风之无穷社区，hp打印机售后电话，灰犀牛变乱
问题：
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尖兵的脚色来增强珍爱主节点了。如下图所示：
本文地址：http://www.wbwb.net/bianchengyuyan/210800.html 转载请注明出处！