Codis 的设计与实现 Part 3

性能，HA (高可用)，运维等等

「对于一个设计良好的分布式系统来说，单机性能从来不是一个问题 」—— 我

第一篇文章就说了，Codis 采用了 Proxy 的方案，所以必然会带来单机性能的损失，经测试，在不开 pipeline 的情况下，大概会损失 40% 左右的性能，但是 Redis 本身是一个快得吓人的东西，即使单机损失了 40% 仍然是一个很大的数字。
另外一个比较好的地方是，Codis 本身是可以充分的利用多核的（Thanks to golang），在多线程客户端的环境下，不会像 Twemproxy 那样，撑死就跑满一个 CPU（当然你可以部署 Twemproxy 的多实例，但不就又增加运维成本了嘛。。。）。而且不要忘了，
Codis 可以通过平行扩展多个 Proxy 实现性能成倍的提升，一台机器 CPU 满了？没事，再另一台机器起一个 proxy 就是了。某个 Redis 跑满了？没事，把一部分数据迁移到另外一个 Redis 实例好了。所以，我们从来不认为单机性能能说明什么。 使用 Codis 带来的最大的好处，是为你的缓存提供了弹性扩缩容的能力, 而不是追求榨干底下 Redis 的性能。。。这也是我们选择了 go 而不是 c 来开发的原因。

我们进行了一个详细的性能测试，测试的结果如下：Benchmark , 2 proxy 的情况下，单机可以到达 20w 的 QPS.

HA (Redis HA, Proxy HA)

对于Redis HA, 我个人是蛮纠结的，仔细用过的 Codis 的同学会发现，在某个 server group 的 master 死掉的时候，虽然 server group 里可以有多个 slave，但是这些 slave 并不会自动的提升为 master。
当然实现这个功能并不困难，但是我认为这种情况应该让管理员清楚，并手动的操作，因为如果自动的切到 slave 上，这段时间原 master 还没同步到 slave 上的数据有可能就会冲突，如果 master 又复活了，解决数据的冲突是一个麻烦的问题，与其自动的操作，不如给客户端返回失败 (也只是这个机器负责的slots 会失败，如果实例足够多，不会出现致命的单点故障), 交给管理员去处理。

Proxy HA, 在决定使用无状态的 proxy 的方案时，就自动带来了高可用性的保证，这个不多说，有很多种做法，比如智能DNS，HAProxy，客户端连接 ZooKeeper 做 Proxy 的连接池等。

说到可运维性，Codis 几乎一切的操作都是通过 codis-config 发起的，codis-config 在做任何操作的时候，都会到 ZooKeeper 拿一个锁，以保证是唯一的操作实例，这也是防止路由表被改坏的一个措施，尤其是设置迁移这样比较敏感的操作，必须保证不能同时有多个 slots 处于迁移状态，所以，在整个迁移的过程中，是不释放锁的。

那么如果在迁移一个 slot 的过程中，我强行杀死 (kill -9) codis-config 不让它释放迁移的锁会怎么样？会死锁吗？

答案是：不会的。

为什么？首先，在迁移过程中的任意阶段打断，都是没有问题的，因为对底层的 redis 来说，迁移的只是一个个原子的 key，我杀掉了 codis-config ，只是停止了发指令的人，导致这个 slot 没有全部迁移干净而已, 在 Zk 上看到的也只是一个长期处于迁移状态的 slot (由于 codis-config 被杀了，没人去发迁移命令，也不会在迁移完成的时候修改slot状态了). 此时如果客户端有请求，proxy 也会主动的发一个 migratekey 先强行的把这个key迁移过来，所以对客户端也是没有影响的。

而且 codis-config 还有一个特性，每次启动的时候，都会在 Zk 上注册一个临时节点， 记录自己的 pid 和机器名，而且上的所有的锁，都会带上机器名和pid的签名，每次启动的时候，会扫描一下所有未释放的锁，如果这个锁的所属进程的临时节点已经不存在了，就会直接把这个锁释放掉，于是避免了死锁的状态。

只不过在下次开始新的迁移任务之前，需要先将这个未迁移完成的slot迁移掉，方法是发起一个迁移任务，from slot 和 to slot 都写成这个slot id, new group id设成之前未完成的那个任务的group id, 这个是为了保证系统能重新回到一个干净的状态，再进行下一个新的迁移任务。这是一个人为加的限制。

在实际使用 Codis 的过程中，我们为一些特别懒的业务 （懒得重建缓存），开发了叫做redis-port的工具，它的作用是，作为一个假的 slave，挂在一个redis后面，然后将master的数据同步回来，sync 到 codis 集群上，所以，业务方根本无需重建缓存，直接同步完后，换个地址重启服务就OK了， 这也是问哦们在公司内部推动项目特别轻松的一个杀手锏。 :P

除此之外，Codis 还有一个和其他后端中间件不太一样的地方：它不仅提供了完整的 Unix CLI interface, 居然有一个炫酷的 dashboard 和完整的 RESTful API ! 恩，没错，而且在实际的生产环境中，我们发现使用 dashboard 更安全，更少误操作，更方便，而且系统的实时状态都非常清晰。这年头，要没有一个好看的 dashboard 都不好意思开源了。。。（嘛，其实是我刚学 AngularJS，技痒了。。。不过最终效果还不错）。

三篇文章差不多写完了，有什么问题可以在 github 上 post issue, 也可以在微博上联系我 @Dongxu_Huang 或 @goroutine, 当然，邮件也可以，同时如果你对豌豆荚基础架构组有兴趣，也欢迎你把简历发过来，我们是 Golang 的重度用户 :) 也是开源的狂热分子，有机会希望和你一起工作, email: [e-mail]

转载：http://0xffff.me/blog/2014/11/11/codis-de-she-ji-yu-shi-xian-part-3/