[译] Cache warming: Agility for a stateful service (一)

图 OWLIE by Mickael Lelièvre

by Deva Jayaraman, Shashi Madappa, Sridhar Enugula, and Ioannis Papapanagiotou

译: 麦芽面包

原文:

https://medium.com/netflix-techblog/cache-warming-agility-for-a-stateful-service-2d3b1da82642

EVCache现在是Netflix平台的一个基础部分(我们叫它一层)，保存了PG级的数据。我们的缓存层服务了包括登录，个性化，搜索，回放等许多场景。它是由千记的节点和百记的集群组成，由于我们的用户增长所以它需要经常常规性地进行扩容。为了满足我们对缓存的需求，我们最近讨论了应用数据缓存的进化:从RAM到SSD。

缓存的存储能力可以通过横向或纵向扩展(一些情况是从RAM到SSD)。许多服务每天进行千亿级别的查询，我们缓存基础设施的网络能力。当我们由于存储或网络的原因需要对缓存进行扩展时，我们的方式是提供一个新的空缓存，双写到老缓存和新缓存中，然后让数据在老集群中的TTL到期时失效。这个方法工作的很好。但当每次扩容时，我们都需要在TTL区间关注老缓存和新缓存集群。这个方式对于有些集群中存在不过期的item或一些会变化的item会有问题。并且在节点上自然地预热数据会导致在缓存替换时出现一些数据丢失。

图1. 新部署的EVCache数据路径

为了解决以上提到的问题，我们引入了EVCache缓存预热设施，它具备以下能力：

复制预热：一种从一个已存在的节点尽可能快的将数据复制到新节点并且不影响客户端使用已存在的节点的机制。

实例预热：一种将当前节点替换或停止后能使用非当前节点的数据来进行启动的机制。

Cache Warmer

设计缓存预热系统的目标是：

• 减少当前EVCache客户端的网络影响

• 最小化当前EVCache节点的内存和磁盘使用。

• 减少预热时间

• 对于何时(高峰/低峰)进行预热没有限制。

之前的方法

我们试验了几种设计方式来达到这些需求。

Piggybacking on Replication

Netflix的云部署模型是 主-主，所以我们需要保证在AWS的三个region中同步所有EVCache集群。我们需要建一个使用自定义Kafka的基于多region的复制系统。在我们最初的迭代中，我们考虑可以使用Kafka的队列消息来对新节点进行预热。但是，一个问题是这个方式需要我们在TTL过期前（可能几周）存储所有的key，这样成本较高。我们也遇到了key的重复复制问题，尤其是过期的那种。

微信公众号「麦芽面包」， id 「 darkjune_think 」

开发者 / 科幻爱好者 / 硬核主机玩家 / 业余翻译家 / 书虫

交流 Email: zhukunrong@yeah.net