Meta如何将缓存一致性提高到99.99999999%

介绍

缓存是一种强大的技术，广泛应用于计算机系统的各个方面，从硬件缓存到操作系统、网络浏览器，尤其是后端开发。对于Meta这样的公司来说，缓存尤为重要，因为它有助于减少延迟、扩展繁重的工作负载并节约成本。由于他们的用例非常依赖缓存，这带来另一系列问题，即缓存失效。

多年来，Meta已经将他们的缓存一致性指标从99.9999%（6个9）提高到99.99999999%（10个9），这意味着在其缓存集群中，每十亿次缓存写入中，不一致的写入次数将少于1次。

本文将重点讨论以下内容：

• 什么是缓存失效和缓存一致性？
• 为什么Meta对缓存一致性如此重视，甚至6个9的准确率都无法满足需求？
• Meta的监控系统如何帮助他们改善缓存失效和缓存一致性，并修复错误的？

一、缓存失效和缓存一致性

顾名思义，缓存并不保存数据的原始来源，因此当原始来源的数据发生变化时，应该有一个主动使陈旧缓存条目失效的过程。如果在失效过程中处理不当，可能会在缓存中无限期地留下与原始来源不一致的值。

那么，我们如何使缓存失效呢？

我们可以设置TTL（生存时间）来维持缓存的新鲜度，由此就没有其他系统会导致缓存失效了。但是，在本文的主题是Meta的缓存一致性，我们将假设使缓存失效的操作是由缓存本身以外的其它系统执行的。

首先，让我们看看缓存不一致是如何产生的：

请假设1、2、3、4是依次递增的时间戳。

• 缓存首先尝试从数据库中填充值。
• 但在x=42的值到达缓存之前，某个操作更新了数据库，将x的值改为43。
• 数据库发送了x=43的缓存失效事件，并在x=42到达缓存之前到达了缓存，于是缓存的值被设置为43。
• 现在，事件x=42到达缓存，缓存的值被设置为42，于是引入了不一致性。

为了解决这个问题，我们可以使用版本字段来执行冲突解决，这样旧版本就永远不会覆盖当前版本。该解决方案适用于互联网上几乎 99% 的公司，但由于系统的复杂性，这个解决方案可能还是无法应对Meta的运营规模。

二、为什么Meta如此重视缓存一致性？

从Meta的角度来看，缓存不一致几乎与数据库数据丢失一样糟糕，而从用户的角度来看，缓存不一致可能导致糟糕的体验。

当你在Instagram上给用户发送私信（DM）时，后台会有一个用户到主存储器（用户信息就存储在主存储器）的映射，用户的信息就存储在主存储器中。

想象一下这里有三个用户：Bob、Mary和Alice。这两个用户都给Alice发送了消息。Bob在美国，Alice在欧洲，而Mary在日本。因此，系统会查询离用户最近的区域，并将消息发送到Alice的数据存储区。在这种情况下，当TAO（The Associations and Objects，Meta的社交图谱存储系统）副本查询Bob和Mary所在的区域时，它们都有不一致的数据，并将消息发送到了没有任何Alice消息的区域。

在上述情况下，将会出现消息丢失和糟糕的用户体验，因此这是Meta需要解决的首要问题之一。

三、监控

要解决缓存失效和缓存一致性问题，首先要进行测量。如果我们能够准确测量缓存一致性，并在缓存中出现不一致条目时发出警报，就能发现问题。然而Meta确保其测量结果不包含任何误报，只是因为值班工程师会忽略警报，由此指标就失去可信度和可用性。

在深入探讨Meta实施的解决方案之前，最简单的解决方案将是记录并跟踪缓存的每次状态变化。在工作负载较小的情况下，这个方案是可行的，但Meta的系统每天的缓存填充量超过10万亿次。记录和跟踪所有缓存状态，会将已经很重的缓存工作负载变成更加沉重，我们甚至不想考虑如何调试它。

四、Polaris

宏观来看，Polaris作为客户端与有状态服务进行交互，并假定其对服务内部结构一无所知。Polaris基于“缓存最终应与数据库一致”的原则工作。Polaris接收失效事件后会查询所有副本，以验证是否发生其他违规情况。

例如：如果Polaris接收到x=4版本4的失效事件，它以客户端身份检查所有缓存副本，以验证是否发生其他违规情况。如果一个副本返回x=3@版本3，Polaris会将其标记为不一致，并重新获取样本，以便稍后与同一目标缓存主机进行检查。Polaris会在特定的时间尺度（例如，一分钟、五分钟或十分钟）内报告不一致性。

这种多时间尺度的设计不仅允许Polaris内部拥有多个队列，以有效实现回退和重试，对于防止误报也至关重要。

让我们通过另一个例子来理解这一点：

假设Polaris接收到一个版本为4的失效事件x=4。但当Polaris检查缓存时，却找不到x的条目，它应该将此标记为不一致。在这种情况下，有两种可能性。

• 在版本3时，x是不可见的，但版本4的写入是该键上的最新写入，这确实是一个缓存不一致。
• 可能是版本5的写入删除了键x，也许Polaris只是看到了比失效事件中更新的数据。

现在，我们如何确定这两种情况中哪一种是正确的？

为了验证这两种情况Polaris需要通过查询数据库进行检查。绕过缓存的查询可能是计算密集型的，并且也可能使数据库面临风险，因为保护数据库和扩展读取密集型工作负载是缓存的两个最常见的用例。因此，我们不能向系统发送太多查询。

Polaris的解决方案是，延迟执行此类检查并调用数据库，直到不一致的样本超过设定的阈值（例如1分钟或5分钟），从而解决了这个问题。Polaris的产品指标表述为“在M分钟内，N个九的缓存写入是一致的。”因此，目前Polaris提供了一个指标：表示在五分钟的时间尺度内，99.99999999%的缓存是一致的。

现在，让我们通过一个编码示例，了解Polaris如何帮助Meta解决由缓存不一致性引起的bug：

假设有一个缓存，它维护着密钥到元数据的映射和密钥到版本的映射。

cache_data = {}

cache_version = {}

meta_data_table = {"1": 42}

version_table = {"1": 4}

1.当读取请求到来时，首先在缓存中检查该值。如果缓存中不存在该值，则从数据库中返回该值。

def read_value(key):

value = read_value_from_cache(key)

if value is not None:

return value

else:

return meta_data_table[key]

def read_value_from_cache(key):

if key in cache_data:

return cache_data[key]

else:

fill_cache_thread = threading.Thread(target=fill_cache(key))

fill_cache_thread.start()

return None

2.缓存返回 None 结果，然后开始从数据库填充缓存。我在这里使用了线程来使进程异步。

def fill_cache(key):

fill_cache_metadata(key)

fill_cache_version(key)

def fill_cache_metadata(key):

meta_data = meta_data_table[key]

print("Filling cache meta data for", meta_data)

cache_data[key] = meta_data

def fill_cache_version(key):

time.sleep(2)

version = version_table[key]

print("Filling cache version data for", version)

cache_version[key] = version

def write_value(key, value):

version = 1

if key in version_table:

version = version_table[key]

version = version + 1

write_in_databse_transactionally(key, value, version)

time.sleep(3)

invalidate_cache(key, value, version)

def write_in_databse_transactionally(key, data, version):

meta_data_table[key] = data

version_table[key] = version

3.同时，当版本数据填入缓存时，数据库可能会有新的写入请求，更新元数据值和版本值。此时这看似是一个bug，但实际不是，因为缓存失效应使缓存恢复到与数据库一致的状态（注意，我在缓存中添加了 time.sleep，并在数据库中添加了写入函数，以复现该问题）。

def invalidate_cache(key, metadata, version):

try:

cache_data = cache_data[key][value] ## To produce error

except:

drop_cache(key, version)

def drop_cache(key, version):

cache_version_value = cache_version[key]

if version > cache_version_value:

cache_data.pop(key)

cache_version.pop(key)

read_thread = threading.Thread(target=read_value, args=("1"))

write_thread = threading.Thread(target=write_value, args=("1",43))

print_thread = threading.Thread(target=print_values)

4.后来，在缓存失效过程中，由于某些原因导致失效失败，在这种情况下，异常处理程序有条件放弃缓存。

丢弃缓存函数的逻辑是，如果最新值大于 cache_version_value，那么就删除该键，但在我们实际情况中并非如此。因此，这将导致在缓存中无限期地保留陈旧的元数据。

请注意，这只是对bug发生过程的简化表述，实际中的bug会更加错综复杂，涉及数据库复制和跨区域通信。只有当上述所有步骤都按特定顺序发生时，才会触发bug。这种不一致性很少被触发，一般都隐藏在交错操作和临时错误后面的错误处理代码中。

既然您已经接到 Polaris 调用缓存不一致的请求，那么最重要的就是检查日志，看看问题出在哪里。正如我们之前所讨论的，记录每一个缓存数据变化几乎是不可能的，但如果我们只记录有可能导致变化的变化呢？

五、一致性跟踪

如果正在值班的你接到了Polaris报告的缓存不一致性的通知，最重要的是检查日志并确定问题出在哪里。正如我们之前讨论的，记录每个缓存数据更改几乎是不可能的，但如果我们只记录那些有可能导致不一致性的更改呢？

我们查看上面实现的代码，如果缓存没有收到失效事件或者失效操作没有生效，那么问题就可能发生。从值班人员的角度来看，我们需要检查以下内容：

• 缓存服务器是否接收到了失效请求？
• 服务器是否正确处理了失效请求？
• 之后相关条目是否变得不一致了？

Meta已经构建了一个有状态追踪库，该库在这个紫色小窗口中记录和跟踪缓存变更，所有有趣且复杂的交互都在这里触发bug，从而导致缓存不一致。

结论

对于任何分布式系统来说，可靠的监控和日志系统都是必不可少的，以确保我们能够抓住bug，并在捕获bug时迅速找到根本原因，从而减少问题发生。以Meta为例，Polaris识别异常后立即发出警报。借助一致性跟踪提供的信息，值班工程师在不到30分钟内就定位到了bug。

>>>>参考资料

• engineering.fb.com/2022/06/08/core-infra/cache-made-consistent/

作者丨Mayank Sharma 编译丨onehunnit

来源丨medium.com/@mayank.sharma2796/how-meta-improved-their-cache-consistency-to-99-99999999-58d79674a806

*本文为dbaplus社群编译整理，如需转载请取得授权并标明出处！欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn