redis架构类型详解

redis架构图如下：

架构大致演变如下：单机-->主从-->哨兵-->高可用集群

单机：没什么好说的，一旦挂了就不可用，如果没有进行持久化，连数据都无法恢复，无抗灾能力...

主从：主节点发生问题时，可以通过切换从节点为主节点来恢复，具备一定的抗灾能力，但是缺点也很明显，需要手动修改redis.conf的配置和客户端连接代码，无法自动切换，在人工切换过程中，服务不可用

哨兵：通过哨兵集群监听redis节点信息，一旦发现master挂了，会自动进行主备切换，在切换过程中，服务会有短暂不可用，切换完成后恢复服务。缺点是上限有限，无法满足高并发。

高可用集群：支持横向拓展，分片，数据通过存储在不同的分片从而提高了并发上限，计算槽位 Hash slot = crc16(key) %16384

redis集群选举原理分析（了解）：

当slave发现自己的master变为fail状态时，会尝试进行failover，以期望变成新的master。由于挂掉的master下可能存在多个slave，从而多个slave竞争成为master的过程如下，

1、slave发现自己的master变成fail

2、将自己记录的集群currentEpoch进行+1，并广播failover_auth_request信息

3、其他主从节点收到该消息，只有主节点会响应，判断请求者的合法性后发送failover_auth_ack，对每一个epoch只发送一次ack

4、尝试failover的slave收集master返回的failover_auth_ack

5、slave收到超过半数的master的ack后变成新的master（这里解释了为什么集群至少需要3个节点，如果只有2个，当其中一个挂了，剩余只有一个主节点是无法选举成功的）

6、slave广播pong消息通知其他集群节点

从节点不是在主节点已进入fail状态就马上发起选举，而是有一定延迟，这个延迟确保我们等待fail状态在集群中传播，slave如果立即尝试选举，其他master或许还没意识到fail状态，可能会拒绝投票

延迟计算公式：DELAY=500ms+random(0~500ms)+SLAVE_RANK*1000ms

SLAVE_RANK表示此slave已经从master复制数据的总量的rank，rank越小代表已复制的数据越新。这种方式从理论可以让持有最新数据的slave首先发起选举，这样持有最新数据的slave有较大概率成为master。