BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Benjamin Darfler 关注 0 他的粉丝 ,译者 潘瑾瑜 关注 0 他的粉丝 发布于 2014年8月20日. 估计阅读时间: 3 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT