Redis3.0 集群模式 容错 简析

Redis-cluster

3.0cluster特性：

       节点自动发现（能够自动分割你多个节点之间的数据集）

       Slave-master选举，集群容错（当节点的一个子节点挂掉后无法与其他集群中机器通信时，不会影响集群功能。）

选举过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉；a:如果集群中任意master挂掉，且当前master没有slave，集群进入fail状态。b:如果集群中超过半数的master挂掉，无论是否有slave集群都会进入fail状态。

       Hotredharding在线分片（不使用一致性哈希，redis集群的每个节点负责hash slot的一个顺序子集，可以更方便的添加或删除集群中的节点。如果想要添加新节点，只需要把一些hash slot从其他节点均分一些到新节点上。如果想要删除旧节点，只需要将这台节点上的hashslots转移到其他节点上，当该节点上的hash slot为空时，即可以完全删除。而且将hash slot从一个节点移动到另一个节点不需要停止操作，所以转换之间不需任何停机时间。）

Redis Cluster通过hash slot将数据根据主键来分区，所以一条key-value数据会根据算法自动映射到一个hash slot。我们可以选择cluster addslots来分配hash slot，该命令的语法为cluster addslots slot1[slot2] ... [slotN]。也可我们在执行Redis服务器启动的目录下找到名字为nodes-6379.conf的配置文件，针对Redis Cluster Node1上nodes-6379.con发的内容，修改内容如下：cda76a0a094d2ce624e33bed7f3c75689a4128fd:0 myself,master - 0 0 connected 0-5000（注意是在自身节点的描述，也就是包含了myself那一行的后面追加hash slot的范围）。类似的，Redis Cluster Node2上nodes-6379.conf文件中追加5001-10000，Redis Cluster Node3上nodes-6379.conf文件中追加10001-16383。经过这样的配置后，Redis Cluster Node1负责存储0至5000之间的所有hash slots，RedisCluster Node2负责存储5001至10000之间的所有hash slots，Redis Cluster Node3负责存储10001至16383的所有hashslots。    保存以上修改，通过Redis客户端将三个Redis服务器重启，再次执行命令cluster nodes和cluster info，我们就可以看到集群的状态已经为ok了。

 

ASK转向/MOVED转向机制

3.0架构细节：

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

       所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

       节点的fail是通过集群中超过半数的节点检测失效时才生效.

       客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

       redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value（cluster通信端口开放给所有需要通信的集群，集群中的所有节点必须可以访问cluster节点）

 

redis集群主从模式

为了保证服务的可用性，Redis Cluster采取的方案是的Master-Slave
每个RedisNode可以有一个或者多个Slave。当Master挂掉时，选举一个Slave形成新的Master

一个Redis  Node包含一定量的桶，当这些桶对应的Master和Slave都挂掉时，这部分桶对应的数据不可用

              例：创建的时候为每一个master添加一个slave节点，即ABC是master节点，A1，B1，C1是slave节点，如果节点挂掉，集群还会继续正常运行，A1会替代A的工作。但是如果在同一时间内A和A1一起挂掉，将不能正常工作。

 

Redis集群一致性

       不能保证强劲的一致性。这就意味着在实际生产环境中redis客户端可能会发生不能写的状况。首要原因就是因为redis集群是异步复制的

 

写数据

RedisCluster使用异步复制
一个完整的写操作步骤：

1.    client写数据到master
2.master告诉client "ok"
3.master传播更新到slave

存在数据丢失的风险：

1.    上述写步骤1）和2）成功后，mastercrash，而此时数据还没有传播到slave
2. 由于分区导致同时存在两个master，client向旧的master写入了数据。
当然，由于Redis Cluster存在超时及故障恢复机制，第2个风险基本上不

能发生

数据迁移

Redis Cluster支持在线增/减节点。
基于桶的数据分布方式大大降低了迁移成本，只需将数据桶从一个Redis Node迁移到另一个Redis Node即可完成迁移。
当桶从一个Node A向另一个Node B迁移时，NodeA和Node B都会有这个桶，Node A上桶的状态设置为MIGRATING，Node B上桶的状态被设置为IMPORTING
当客户端请求时：
所有在Node A上的请求都将由A来处理，所有不在A上的key都由Node B来处理。同时，Node A上将不会创建新的key