Flickr 选择使用 Sentinel 来保证 Redis 的高可用性

Flickr 近期宣布，针对他们的线下任务处理子系统中的 Redis ，已经部署了 Sentinel ，用于自动化其故障转移操作。但他们对 Redis 的一致性问题感到了担忧。

去年， Factual 的工程师及分布式系统专家 Kyle Kingsbury ，对 Redis 的一致性问题进行了研究，并将结果发表在了他的 Jespen 系列连载中。在文章中，他表示能够使用 Redis 和 Sentinel 构造出这样一个场景：在 Redis 通知我们已成功的写请求中，有 56% 的写请求事实上是被丢弃了。Kingbury 表示，这个令人担心的结果是由 Sentinel 系统中的两个问题导致的。

第一个问题，要注意在网络分割开始时，所有客户端都会丢失写请求的数据。因为当网络出现故障时，客户端都往 n1 节点写数据。由于之后 n1 退级，不再是主节点，在这个时间窗口内写入的数据将全部丢失。第二个问题是由 split-brain 引起的：在网络分割现象消失之前，n1 和 n5 都成为了主节点。一些客户端可能可以成功地写入数据，而其他的将丢失所写的数据，这取决于客户端与哪个节点进行交互。

Redis 的作者 Salvatore Sanfilippo ，对这篇文章作出了回复。他确认了这个问题的存在，但也同时指出：丢失数据量最小化并不是 Sentinel 的设计目标。

需要明确的是，这条指责是正确的。它表明了 Sentinel 并不擅长处理在网络分割中将丢失数据量最小化这个复杂的问题，这一点原本就不是 Sentinel 的设计目标。况且，在用户通过自己所写的脚本来处理故障转移的案例中，99% 的案例在故障检测和故障转移处理过程上，远远逊于 Sentinel。

尽管 Flickr 知道这些问题，但由于起初他们为自己的线下任务处理子系统制定了过于自信的 SLA 目标，他们开始转而使用 Sentinel。在注意到他们的手动故障恢复流程不可能帮助他们达到 99.995% 正常运行时间的目标后，他们寻找了其他解决方案，并选定了 Sentinel。

在对 Sentinel 系统及它的配置参数进行重要的测试之后，他们能设计出一种在 4～6 秒钟内自动进行故障转移的方法。从而使得他们可以达到之前设定的正常运行时间的目标。在测试过程中，他们也能重现 Kingsbury 所发现的场景。但是，Flickr 工程师 Richard Thorn 和 Shawn Cook 解释道：“尽管我们相信我们的生产环境会受到 split-brain 的影响，但我们确信所获得的好处远大于带来的风险”。

参考英文原文： Flickr Chooses Sentinel for Highly Available Redis

感谢邵思华对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。