为什么有了主从架构后还需要Redis Cluster架构
主从架构的容量瓶颈
我们回忆一下主从架构（一主多从）中，master节点负责写入数据，并同步给slave节点，然后slave节点负责处理读请求；可以通过slave节点的扩容，提高主从架构的读QPS；同时基于哨兵可以确保主从架构的高可用性。
可以说主从 + 哨兵的一套组合拳，既能抗住高并发的读请求，同时也可以实现高可用性；但是主从架构的数据来源其实是master，而主从架构中只有一个master节点，就导致了redis存储的数据容量是很有限的。在海量数据场景下，如果单单使用主从+哨兵的架构，肯定是不行的。
这就是我们所说的主从架构容量瓶颈。
所以我们需要一个新的架构来支撑海量数据。
读者可以先思考一下，单个master节点的数据容量是有限的，那么我们搞多个master节点，并且每个master节点中的数据都是不同的，这样不就可以支撑更大的数据量了吗？
再说，这个新的架构支撑了更多的数据量，同时你至少也需要支撑高可用吧，如果连高可用性都不能保障的话，要这么大的数据量有什么用，一旦某个master节点发生故障，那么整个架构就不可用了，这也太坑爹了吧。所以新的架构也要做到高可用。
这个新的架构，也就是我们接下来要讲解的Redis Cluster。
Redis Cluster原理
基本介绍
Redis Cluster包含多个master节点，每个master节点挂在多个slave节点，多个master可以支撑更大的数据量
横向扩容支持更大数据量：如果我们需要支撑更多的数据量，那么添加新的master和slave节点就好了
当master节点挂掉后，Redis Cluster会从master对应的slave节点中选举出一个新的master完成故障转移（高可用）
redis cluster默认是不支持slave节点读或者写的，slave节点更多是为了master发生故障时备用的节点
节点通信
通信流程
维护元信息的两种方式介绍
在分布式存储中需要提供维护节点元信息的机制，常见的元信息维护方式为：集中式和P2P。Redis Cluster使用的是P2P的gossip协议。
节点元信息主要包括：节点负责哪些数据、是否出现故障等状态信息。
我们来对比一下这两种维护元信息的方式。
集中式：将元信息集中存储在一个外部组件里，比如ZooKeeper
- 集中式的优点在于元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到;
- 缺点在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力。
gossip协议：
- 好处：元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力
- 缺点：元数据更新有延时，可能导致集群的一些操作会有一些滞后
10000端口
每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口
每个节点隔一段时间都会往另外几个节点发送
ping消息，同时其他几点接收到ping之后返回pong
节点交换的信息
包含故障信息，节点的增加和移除，
hash slot信息等等
gossip协议详解
gossip消息
gossip协议包含多种消息，包括ping、pong、meet、fail等等。
meet：某个节点发送meet消息给新加入的节点，让新节点加入到集群中，然后新节点就会与其他节点通信ping：每个节点每秒都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元信息。（节点之间互相交换元信息）节点之间互相通过
ping交换元信息。每个节点每秒都会频繁发送
ping给其他的节点，频繁的互相之间交换数据，互相进行元数据的更新
pong：返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新fail：某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了
ping消息的深入理解：
ping很频繁，而且要携带一些元数据，所以可能会加重网络负担
考虑到网络开销，每个节点每秒会执行10次
ping时，每次会选择5个最久没有通信的其他节点当然如果发现与某个节点通信延时达到了
cluster_node_timeout/ 2，那么立即发送ping，避免数据交换延时过长，落后的时间太长了
- 比如说，两个节点之间都10分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题；所以
cluster_node_timeout可以调节，如果调节比较大，那么会降低发送的频率每次
ping，一个是带上自己节点的信息，还有就是带上1/10其他节点的信息，发送出去，进行数据交换
高可用性与主备切换原理
redis cluster的高可用的原理，几乎跟哨兵是类似的。
1. 判断节点宕机
如果一个节点认为另外一个节点宕机，那么就是
pfail，主观宕机如果多个节点都认为另外一个节点宕机了，那么就是
fail，客观宕机可以类比到哨兵中的
sdown、odown
如果在cluster-node-timeout内，某个节点一直没有返回pong，那么就被认为pfail。
如果一个节点认为某个节点pfail了，那么会在gossip ping消息中，ping给其他节点，如果超过半数的节点都认为pfail了，那么就会变成fail（客观宕机）。
2. 从节点过滤
对宕机的master node，从其所有的slave node中，选择一个切换成master node
检查每个slave node与master node断开连接的时间，如果超过了
cluster-node-timeout*cluster-slave-validity-factor，那么就没有资格切换成master
3. 从节点选举
每个从节点，都根据自己对master复制数据的
offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。所有的master node开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。
从节点执行主备切换，从节点切换为主节点（故障转移）
哨兵的从节点选举：对所有从节点进行排序，slave
priority，offset，run id
总结
本文先从主从架构的不足之处引出了Redis Cluster，然后介绍了Redis Cluster的原理，主要包含gossip协议以及高可用实现原理这两个点。本文并没有详细讲述Redis Cluster中比较重要的数据分片算法：hash slot算法，后面会专门写一篇文章讲述一下。
参考资料
- https://redis.io/topics/cluster-tutorial
- 《Redis开发与运维》p274—p345
- 《中华石杉亿级流量》
本文使用 mdnice 排版
