Codis 的设计与实现 Part 1

c4pt0r · · 4446 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

最近开源了 Codis,在 Github 上的反响挺不错的,3天已经收集到了 1000 多 stars, 让我比较吃惊。 也从侧面说明了确实分布式缓存是大家都会遇到的问题。于是我打算在本篇和接下来的几篇 Blog 详细说明一下 Codis 的设计和一些背后的考虑,以及对于分布式存储(尤其是缓存)系统的一些思考。

Why proxy?

Codis 的架构采用了 Proxy-based 的设计,没有走官方 Cluster 的路,官方的 Cluster 实现是 P2P 的模型,依靠 Gossip 协议进行消息同步和将数据分若干个 Slot 作为管理的单位,客户端需要更改。这个模型的好处是:

  • 真正的无中心节点
  • 对于客户端来说请求的性能不会损失太多

但是缺点同样明显:

  • 状态很难明确,你很难清楚的知道集群现在处于什么状态
  • 对与redis来说,集群的升级困难,运维困难,因为它将分布式的逻辑和存储引擎绑定在了一起。
  • 需要依赖 smart client

这两个缺点几乎在任何 p2p 模型的分布式系统中都存在,由于第一个问题,导致开发和调试的过程也异常艰辛(官方的 cluster 几乎写了 3 年才比较稳定)

而 Proxy-based 的方式的好处就比较明显了:

  • 开发成本低
  • 业务的切换成本低
  • Proxy 的逻辑和存储的逻辑是隔离的

所以,在 Codis 之前,Twemproxy 是这个方案的最优的选择,应用也非常广泛,许多大型的互联网公司都在使用它,但是 Twemproxy 也有它的问题, 最大的问题是:Twemproxy 真的就只是一个 Proxy 而已, 集群的功能完全没有。而且看上去 Twitter 也不打算继续维护它了。
Twitter 最近的一个 Talk,提到了Twitter 内部对于 Scaling Redis 的一些做法和想法,其中对于 Proxy 的方案是比较推崇的(同时也提到了他们内部也不再使用 Twemproxy 了….),里面理由写得比较清楚了,有兴趣的可以去看看。同样的, Facebook 之前那篇关于扩展 memcached 的论文也提到了类似的方案 (mcrouter)。其中我觉得这个方案背后最重要的思想就是:存储和分布式逻辑分离。至于因为转发请求而损失的性能,可以通过其他的方式补回来, 比如水平扩展 Proxy。带来的好处是整个系统的状态非常清晰,几乎所有组件都可以独立的部署和升级,程序还比较好写,所以 Codis 从一开始就坚定的走 Proxy 这条路。

但是相对于 Twemproxy, Codis 又有一些改进,首先集成了集群的功能,使用 Presharding 对分散数据的存储。所有的集群状态信息依赖 ZooKeeper 进行同步, 所有的 Proxy 是无状态的。这样就可以实现多 Proxy 的水平扩展。
另外一个比较重要的决定是使用 Go 作为主要开发语言,抛掉信仰问题不谈 (我和 @goroutine 都是 go 的脑残粉), go 几乎就是针对这种后端的网络程序而发明出来的语言,这给开发工作带来了极大的效率提升,从写下第一行代码,到第一个可用版本,几乎才用了不到一个月的时间。

当然,使用多 Proxy 对于迁移过程中数据一致性带来一些问题,会在下一篇 blog 介绍一下 Codis 是怎么解决的。

本文来自:dongxu.h

感谢作者:c4pt0r

查看原文:Codis 的设计与实现 Part 1

入群交流(和以上内容无关):Go中文网 QQ 交流群:798786647 或加微信入微信群:274768166 备注:入群;关注公众号:Go语言中文网

4446 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传