从小白到架构师 | Meta 如何实现 99.99999999% 的缓存一致性-技术圈

推荐一个原创技术号-非科班大厂码农，号主是机械专业转行进入腾讯的后端程序员！

曾经的故事

Meta（Facebook）曾经运行一个简单的技术栈——PHP 和 MySQL。

但随着更多用户的加入，他们面临着可扩展性问题。因此他们建立了一个分布式缓存。

虽然这暂时解决了可扩展性问题，但保持缓存数据的新鲜度变得困难。以下是一种常见的数据不一致场景：

现在数据库中的值：x = 1，而缓存中的值：x = 0。所以存在缓存和数据库中的数据不一致。

尽管缓存不一致出现的概率很小，但是Meta 的用户增长速度却是爆炸性的，很快成为全球访问量第三大的网站。

现在他们每天处理一千万亿（10^15）个请求。所以即使有1%的缓存未命中率其代价也是昂贵的——每天有10万亿次缓存填充。

这篇文章介绍了 Meta 如何利用可观测性来提高缓存一致性。

从用户的角度来看，缓存不一致就像数据丢失一样。因此他们创建了一个可观察性解决方案。以下是他们的做法：

Meta的开发人员开发了一个单独的服务来监控缓存不一致问题，并将该服务命名为Polaris。 Polaris 监控缓存不一致

Polaris 的工作原理如下：

这里还是举一个例子来帮助理解Polaris 的工作原理：假设有一个电商网站，它使用缓存来加速用户访问产品信息的速度。缓存中存储了产品的价格、库存等信息，而这些数据的原始来源是数据库。

数据库更新：某个商品的库存从10件增加到20件，数据库发送了一个缓存失效事件。
Polaris 接收事件：Polaris 收到了这个失效事件，并开始工作。
查询缓存服务器：Polaris 向缓存服务器查询该商品的信息，发现缓存中的库存还是10件，与数据库中的20件不一致。
排队并再次检查：Polaris 将这个缓存服务器排队，稍后再次检查和刷新缓存，确保缓存中的数据更新为20件。
在写入时检查：现在，假设有另一个用户在短时间内再次购买商品：库存从20件减少到19件。在这个写入操作发生时，Polaris 会再次检查缓存中的数据，确保缓存中的数据是最新的19。如果发现缓存中的数据不正确（例如，缓存中显示的是20件，而实际库存已经变为19件），Polaris 会立即更新缓存，确保缓存和数据库中的数据保持一致。

此外，分布式缓存与 Polaris 之间存在网络分区的风险。因此他们在客户端与 Polaris 之间使用单独的失效事件流。这个流专门用于传递缓存失效事件，即使在网络分区的情况下，也能确保失效事件被传递到位。

解决缓存不一致的一个简单方法是查询数据库。但大规模下数据库存在过载风险。因此 Polaris 以 1、5 或 10 分钟为时间间隔查询数据库。通过这种方式，Polaris 可以在确保数据一致性的同时，避免频繁查询数据库导致的过载问题。

在没有日志的情况下调试分布式缓存中的问题非常困难。为了找到缓存不一致的原因，记录每个数据更改虽然是一个办法，但因为写入操作过于频繁，导致这种方法不可扩展。因此，他们创建了一个跟踪库并将其嵌入到每个缓存服务器上。记录竞争条件窗口期间发生的数据变化

其工作原理如下：

跟踪库仅记录在竞争条件时间窗口内发生的数据变化，从而减少了日志存储的需求。竞争条件时间窗口是指在发生数据竞争的时间段。例如，当多个操作同时尝试访问和修改同一数据时，会产生竞争条件。
跟踪库会保存最近修改的数据的索引，以便在发生新的数据更改时，判断是否需要记录。如果新数据变更涉及到最近修改的数据，才会进行记录。这种方式减少了不必要的日志记录，
如果Polaris发现缓存不一致，它会读取这些日志来查找问题的根源，然后发送通知。这样可以快速定位和解决问题。

缓存失效是计算机科学中的难题之一，现在 Meta 支持 10 个 9 的缓存一致性 - 99.99999999%。简而言之，100 亿次缓存写入中，只有 1 次会出现不一致的情况。这种技术可以与任何规模的缓存服务器一起使用。