去年我写了一篇关于Redis和Memcached与ketama一致哈希的文章:http://engineering.wayfair.com/consistent-hashing-with-memcached-or-redis-and-a-patch-to-libketama/。从那时起,我们对我们的系统进行了很多改进。去年11月,我在Facebook的卓越Data@Scale波士顿会议上谈到了最新的发展:https://www.youtube.com/watch?v=oLjryfUZPXU。我们对设计和代码都有一些更新,我们准备与大家分享。

总结一下:在过去四年的任何时候,我们都有了一个我称之为最小可行的缓存系统。阶段是:

  1. 站起来一主从Memcached的对。
  2. 添加分片Redis,每个分片都是主从对,具有松散的pinstagram风格的持久性,基于完全分布的ketama客户端进行一致的散列,Zookeeper会通知客户端配置变化。
  3. 更换(1)Wayfair-ketamafied Memcached的,无主的奴隶,只是ketama故障转移,也被动物园管理员管理。
  4. 把Twemproxy放在Memcached的前面,Wayfair-ketamafied的Twemproxy入侵了它。ketama代码从客户端(如PHP脚本和Python服务)转移到代理组件。这两个系统(一个配置完全分布式,一个基于代理)保持了互操作性,还有一些完全分布式的客户机至今仍然存在。
  5. 增加Redis配置的改进,特别是在集群扩展期间为过渡状态同时增加2个哈希环。
  6. 将所有Redis键切换到' Database 0 '
  7. 把Wayfairized Twemproxy放在Redis前面。
  8. 在每个数据中心建立第二个Redis集群,配置与Memcached基本相同,每个碎片没有slave,每个键可以从一个交互(非批处理)源惰性地填充。

我们要写的代码是

  1. 对理查德·琼斯的ketama的一些补丁,在之前的博客中有详细描述:https://github.com/wayfair/ketama
  2. 一些补丁,以Twitter的Twemproxy:https://github.com/wayfair/twemproxy,这是一个较小的更改,使它可以与前面的项互操作。
  3. 修正php-pecl-memcached,删除“版本”检查
  4. 动物管理员脚本保姆行为不端的群集节点。这是一个要点给出一个想法。

Twemproxy /胡桃夹子已Redis的支持,从早期的,但显然Twitter的不生产的Redis的前面延伸Twemproxy,如下Twitter的高速缓存团队讨论的姚乐:
。因此,我们不必感到惊讶,它没有给我们“只是工作”没有一个轻微的修改,并添加了动物园管理员组件。

在此过程中,我们考虑了另外两个解决这个问题的方法:mcRouter和Redis集群。麦克劳德的决定并没有什么了不起的。Facebook去年夏天发布了McRouter。我们的核心用例已经被我们不断发展的复合系统覆盖了,似乎要做很多工作来破解Redis支持,所以我们没有这么做。McRouter是一款非常棒的软件,从理论上讲,它比我们现有的软件功能更全面。但是由于我们已经走在使用Redis作为twitter风格的“数据结构”服务器的道路上,而不是像Facebook的Tao这样的更特殊的用途,这是另一件mcRouter支持的事情,它感到轻率的走在Redis/mcRouter黑客的边缘。另一个决定是,我们决定不使用Redis集群,这在当时是一件很有感触的事情:我们不想集中处理严重的问题,比如数据库的碎片定位。这些数据库已经有很多需要考虑的了!随着产品的成熟,我们当然会继续关注它。

有一个关于替代技术分析的脚注值得一提。我们饶有兴趣地关注了@antirez和他的助手们关于‘Database 0’的讨论。长话短说:编号数据库将继续存在于Redis中,但它们在Redis集群或Twemproxy中都不受支持。在我们看来,这是有关社会的共识。和许多人一样,我们在很长一段时间前就开始使用编号数据库作为一组快捷而粗糙的名称空间,所以我们考虑过把它黑进Twemproxy,但最终还是决定不这么做。然后当然,我们必须将所有数据移到数据库0中,并将命名空间整合在一起,我们做到了。

我把松散联盟的角色称为我们的分布式系统团队。你不会在Wayfair的组织结构图中找到它们,因为拥有一个集中式的分布式系统团队感觉是错误的。它们潜伏在Wayfair工程公司一组看似随机的软件和系统组中。特殊的荣誉克莱顿Andrii对于无情地切割的代码段浪费了,他们不属于组件,并在正确的子系统,具有精简的结构取而代之。

即使茜草道具同一对工程师,为转变业务方面的无缝处理,因为我们打沿着这条道路的里程碑事件。这里有一些图表,从里程碑比赛日。在第一个,我们开始使用Twemproxy因为这是已经在数据0数据库我们把连接Redis的一半:

redis-twemproxy-migration-1

然后我们又向下迈了一大步。

redis-twemproxy-migration-2

加上这两个步骤,连接数从8K增加到219。对不起过去的网络人,感谢你们的耐心!我们承诺从现在起要做好公民。

[更新:我曾在2014年Facebook的Data@Scale波士顿会议上谈到过这个问题]