Redis高可用为什么要把哨兵独立出来，而不是在Redis自身中实现？分布式架构有哪些为了高可靠而存在的监控角色？

01 分布式架构中心化模式

从集群的分布式模式来看，往往分布式的中心化存储，其监控模式都推荐隔离开业务数据处理，形成独立管理者或者状态监控者，例如：分布式文件系统HDFS的namenode、zookeeper、journalnode；MongoDB副本集模式中的仲裁；RocketMQ的nameserver；以及Redis的哨兵。

如下图所示：为了保证HDFS namenode双节点高可靠，Hadoop的HA护城河包括了zookeeper、journalnode、zkfc，已经算是武装到了牙齿。

这与分布式中心化的需求有关，主的高可靠在集群中非常重要，因为一旦主节点挂掉了，就需要马上有副本节点能顶上来，否则集群就彻底崩坍了，所以这个时候谁能去监控主节点是否挂掉，同时让从节点顶上来就是很关键的角色了，若这个监控者角色本身还存在着数据业务处理任务，那么就会让监控者的运行过程变得复杂，出现服务故障的几率就会升高。

若监控者出现三长两短的事故，那么整个集群就等于处于无保护状态。redis的哨兵其实就是扮演这个监控者的角色。因此redis哨兵服务本身的角色需求就应该是目的单一，并且尽可能降低自身的故障风险。

如下图所示：Redis1-4个节点，统一由一个哨兵（Sentinel）监控，当Redis1作为主出现故障而下线，那么Redis2-4的从节点复制工作就会中止。哨兵安排Redis4升级为主节点，继续为客户端提供服务，并继续Redis2-3的数据复制

02 分区(分片)作为主从关系的分布式架构

分布式中心化集群中，也有一种特殊模式的存在，那就是Kafka，Elasticsearch的一种分区（分片）为核心的主从模式，Leader节点实际上没有特别重的中心化协调需求，往往选举出的主节点就是协调管理集群。

例如Kafka的Leader主要是在创建Topic、分区重分配等命令操作过程扮演着领导者的角色，其他时间Leader节点是集群中一个对等的brocker，接收客户端的Topic分区写和读。

这种方式降低了必须主节点统一受理数据写入，产生的业务数据操作与负载的风险，像Redis、MongoDB、MySQL在主从模式下，必须主节点承担所有的写入负载和副本节点的数据复制负载。Kafka、Elasticsearch集群通过各个节点的数据分区（分片）形成主/从模式，就让这种数据读写负载的风险由集群各个节点共担了。

例如：Elasticsearch写入的时候，节点根据主分片来负载数据写入，并向其他节点的从分片复制数据形成副本。查询的时候实现集群多节点的分片并行查询，Leader节点协调由哪些节点的分片副本参与其中一路的分片查询，最终再将不同节点的查询结果汇聚到一个节点上提供给客户端。

采用此主/副分区（分片）的设计思想来分散单主的风险，是介于中心化和去中心化之间的一直分布式模式，但本质上还是中心化的管理，也就不需要再独立出来一个类似Redis哨兵的角色来加强保护主节点了。如下图所示：

最后一种是真正去中心化的分布式集群，就是典型的节点包括了状态维持、数据操作了。例如：Redis Cluster就是典型的去中心化集群模式，每个节点都要考虑集群一致性问题，再比如说Glusterfs这种分布式文件系统，也是典型的去中心化存储，不需要单独的状态监控，每个节点自身就是，集群的管理往往都是通过半数以上的投票进行决策。