每个Redis实例会自己维护一份slot - Redis节点的映射关系，假设你在节点A上设置了某个key，但是这个key通过CRC16计算出来的槽位是由节点B维护的，那么就会提示你需要去节点B上进行操作。
Redis Cluster如何做到高可用
不知道你思考过一个问题没，如果Redis Cluster中的某个master节点挂了，它是如何保证集群自身的高可用的？如果这个时候我们集群需要扩容节点，它该负责哪些槽位呢？我们一个一个问题的来看一下。
集群如何进行扩容
我们开篇聊过，Redis Cluster可以很方便的进行横向扩容，那当新的节点加入进来的时候，它是如何获取对应的slot的呢？
答案是通过reshard（重新分片）来实现。reshard可以将已经分配给某个节点的任意数量的slot迁移给另一个节点，在Redis内部是由redis-trib负责执行的。你可以理解为Redis其实已经封装好了所有的命令，而redis-trib则负责向获取slot的节点和被转移slot的节点发送命令来最终实现reshard。
假设我们需要向集群中加入一个D节点，而此时集群内已经有A、B、C三个节点了。
此时redis-trib会向A、B、C三个节点发送迁移出槽位的请求，同时向D节点发送准备导入槽位的请求，做好准备之后A、B、C这三个源节点就开始执行迁移，将对应的slot所对应的键值对迁移至目标节点D。最后redis-trib会向集群中所有主节点发送槽位的变更信息。
高可用及故障转移
Redis Cluster中保证集群高可用的思路和实现和Redis Sentinel如出一辙，感兴趣的可以去看我之前写的关于Sentinel的文章Redis Sentinel-深入浅出原理和实战。
简单来说，针对A节点，某一个节点认为A宕机了，那么此时是主观宕机。而如果集群内超过半数的节点认为A挂了， 那么此时A就会被标记为客观宕机。
一旦节点A被标记为了客观宕机，集群就会开始执行故障转移。其余正常运行的master节点会进行投票选举，从A节点的slave节点中选举出一个，将其切换成新的master对外提供服务。当某个slave获得了超过半数的master节点投票，就成功当选。
当选成功之后，新的master会执行slaveof no one来让自己停止复制A节点，使自己成为master。然后将A节点所负责处理的slot，全部转移给自己，然后就会向集群发PONG消息来广播自己的最新状态。
按照一致性哈希的思想，如果某个节点挂了，那么就会沿着那个圆环，按照顺时针的顺序找到遇到的第一个Redis实例。
而对于Redis Cluster，某个key它其实并不关心它最终要去到哪个节点，他只关心他最终落到哪个slot上，无论你节点怎么去迁移，最终还是只需要找到对应的slot，然后再找到slot关联的节点，最终就能够找到最终的Redis实例了。
那这个PONG消息又是什么东西呢？别急，下面就会聊到。
简单了解gossip协议
这就是Redis Cluster各个节点之间交换数据、通信所采用的一种协议，叫做gossip。
gossip: 流言、八卦、小道消息
gossip是在1989年的论文上提出的，我看了一堆资料都说的是1987年发表的，但是文章里的时间明确是1989年1月份发表。
感兴趣的可以去看看Epidemic Algorithms for Replicated . Database Maintenance，在当时提出gossip主要是为了解决在分布式数据库中，各个副本节点的数据同步问题。但随着技术的发展，gossip后续也被广泛运用于信息扩散、故障探测等等。
Redis Cluster就是利用了gossip来实现自身的信息扩散的。那使用gossip具体是如何通信的呢？
很简单，就像图里这样。每个Redis节点每秒钟都会向其他的节点发送PING，然后被PING的节点会回一个PONG。
gossip协议消息类型
Redis Cluster中，节点之间的消息类型有5种，分别是MEET、PING、PONG、FAIL和PUBLISH。这些消息分别传递了什么内容呢？我简单总结了一下。
使用gossip的优劣
既然Redis Cluster选择了gossip，那肯定存在一些gossip的优点，我们接下来简单梳理一下。
gossip可以在O(logN) 轮就可以将信息传播到所有的节点，为什么是O(logN)呢？因为每次ping，当前节点会带上自己的信息外加整个Cluster的1/10数量的节点信息，一起发送出去。你可以简单的把这个模型抽象为：
当然，gossip仍然存在一些缺点。例如消息可能最终会经过很多轮才能到达目标节点，而这可能会带来较大的延迟。同时由于节点会随机选出5个最久没有通信的节点，这可能会造成某一个节点同时收到n个重复的消息。
总结
总的来说，Redis Cluster相当于是把Redis的主从架构和Sentinel集成到了一起，从Redis Cluster的高可用机制、判断故障转移以及执行故障转移的过程，都和主从、Sentinel相关，这也是为什么我在之前的文章里说，主从是Redis高可用架构的基石。
- END -