Redis Cluster（Redis 3.X）设计要点

Redis 3.0.0 RC1版本号10.9号公布，Release Note
这个版本号支持Redis Cluster。相信非常多同学期待已久，只是这个版本号仅仅是RC版本号，要应用到生产环境，还得等等

Redis Cluster设计要点：

架构：无中心

Redis Cluster採用无中心结构，每一个节点都保存数据和整个集群的状态
每一个节点都和其它全部节点连接，这些连接保持活跃
使用gossip协议传播信息以及发现新节点
node不作为client请求的代理，client依据node返回的错误信息重定向请求

数据分布：预分桶

预分好16384个桶。依据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中
每一个Redis物理结点负责一部分桶的管理，当发生Redis节点的增减时，调整桶的分布就可以
比如，如果Redis Cluster三个节点A/B/C，则
Node A 包括桶的编号能够为: 0 到 5500.
Node B 包括桶的编号能够为: 5500 到 11000.
Node C包括桶的编号能够为: 11001 到 16384.
当发生Redis节点的增减时，调整桶的分布就可以。
预分桶的方案介于“硬Hash”和“一致性Hash”之间，牺牲了一定的灵活性。但相比“一致性Hash“，数据的管理成本大大减少

可用性：Master-Slave

为了保证服务的可用性，Redis Cluster採取的方案是的Master-Slave
每一个Redis Node能够有一个或者多个Slave。当Master挂掉时，选举一个Slave形成新的Master
一个Redis Node包括一定量的桶，当这些桶相应的Master和Slave都挂掉时，这部分桶相应的数据不可用

写

Redis Cluster使用异步复制
一个完整的写操作步骤：
1.client写数据到master
2.master告诉client "ok"
3.master传播更新到slave
存在数据丢失的风险：
1. 上述写步骤1）和2）成功后，master crash，而此时数据还没有传播到slave
2. 因为分区导致同一时候存在两个master，client向旧的master写入了数据。

当然。因为Redis Cluster存在超时及故障恢复机制。第2个风险基本上不可能发生

数据迁移

Redis Cluster支持在线增/减节点。
基于桶的数据分布方式大大减少了迁移成本，仅仅需将数据桶从一个Redis Node迁移到还有一个Redis Node就可以完毕迁移。

当桶从一个Node A向还有一个Node B迁移时。Node A和Node B都会有这个桶。Node A上桶的状态设置为MIGRATING，Node B上桶的状态被设置为IMPORTING
当客户端请求时：
全部在Node A上的请求都将由A来处理，全部不在A上的key都由Node B来处理。同一时候，Node A上将不会创建新的key

多key操作

当系统从单节点向多节点扩展时。多key的操作总是一个非常难解决的问题，Redis Cluster方案例如以下：
1. 不支持多key操作
2. 如果一定要使用多key操作。请确保全部的key都在一个node上。详细方法是使用“hash tag”方案
hash tag方案是一种数据分布的例外情况

Reference：
Redis cluster tutorial
Redis cluster Specification