Redis的主从复制
Redis的主从复制模式下， 一旦主节点由于故障不能提供服务， 需要人工将从节点晋升为主节点， 同时还要通知应用方更新主节点地址， 对于很多应用场景这种故障处理的方式是无法接受的。 可喜的是Redis从2.8开始正式提供了Redis Sentinel（哨兵） 架构来解决这个问题。
Redis Sentinel是官方从Redis 2.6版本提供的高可用方案，在Redis主从复制集群的基础上，增加Sentinel集群监控整个Redis集群。当Redis集群master节点发生故障时，Sentinel进行故障切换，选举出新的master，同时Sentinel本身支持高可用集群部署
优点在于支持集群高可用，高性能读写，缺点在于没有实现数据分片，每个节点需要承载完整数据集，负载能力受单个Redis服务器限制，仅支持通过增加机器内存实现垂直扩容，不支持水平扩展,如图：
主从复制的问题
Redis的主从复制模式可以将主节点的数据改变同步给从节点， 这样从节点就可以起到两个作用：
第一， 作为主节点的一个备份， 一旦主节点出了故障不可达的情况， 从节点可以作为后备“顶”上来， 并且保证数据尽量不丢
失（主从复制是最终一致性） 。
第二， 从节点可以扩展主节点的读能力， 一旦主节点不能支撑住大并发量的读操作， 从节点可以在一定程度上帮助主节
点分担读压力。
但是主从复制也带来了以下问题：
·一旦主节点出现故障， 需要手动将一个从节点晋升为主节点， 同时需要修改应用方的主节点地址， 还需要命令其他从节点去复制新的主节点， 整个过程都需要人工干预。
·主节点的写能力受到单机的限制。
·主节点的存储能力受到单机的限制。
高可用
Redis主从复制模式下， 一旦主节点出现了故障不可达， 需要人工干预进行故障转移， 无论对于Redis的应用方还是运维方都带来了很大的不便。对于应用方来说无法及时感知到主节点的变化， 必然会造成一定的写数据丢失和读数据错误， 甚至可能造成应用方服务不可用。 对于Redis的运维方来说， 整个故障转移的过程是需要人工来介入的， 故障转移实时性和准确性上都无法得到保障， 图展示了一个1主2从的Redis主从复制模式下的主节点出现故障后， 是如何进行故障转移的， 过程如下所示。
1） 如图所示， 主节点发生故障后， 客户端（client） 连接主节点失败， 两个从节点与主节点连接失败造成复制中断。
2） 如图所示， 如果主节点无法正常启动， 需要选出一个从节点（slave-1） ， 对其执行slaveof no one命令使其成为新的主节点。
3） 如图所示， 原来的从节点（slave-1） 成为新的主节点后， 更新应用方的主节点信息， 重新启动应用方。
4） 如图所示， 客户端命令另一个从节点（slave-2） 去复制新的主节点（new-master）
5） 如图9-5所示， 待原来的主节点恢复后， 让它去复制新的主节点。
上述处理过程就可以认为整个服务或者架构的设计不是高可用的， 因为整个故障转移的过程需要人介入。 考虑到这点， 有些公司把上述流程自动化了， 但是仍然存在如下问题：
第一， 判断节点不可达的机制是否健全和标准。
第二， 如果有多个从节点， 怎样保证只有一个被晋升为主节点。
第三，通知客户端新的主节点机制是否足够健壮。 Redis Sentinel正是用于解决这些问题。