redis集群方案

前端时间粗略的调研了一下redis集群方案，研究的不算深入，还有很多问题没有想明白，暂时把已经调研的清楚的记录下来。

redis集群方案，主要有4种方案client、twemproxy、codis、redis3.0 cluster。

需要考虑的点包括：集群性能、redis ha、扩容、迁移、client友好程度

一、client端负载均衡方案

可以将redis分成两种用途，cache和storage。

cache：这种方案仅是将redis当作cache，其实和memcache基本一样，client端采用一致性hash算法实现，后端storage可以用mysql。

1. 性能，可以达到N台redis性能总和，理论值待验证
   
2. redis ha，这种方案由于最终存储都放在了mysql上，无需保证redis上数据安全性，如果redis上没有，直接穿透到mysql则可。不需要redis的ha。
3. 扩容，通过一致性hash算法进行扩容
4. 迁移，手动迁移
5. client需要自己实现，目前未找到开源项目
   

storage：

1. 性能，可以达到N台redis性能总和，理论值待验证
2. redis ha，可以借助zookeeper或sentinel来实现主备切换
3. 扩容，模倍数扩容，方案细节后面详述
4. 迁移，手动迁移
5. client需要自己实现，目前未找到开源项目

storage扩容方案

假如扩容前是模N，我们提出的方案：扩容后，对N的倍数进行模运算。

以扩容后模2N为例，具体操作为：

1. 首先对N个Master节点（如A、B、C），以1:1建立N个Slave同步（如D、E、F）
2. 然后关闭Slave库的ReadOnly，但主从关系和顺序保持不变，客户端改为模2N（A、B、C、D、E、F）
3. 然后断开主从
4. 最后异步清理掉2N个库中多余的50%的Key

二、Twitter开源proxy twemproxy

twemproxy是比较老牌的redis proxy方案，有很多公司（Twitter、yahoo等）在使用。twemproxy由于是单个进程的，只能使用单核cpu，如果前端挂keepalive或haproxy等代理，可以为twemproxy做1+1主备。

1. 性能，N台redis server，仅能达到单台redis server的80%的性能，有20%的性能损耗
2. redis ha，sentinel，twemproxy会订阅sentinel，完成主备切换，对client完全透明
3. 扩容，官方未提供扩容方案，需要人工参与，并需要修改twemproxy配置文件，重启twemproxy服务
4. 迁移，官方未提供迁移方案，需要人为参与
5. client，对client友好

三、豌豆荚开源proxy codis

豌豆荚codis可以使用多核cpu，如果前端挂keepalive或haproxy等代理，可以为codis做1+1主备。

通过presharding技术做数据分片，slot个数为1024个，SlotId = crc32(key) % 1024，引入zookeeper，记录路由信息。

访问顺序为key---->计算slot id---->通过zookeeper记录的slot和machine对应关系（路由信息），找到对应的machine。

1. 性能，N台redisserver，能达到单台或以上性能，可以利用多核cpu（twemproxy仅能利用单核cpu），目前在实验室vm仅有4核cpu，可以达到单台redis的性能，如果继续增加cpu核数，或许能继续提升性能
2. redis ha，codis-ha，豌豆荚开源的ha方案，对client完全透明
3. 扩容，官方提供了完美解决方案，对client完全透明
4. 迁移，官方提供了完美解决方案，对client完全透明。这个迁移其实就是将slot从一台机器迁移到另一台机器，然后修改zookeeper中的路由信息则可
5. client，友好，client无需修改代码

四、redis 3.0 cluster方案

redis3.0 版本提供了一套去中心化的分布式解决方案，需要client端的配合，增加了client redirect过程。这套方案，目前没有在生产环境大规模商用，至于有多少坑要填，尚且未知。

1. 性能，N台redisserver，能达到N*单台redis性能（官方文档说明）
2. redis ha，sentinel，client订阅sentinel，获取ha切换事件，主备redisip改变
3. 扩容，未做调研
4. 迁移，未做调研
5. client，不友好，目前官方给出的client driver没有c/c++，而且从网友反馈的信息来看，支持的java client driver也有大量bug

五、实验室twemproxy和codis性能测试数据

命令：

redis-benchmark -h10.10.73.212 -p 6000 -c 200 -d 1024 -r 1024 -q -t set,get

本地：

SET: 99009.90requests per second

GET: 92506.94requests per second

跨网：

SET: 65746.22requests per second

GET: 77160.49requests per second

单进程twemproxy：

SET: 52603.89requests per second

GET: 51282.05requests per second

4核cpu的codis：

SET: 61327.12requests per second

GET: 62644.86requests per second

结论：

六、结论

Start client，性能不错，但是需要client参与的事情太多（包括ha、扩容、迁移），目前没有开源项目供参考，暂时不考虑。

Twemproxy：性能一般，扩容和迁移很痛苦。

Codis：多核cpu，性能要好于twemproxy，同时ha、扩容、迁移对client完全透明。

Redis3.0 cluster：目前并没有哪家公司在生产环境大规模使用，到底有多少坑需要填，还属于未知数。

综合考虑，我认为可以考虑豌豆荚开源的codis，大家有不同意见，可以一起讨论

七、尚待研究的问题

1. twemproxy hash算法？
2. sentinel 原理？
3. 继续增加cpu，codis性能极限？
4. nginx+lua+codis+redis性能？
5. nginx+module+codis+redis性能？
6. 性能调优，包括内核参数、nginx、lua redis、nginx module等。
   

八、参考资料

Codis开源项目：https://github.com/wandoulabs/codis

Twemproxy开源项目：https://github.com/twitter/twemproxy

Codis作者给出的说明：http://chuansong.me/n/1509830

Redis相关：http://redis.io/topics/sentinel

性能测试数据：https://github.com/wandoulabs/codis/issues/309