Twemproxy

Codis

Redis Cluster

架构设计

分布式CAP,牺牲P性能，而仅仅只是数据分片

分布式CAP,牺牲P性能，设计初衷为数据一致性

分布式CAP,牺牲C数据强一致性原则，追求redis最大的特点性能

设计模型

Proxy-based

Proxy-based

Gossip/P2P

设计思路

分布式逻辑和存储引擎分开，逻辑层proxy代理，存储用的是原子redis，当每个层面需要添加删除节点必须重启服务生效（要重新利用散列函数生成KEY分片更新）

分布式逻辑和存储引擎分开，逻辑层codis-proxy，存储用的是修改过的codis-server,这种好处是proxy层可以自动扩展和收缩，存储层也同样可以，每个层面都可以热插拨

分布式的逻辑和存储引擎不分开，即又负责读写操作，又负责集群交互，升级困难，如果代码有bug，集群无法工作

架构特点

Proxy无状态，redis数据层有状态的，客户端可以请求任一proxy代理上面，再由其转发至正确的redis节点，该KEY分片算法至某个节点都是预先已经算好的，在proxy配置文件保存着，但是如果更新或者删除节点，又要根据一致性hash重新计算分片，并且重启服务

Proxy无状态，codis-server分为组间，每个组存在一个主节点（必须有并且只能有一个）和多个从节点。客户端请求都是和proxy链接，链接哪个proxy都一样，然后由它根据zookeeper路由信息转发至正确节点，直接可以定位到正确节点上

这个结构为无中心的组织，不好把控集群当前的存活状态，客户端可以向任一节点发送请求，再有其重定向正确的节点上。如果在第一次请求和重定向期间cluster拓扑结构改变，则需要再一次或者多次重定向至正确的节点，但是这方面性能可以忽悠不计

codis独特之处

不支持

1、 有中心节点，逻辑问题交由proxy处理，codis还有个特点下层存储可以根据数据的冷热程度把冷数据暂时保存至磁盘，待其为热数据的时候又可以上线（这点我还没有测试）

2、 提供数据在线迁移的工具

比如需求要从redis或者twemproxy迁移数据至codis或者以后redis数据库中，又不想直接预热，可以借助其提供的redis-port命令行工具

不支持

开发语言

C语言

Go语言、C语言

C语言

服务启动方式

单进程

多进程

单进程

性能问题

1、 单点的话比起原子redis降低20%左右；

2、 增加PIPELINE管道提高性能

只要是代理的设计性能瓶颈肯定在其，因redis实在太快

1、 相当于单redis实例40%性能丢失(从最开始的版本比Twemproxy慢20%至目前比其快100%)；

2、 弥补：增加proxy数量和支持多核，比起Twemproxy还是好一点，因Twemproxy最好的情况跑满一个CPU；

3、 弥补：增加PIPELINE管道提高性能

只要是代理的设计性能瓶颈肯定在其，因redis实在太快

没什么损失，追求的就是这个

1000个节点内拥有线性的伸缩性，和操作redis实例性能差不多

分片算法

Redis一致hash，当初设计好如后续变更修改（增减节点）需要配置proxy通知新的算法，重启服务

通过presharding采用solt槽位的形式，整个集群分为1024个哈希槽，分片算法位SlotId = crc32(key) % 1024，增减节点不需要重启服务

采用solt槽位的形式，整个集群分为16384个哈希槽，分片算法位SlotId = crc16(key) % 16384，增减节点不需要重启服务

所需组件

Redis、twemproxy(nutcracker)

Codis、zookeeper

redis

数据一致性

不能保证强一致性

1、 如redis cluster第一种情况没有，设计不一样

2、 网络分裂，这种情况其有监控工具可以通知管理员某个主节点宕机，这时如果管理员切换HA（但是不提供自动提升从节点为主节点，因从节点变为主节点必须更新分片算法，重启服务），数据就会丢失，因主节点的写命令会丢失，除非再次AOF同步最后一条写命令，二者如国管理员可以判断其为网络分裂，等待网络恢复是主节点会向从节点同步写命令数据

强一致性

1、 数据迁移过程中数据强一致性性，因迁移都是一个个KEY原子迁移，每次操作都是给ZK发送信息，通知proxy，同时所有操作都是上一把锁，假如该期间有客户端访问，则提升访问该KEY的操作为优先操作，快速迁移至新节点，访问转移至新节点，不会访问老的KEY，如期间也可以中断正在同步的数据，也是不影响，因为redis没有回滚机制，要么成功要么失败

2、 网络分裂：因为它的设计初衷就是不考虑HA自动切换（后面添加该功能），等到网络恢复Zookeeper保证数据一致性，写命令不会丢失，所有操作都要在zookeeper上面注册

不能保证强一致性

比如官网给出的两种有可能丢失写命令的情况如下

1、 客户端向主节点A发送一条写命令，主节点是首先立马向客户端返回命令回复，然后再把刚刚的执行写命令同步至从节点，追求性能所致该设计

2、 网络分裂(network partition)，如果时间很长导致A节点的从节点转换为主节点，然这中间可能存在客户端正在和A节点通信也就被孤立了，这样写的命令将丢失，如当网络恢复A又重新加入集群

数据的特殊安全

1、 比如某段时间业务数据一下爆表（内存写满），数据来不及迁移，这样的话redis会根据LRU策略，会淘汰一部分老的key，这个没办法，所以运维中当内存使用80%时应该扩容

2、 主从切换过程中有一部分数据丢失（主挂了到从切换上来丢失的这部分数据）

磁盘IO

基于redis本身的持久化（RDB和AOF），肯定会存在数据丢失的情况

数据的迁移

不可在线迁移，并且迁移完之后需要修改配置文件的分片算法，再重新启动Twemproxy服务，重新识别分片算法

采用sharding在线迁移数据，安全透明，可以自动平衡数据到其他节点，相当于可热插拨，不会造成响应时延（因迁移时会另外有个进程来做，数据迁移还是原子的数据迁移指令，这样迁移的话就会相当慢一些）

在线迁移数据，动态迁移KEY值会造成响应时延（迁移数据是拷贝RDB数据文件，而且因为redis是单进程的），另外新节点solt又不自动，依赖ruby(redis cluster集群管理和分配脚本)脚本来平衡数据，无中心设计如此

水平扩容缩容（增减节点）

Redis存储层操作，不提供自动的解决方案，并且要自己写脚本支持数据的搬迁活动，然后更改proxy哈希算法，重启服务

Redis存储层，都是在线操作（扩容数据迁移，缩容的话先搬迁数据至别的节点，然后下线该节点）

没有代理和存储之分，可以在线操作（扩容数据迁移，缩容的话先搬迁数据至别的节点，然后下线该节点）

主从是否必须

1、 没有数据复制不影响可用节点代替故障节点

2、 如果没有做备份，故障节点key全部丢失

1、 故障节点如果没有备份，则丢失掉该组的所有数据，但是不影响其他组的运行，不会导致整个集群坏掉

2、 如有备份节点，则把其升为主节点，集群没有影响，正常运转（需要管理员手动变更从节点为主节点，最新版本添加HA功能）

没有主从复制的节点一旦故障，将导致整个集群不可用，无法写入或者读入任何key，无法进行数据重新分片

官网建议：至少3主3从

主从特点

基于redis本身的主从方案（利用发布/订阅机制，采用广播形式），

采用异步复制（asynchronous replication）的方案，无论是master端还是slave端都不会引起阻塞，但是肯定是存在数据丢失的情况

集群设计

1、 proxy部署高可用（多proxy结合keepalived+haporxy）

2、 redis层设计多主多从部署

1、 proxy部署（多proxy+zookeeper集群方案，并且结合keepalived+haporxy）

2、 codis-server部署多组，每组部署一主多从架构

利用redis本身部署集群：至少3主3从

HA方案

Proxy层已经有了，由上面的设计，redis层基于自带的HA解决方案（sentinel），这里不阐述sentinel机制

Proxy层已经有了，存储层本来设计就没有考虑自动HA切换，后面根据用户强烈的要求，目前添加codis-ha解决

自主监控自动切换(把sentinel功能搬迁过来)

故障监控

自带监控并告警

自带监控并告警

目前还没有提供

故障检测和故障转移时间

1、proxy配置文件设置：auto_eject_hosts: true

timeout: 400

server_failure_limit: 3

当proxy server超时400毫且3次重试机会，则认为该proxy节点坏掉，这样故障节点从hash环直接取下，并且清理该Key信息

故障转移耗时：400*3=1200毫秒

2、如果存储层加入sentinel做HA

（注意：底层redis转移故障之后，因proxy层不知道该配置信息已经变动，此时需要引入第四方工具redis-twemproxy-agent（node.js），更新Twemproxy配置，并重启）

故障转移耗时：

每个sentinel以每秒发送一次ping，配置down-after-milliseconds=2s，则主观认为下线3秒，然数量sentinel（配置文件可以配置）认可同意需要1s，再sentinel当选故障转移主持节点需要1秒，选出slave升级为master需要0.5秒，通过发布和订阅推送更新配置至其他sentinel并且配置更新需要1秒，这样总共耗时6.5秒。

1、 proxy层配置文件：

backend_ping_period=5 则表示5秒zookeeper没有等到pong回应就认为proxy已经坏掉

故障转移耗时：5秒

2、 存储层本来不设置自动故障迁移的

（后面添加codis-ha机制）

过程：codis-ha通过dashboard监控每组的存活状况，zookeeper能够快速知道存活的proxy节点，然后休眠3秒再次监控至重试3次，大致10秒左右时间切换，但是官方建议，还是不希望使用该解决方案，因主节点有问题，立马切换从节点为主节点可能导致数据丢失的情况。推荐大家使用手动切换，做好监控，确定好数据安全然后使用web界面或者命令手动操作（因用户的强烈要求才加入该解决方案）

Redis cluster拓扑结构是一张完全图：每个节点都持有N-1个输入TCP和N-1个输出TCP。

这里不阐述故障监控和切换的流程（比如FAIL状态、slave选主时机和cluster逻辑时钟等）

故障转移耗时（配置文件可以修改）

Node_time=2

Fail_report_validity_mult=3

标记master为pfail耗时2秒，升级pfail为fail状态耗时为2*3=6秒，选主前随机延期期望为1秒，收集足够多master投票为max((2*node_time),2)=4秒

这样总共耗时13秒。

功能限制

1、 不支持多key操作

2、 不支持MULTI/EXEC

3、 不支持EVAL

比较多，可以查看官方文档

1、 复杂的多KEY(set求并求交集)不能跨节点操作

2、 不支持MULTI/EXEC

3、 写丢失比较频繁

提供支持

不在维护

目前活跃状态

官网主打

客户端driver工具

保持不变（redis支持的都支持）

保持不变（redis支持的都支持）

只能支持cluster协议的客户端工具（目前官网上面说的是针对JAVA的是Jides，针对PHP的是Predis，而且不成熟）

概括

1、 轻量级

2、 在proxy层实现一致性哈希

3、 快速的故障转移

4、 可借助sentinel实现底层HA

5、 每次变更必须重启生效

1、 基于zookeeper的proxy高可用，zookeeper会记录整个集群的生存状态，则需要维护好zookeeper

2、 优势为动态水平扩容，平衡数据，在迁移的时候不影响业务访问和响应时间，这点很炫，也是它主打的方向

3、 Dashboard操作降低人失误率，图形直观查看信息

4、 强一致数据（也是设计的重点）

1、 性能好（也是设计的原则）

2、 无中心组织结构，有利有弊

3、 故障转移响应时间长

4、 有写丢失，比较频繁