Redis高可用的三种实现方式

1.主从模式

2.哨兵模式
在主从模式中，一旦master节点发生宕机，为了保证高可用，需要找一个slave节点作为新的master节点。谁来确定宕机，选择哪一个slave节点，这些问题都没有解决。哨兵(sentinal)模式则是为了解决这些问题而产生的，它用于对主从模式中每个节点进行监控，当出现故障时通过投票机制，选择新的master节点，并将所有的slave节点连接到master节点

优点：哨兵机制，保证高可用。能够监控各个节点运行状况，进行自动故障转移。

缺点：
切换节点时，会发生数据的丢失。
数据量过大时，主从同步严重影响master的性能。数据写的操作都集中在master上，没有解决master写数据的压力

3.集群模式
​ 哨兵模式基本已经实现了高可用，但是每个节点都存储相同的内容，很浪费内存。而且，哨兵模式没有解决master写数据的压力。为了解决这些问题，就有了集群模式，实现分布式存储，每个节点存储不同的内容。集群部署的方式能自动将数据进行分片，每个master上放一部分数据，提供了内置的高可用服务，即使某个master宕机了，服务还可以正常地提供

​ 集群模式中数据通过数据分片的方式被自动分割到不同的master节点上，每个Redis集群有16384个哈希槽，进行set操作时，每个key会通过CRC16校验后再对16384取模来决定放置在哪个槽。数据在集群模式中是分开存储的，那么节点之间想要知道其他节点的状态信息，包括当前集群状态、集群中各节点负责的哈希槽、集群中各节点的master-slave状态、集群中各节点的存活状态等是通过建立TCP连接，使用gossip协议来进行集群信息传播。

​ 故障判断方法：判断故障的逻辑其实与哨兵模式有点类似，在集群中，每个节点都会定期的向其他节点发送ping命令，通过有没有收到回复来判断其他节点是否已经下线。具体方法是采用半数选举机制，当A节点发现目标节点疑似下线，就会向集群中的其他节点散播消息，其他节点就会向目标节点发送命令，判断目标节点是否下线。如果集群中半数以上的节点都认为目标节点下线，就会对目标节点标记为下线，从而告诉其他节点，让目标节点在整个集群中都下线。

优点：

无中心结构，部署简单。所有的Redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
可扩展性，可扩展master节点，释放单个master的写数据压力，节点可动态添加或删除。
能够实现自动故障转移，节点之间通过gossip协议交换状态信息，用投票机制完成slave到master的角色转换。