作者 | Renato Losio
译者 | 王强
Cloudflare 的工程团队最近分享了他们如何将公司内部的全局键值存储 Quicksilver 过渡到分层缓存架构的故事。他们介绍了他们逐渐从“每一处都存储全部内容”的策略转变为采用分布式缓存系统的旅程。这一变化提高了存储效率，同时保证了一致性和边缘的低延迟读取性能。
在过去几年里，Cloudflare 从现在被称为 Quicksilver V1 的系统过渡到了新的分层缓存系统 Quicksilver V2，后者只使用了少数『服务器』来存储数据。这两篇文章描述了他们如何实现分层缓存架构的过程，这个过程需要团队迁移数十万个实时数据库，同时每秒服务数十亿个请求。
Quicksilver 是 Cloudflare 内部开发的一种键值存储，用于实现快速的全局复制，并在该公司全球众多『数据中心』中实现低延迟访问。它最初设计为分发各种配置的全局系统，随着时间的推移，它演变成了许多 Cloudflare 服务和产品（包括他们的 DNS、CDN 和 WAF）的基础存储系统。
Quicksilver v1 在全局每个『服务器』上都存储完整的数据集，结果消耗了大量磁盘空间，1.6TB 的数据集在仅仅一年内就增长了 50%，意味着 Cloudflare 网络中的可用存储即将耗尽。向新方案的迁移始于 Quicksilver v1.5，这是一个引入代理和复制『服务器』角色的解决方案，它让磁盘占用减少了 50%。
在最新的 v2 实现中，Cloudflare 引入了多级缓存策略。最新架构的特点是本地的每『服务器』一份缓存、『数据中心』范围内的分片缓存和在专用存储节点上的完整数据集副本，以及将未命中缓存分散在『服务器』之间的响应式预取。内存使用和冷缓存问题导致 Cloudflare 选择使用 RocksDB 的持久存储，而不是基于内存的缓存，并使用基于这一引擎的压缩过滤器进行驱逐。
Cloudflare 的系统『工程师』 Anton Dort-Golts 和 Marten van de Sanden 解释了为什么向后兼容性和顺序一致性很重要：
Quicksilver 从一开始就为客户提供了顺序一致性……我们亲身体会了海勒姆定律，Quicksilver 在公司内部采用得如此广泛，以至于我们在早期版本中引入的每个属性现在都依赖其他团队。这意味着更改行为将不可避免地破坏现有特性并引入错误。
新架构通过多版本并发控制（MVCC）和滑动窗口方法来处理异步复制挑战，从而保持顺序一致性。
从旧架构到 Quicksilver v2 的转变解决了 Cloudflare 之前在 330 个城市网络中遇到的关键瓶颈，同时保持了 1.6TB 数据集的亚毫秒处理性能（该数据集包含五十亿个键值对）。根据作者的说法，Quicksilver 目前对 90% 的请求可在 1 毫秒内响应，99.9% 的请求在 7 毫秒内响应。大多数请求只返回几个键，而其他请求返回数百甚至更多的键。Dort-Golts 和 van de Sanden 补充说：
我们的键空间被分成了多个分片。『数据中心』中的每个『服务器』被分配了一个分片。这些分片不是包含它们键空间部分的完整数据集，而是包含它的一片缓存。这些缓存分片由『数据中心』内的所有未命中缓存来填充。这一切组成了一个使用分片分布的，『数据中心』层面的缓存系统。
Cloudflare 通过维护本地每个『服务器』一块缓存以及『数据中心』级别的缓存来解决数据本地性问题，『数据中心』中的所有『服务器』都包含它们的本地缓存，和分片缓存的一个物理缓存分片。每个请求的键首先在『服务器』的本地缓存中查找，然后在『数据中心』范围的分片缓存中查找。如果两个缓存都未命中键，则在存储节点之一上查找。作者在文章最后分享了一些有多个缓存层的测试结果：
添加第二缓存层后，可以在『数据中心』内解决的键的百分比显著提高。表现最差的实例具有高于 99.99% 的缓存命中率。所有其他实例的缓存命中率高于 99.999%。
代理和副本之间的 99.9 百分位延迟几乎没有差异，由于磁盘数据集较小，代理偶尔优于副本。
