redis cluster 总体架构：
1、在这个图中，每一个redis服务器节点，它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点，对其进行存取和其他操作。
2、集群节点属性
集群中每个Master node负责存储数据、集群状态，包括slots与nodes对应关系。Master nodes能够自动发现其他nodes，检测failure节点，当某个Master节点失效时，集群能将核实的Slave提升为Master。下图是节点的关联信息，节点定时会将这些信息发送给其他节点：
从左至右分别是：
节点ID、IP地址和端口、节点角色标志、最后发送ping时间、最后接收到pong时间、连接状态、节点负责处理的hash slot。
3、各节点通过Gossip进行通讯
cluster 服务端节点直接使用 gossip 协议进行节点间通信，可以自动识别出ip/port的变化，并通过Gossip（最终一致性，分布式服务数据同步算法）协议广播给其他节点知道。Gossip也称“病毒感染算法”、“谣言传播算法”。
（1）主要使用 cluster meet ,ping ,pong 三个命令来完成。
（2）通信由 meet 或 ping 命令发起。
（3）meet 命令主要用于节点间的初次通信(?待确认)。
（4）节点间的握手，类似于 tcp 的三次握手，都会确保对方知道自己已经收到消息。
（5）定时任务 clusterCron 会向随机节点发其 ping 通信（标记下线，疑似下线，即获知其他节点的存活情况）。
（6）在定时心跳通信时，会附带上随机两个节点的信息，包括 ip,端口，以及节点所包含的槽位信息
（7）收到心跳信息的节点，会判断附加的节点信息是否在本地记录中，
本地无记录，会发其 meet 通信(握手)；
本地有记录，会进行更新(判断 epoch)。
（8）数据结构
使用 bitmap 来表示一个节点持有的槽位信息；
集群消息处理函数 clusterProcessPacket。
4、 Redis 集群的数据分片
Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.
Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:
- 节点 A 包含 0 到 5500号哈希槽.
- 节点 B 包含5501 到 11000 号哈希槽.
- 节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。
下面对redis cluster原理进行深入讲解。
