Redis集群架构演变

redis最开始使用主从模式做集群，若master宕机需要手动配置slave转为master；后来为了高可用提出来哨兵模式，该模式下有一个哨兵监视master和slave，若master宕机可自动将slave转为master，但它也有一个问题，就是不能动态扩充；所以在3.x提出cluster集群模式。

1. 主从复制

主从架构

​ 主节点主要负责写的操作，从节点主要负责读以及复制数据到主节点。

主从复制的特点：

• 主从模式下，当某一节点损坏时，因为其会将数据备份到其它Redis实例上，这样做在很大程度上可以恢复丢失的数据。

• 主从模式下，可以保证负载均衡

• 主从模式下，主节点和从节点是读写分离的。使用者不仅可以从主节点上读取数据，还可以很方便的从从节点上读取到数据，这在一定程度上缓解了主机的压力。

• 从节点也是能够支持写入数据的，只不过从从节点写入的数据不会同步到主节点以及其它的从节点下。

主从复制的缺陷

• 一旦主节点宕机，其它节点不会竞争称为主节点，此时，Redis将丧失写的能力。这点在生产环境中，是致命的

• 主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡 ，缺陷是写的操作无法负载均衡，以及一旦主节点宕机，故障无法转移。

2. 哨兵机制

哨兵架构

​ 哨兵机制是基于主从模式做的一定变化，它能够为Redis提供了高可用性。在实际生产中，服务器难免不会遇到一些突发状况：服务器宕机，停电，硬件损坏等。这些情况一旦发生，其后果往往是不可估量的。而哨兵模式在一定程度上能够帮我们规避掉这些意外导致的灾难性后果。其实，哨兵模式的核心还是主从复制。只不过相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制——从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。器。简单说哨兵机制就是拥有自动故障转移的主从架构

哨兵机制的特点

• 监控：它会监听主服务器和从服务器之间是否在正常工作。

• 通知：它能够通过API告诉系统管理员或者程序，集群中某个实例出了问题。

• 故障转移：它在主节点出了问题的情况下，会在所有的从节点中竞选出一个节点，并将其作为新的主节点。

• 提供主服务器地址：它还能够向使用者提供当前主节点的地址。这在故障转移后，使用者不用做任何修改就可以知道当前主节点地址。

• sentinel也可以集群，部署多个哨兵，sentinel可以通过发布与订阅来自动发现Redis集群上的其它sentinel。sentinel在发现其它sentinel进程后，会将其放入一个列表中，这个列表存储了所有已被发现的sentinel。

• 集群中的所有sentinel不会并发着去对同一个主节点进行故障转移。只有当一个选中的从节点故障转移失败后，才会尝试下一个。

哨兵机制的缺陷

• 哨兵机制是在主从复制的基础上，利用哨兵实现了自动化的故障恢复。缺陷是写操作任然无法负载均衡；存储能力受到单机的限制。

3.高可用集群

cluster集群架构

Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。一组主从作为一个节点，而 一组主从节点中，可以是一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉

redis集群的特点

• 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。

• 节点的fail是通过集群中超过半数的节点检测失效时才生效。

• 客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

• redis-cluster把所有的物理节点映射到[0-16383]slot上（不一定是平均分配）,cluster 负责维护node<->slot<->value。

• Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中。

集群如何判断某个主节点挂掉

首先要说的是，每一个节点都存有这个集群所有主节点以及从节点的信息。它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个主节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用从节点。

判断节点挂掉是通过投票完成的，投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉。

集群如何选举新的主节点

选举的优先级依据依次是：网络连接正常->5秒内回复过INFO命令->10秒（down-after-milliseconds）内与主连接过的->从服务器优先级->复制偏移量->运行id较小的。选出之后通过slaveif no ont将该从服务器升为新主服务器。

选举出新的主节点后： 通过slaveof ip port命令让其他从节点器复制该新主节点的信息。

最后当旧的主节点重新连接后将其变为新的主节点的从节点。注意如果客户端与旧主节点服务器分隔在一起，写入的数据在恢复后由于旧主会复制新主的数据会造成数据丢失。

集群进入fail状态的判定

• 某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。
• 如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.
• 如果集群任意master挂掉,且当前master没有slave.集群进入fail状态

redis集群丢失数据的情况

• 如果某一个主节点和他所有的从节点都下线的话，redis集群就会停止工作了。redis集群不保证数据的强一致性，在特定的情况下，redis集群会丢失已经被执行过的写命令。
• 使用异步复制（asynchronous replication）是redis 集群可能会丢失写命令的其中一个原因，有时候由于网络原因，如果网络断开时间太长，redis集群就会启用新的主节点，之前发给主节点的数据就会丢失。

端与旧主节点服务器分隔在一起，写入的数据在恢复后由于旧主会复制新主的数据会造成数据丢失。

集群进入fail状态的判定

• 某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。
• 如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.
• 如果集群任意master挂掉,且当前master没有slave.集群进入fail状态

redis集群丢失数据的情况

• 如果某一个主节点和他所有的从节点都下线的话，redis集群就会停止工作了。redis集群不保证数据的强一致性，在特定的情况下，redis集群会丢失已经被执行过的写命令。
• 使用异步复制（asynchronous replication）是redis 集群可能会丢失写命令的其中一个原因，有时候由于网络原因，如果网络断开时间太长，redis集群就会启用新的主节点，之前发给主节点的数据就会丢失。