Redis集群机制

1. Redis 集群是3.0之后才引入的，在3.0之前，使用哨兵（sentinel）机制来监控各个节点之间的状态。Redis 集群可以使用的功能是普通单机 Redis 所能使用的功能的一个子集；Redis 集群通常具有高可用、可扩展性、分布式、容错等特性。

2. redis的集群搭建参考博客：https://www.cnblogs.com/mafly/p/redis_cluster.html

3. redis集群架构图：

4. Redis 集群键分布算法使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 它们的编号为0、1、2、3……16382、16383，这个槽是一个逻辑意义上的槽，实际上并不存在。redis中的每个key都属于这 16384 个哈希槽的其中一个，存取key时都要进行key->slot的映射计算。

假设已经按照第2点成功搭建了一个集群，有6个节点，端口号分别为7001,7002,7003,7004,7005,7006，每个master节点至少有一个slave，即3主3从，假设7001(从节点为7004),7002(从节点为7705),7003(从节点为7006)三个节点为主节点，redis集群创建的时候会平均将16384个slot分配到3个master节点去，从节点是没有哈希槽的。7001节点的slot为0-5460，7002节点的slot为5461-10922，7003节点的slot为10923-16383。当客户端向集群中存储一个key时，redis集群使用集群公式来计算键 key 属于哪个槽：

HASH_SLOT（key）= CRC16(key) % 16384

redis的集群分区，最主要的目的是在移除、添加一个节点时对已经存在的缓存数据的定位影响尽可能的降到最小。redis将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点， 比如说：

• l如果用户将新节点 D 添加到集群中， 那么集群只需要将节点 A 、B 、 C 中的某些槽移动到节点 D 就可以了。
• 如果用户要从集群中移除节点 A ， 那么集群只需要将节点 A 中的所有哈希槽移动到节点 B 和节点 C ， 然后再移除空白（不包含任何哈希槽）的节点 A 就可以了。

因为将一个哈希槽从一个节点移动到另一个节点不会造成节点阻塞， 所以无论是添加新节点还是移除已存在节点， 又或者改变某个节点包含的哈希槽数量， 都不会造成集群下线，从而保证集群的可用性，并且支持动态扩容。

5. 集群节点属性：集群中每个Master node负责存储数据、集群状态，包括slots与nodes对应关系。Master nodes能够自动发现其他nodes，检测failure节点(彼此发送ping-pong)，当某个Master节点失效时，集群能将核实的Slave提升为Master。Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，所以Slaver的扩容只能提高读效率不能提高写效率。

6. 集群可用性：Redis集群通过partition来提供一定程度的可用性，当集群中的一部分节点失效或者无法进行通讯时，集群仍可以继续提供服务。这里有两点补充:

• 只要集群中大多数Master可达、且失效的Master至少有一个Slave可达，即集群非Fail状态，集群都是可用的。
• Redis集群的replicas migration机制可以将拥有多个Slave的Master的某个Slave，迁移到没有Slave的Master下，即Slave分布相对平衡，确保Master都有一定数量的Slave备份

集群状态什么时候处于“OK”，什么时候处于“FAIL”，节点什么时候可用等，详见下面的解释：

 当NODE_TIMEOUT时，触发failover，此时集群仍然可用的前提是：“大分区”（相对发生网络分区的Client-Master小分区端而言）端必须持有大部份Masters，且每个不可达的Master至少有一个Slave也在“大分区”端，且集群在小部分Nodes失效后仍然可以恢复有效性。举个例子：

集群有N个Master，且每个Master都有一个Slave，那么集群的可用性只能容忍一个Master节点被分区隔离，也就是说只有一个Master处于小分区端，当第二个Master节点被分区隔离之前扔保持可用性的概率为1-(1 /(N*2-1))，这里的意思是：当第一个节点失效后，剩余N*2-1节点，此时没有Slave的Master失效的概率为1 /(N*2-1)。比如有10个节点，每个Master有一个Slave，当2个节点被隔离或失效后，集群可用性的概率是：1/(10*2-1)=5.26%，此时集群不再可用。

为了避免上述情况发生，Redis Cluster提供了“replicas migration”机制，当Master节点发生failover后，集群会动态重新分配、平衡Slaves的分布，有效地提高了集群的可用性。从节点选举逻辑：

• 节点是已下线Master对应的Slave

• FAIL状态的Master负责的hash slot 非空

• 主从节点之间的replication link断线的时长不能超过NODE_TIMEOUT * REDIS_CLUSTER_SLAVE_VALIDITY_MULT

7. Redis集群实现的核心思想和思路是通过消息的交互（Gossip）实现去中心化(指的是集群自身的实现，不是指数据)，通过Hash槽分配，实现集群线性可拓展。

8. 参考博客：

• Redis集群搭建:https://www.cnblogs.com/mafly/p/redis_cluster.html
• 三张图秒懂Redis集群设计原理:https://blog.csdn.net/yejingtao703/article/details/78484151
• Redis集群实现原理探讨:https://segmentfault.com/p/1210000009708869/read
• Redis集群操作:https://www.cnblogs.com/hjwublog/p/5681700.html#autoid-2-8-0