- redis-cluster 可以不准确的理解为：N个主从架构在一起对外提供服务，每一个master节点都存储一部分数据（每个节点会分配特定的slot,key根据哈希算法确认存储在哪一个具体slot，每个master也有各自的slave）,相关概念后续会继续阐述。架构如下：
-
redis采用了虚拟节点机制，来让节点分配的更均匀。在圆环中，增加了对应节点的虚拟节点，然后完成了虚拟节点到真实节点的映射。假设现在计算得出了位置D，那么按照顺时针的顺序，我们找到的第一个节点就是C #1，最终数据实际还是会落在节点C上。通过增加虚拟节点的方式，使ABC三个节点在圆环上的位置更加均匀，平均了落在每一个节点上的概率。这样一来就解决了上文提到的数据存储存在不均匀的问题了，这就是一致性哈希的虚拟节点机制。
-
redis-cluster类一致性哈希算法： 一致性哈希是对2^32取模，而Redis Cluster则是对2^14（也就是16384）取模。Redis Cluster将自己分成了16384个Slot（槽位）。通过CRC16算法计算出来的哈希值会跟16384取模，取模之后得到的值就是对应的槽位，然后每个Redis节点都会负责处理一部分的槽位，就像下表这样。
| 节点 | 处理槽位 |
|---|---|
| A | 0 - 5000 |
| B | 5001 - 10000 |
| C | 10001 - 16383 |
- 每个Redis实例会自己维护一份slot - Redis节点的映射关系，假设你在节点A上设置了某个key，但是这个key通过CRC16计算出来的槽位是由节点B维护的，那么就会提示你需要去节点B上进行操作。
-
每个Redis节点每秒钟都会向其他的节点发送PING，然后被PING的节点会回一个PONG。默认情况下gossip的通信端口是redis client连接端口+10000，集群节点通过该端口进行信息交换。
-
gossip消息协议有以下几类：
| 节点 | 处理槽位 |
|---|---|
| MEET | 给某个节点发送MEET消息，请求接收消息的节点加入到集群 |
| PING | 每隔一秒钟，选择5个最久没有通信的节点，发送PING消息，检测对应的节点是否在线；同时还有一种策略是，如果某个节点的通信延迟大于了cluster-node-time的值的一半，就会立即给该节点发送PING消息，避免数据交换延迟过久 |
| PONG | 当节点接收到MEET或者PING消息之后，会回一个PONG消息给发送方，代表自己收到了MEET或者PING消息。同时，节点也可以主动的通过PONG消息向集群中广播自己的信息，让其他节点获取到自己最新的属性，就像完成了故障转移之后新的master向集群发送PONG消息一样 |
| FAIL | 用于广播自己的对某个节点的宕机判断，假设当前节点对A节点判断为宕机，就会立即向Redis Cluster广播自己对于A节点的判断，所有收到消息的节点就会对A节点做标记 |
| PUBLISH | 用于向指定的Channel发送消息，某个节点收到PUBLISH消息之后会直接在集群内广播，这样一来，客户端无论连接到任何节点都能够订阅这个Channel |
- gossip协议的优缺点如下
- 优点：
| 优点 | 描述 |
|---|---|
| 扩展 | 络可以允许节点的任意增加和减少，新增加的节点的状态最终会与其他节点一致。 |
| 容错性 | 由于每个节点都持有一份完整元数据，所以任何节点宕机都不会影响gossip的运行(机器不要大面积宕机就行哈) |
| 健壮性 | 与容错性类似，由于所有节点都持有数据，地位平台，是一个去中心化的设计，任何节点都不会影响到服务的运行 |
| 最终一致性 | 当有新的信息需要传递时，消息可以快速的发送到所有的节点，让所有的节点都拥有最新的数据 |
- 缺点： gossip将信息传播到所有的节点的时间复杂度为O(logN)，集群规模很大时，消息的同步时间就越久
