（1）首先sentinel也属于一种redis服务器，只不过启动时加载的配置文件不同。配置文件里包括了监控的主服务器列表（对，可以是多个主服务器，即就是多个集群）。
（2）sentinel通过配置文件中的主服务器IP：端口号，建立链接和订阅，就是一个双向的通道
（3）sentinel默认每10秒，向建立链接的主服务器，发送INFO命令；主服务器收到命令，返回主服务器信息。
可以看到，返回了主服务器的运行ID，重要的是：同步主服务器的从节点信息
（4）从步骤（3）中获取到的从节点信息，从节点的IP和端口。sentinel和从节点建立链接和订阅
（5）sentinel默认每10秒，向建立链接的从服务器，发送INFO命令，从服务器接收到命令后，返回从服务器信息
主要包括了从服务器对应的master节点的地址：端口号，偏移量
（6）sentinel与主服务器和从服务器建立了链接和订阅，可以向主从服务器发送命令，也可以接收主从服务器的广播
订阅命令：subscribe _sentinel_:hello
通道名：hello
sentinel对hello频道的订阅会一直持续到sentinel和服务器之间的链接断开为止
sentinel向服务器通道发送的消息，其他与该服务器建立订阅关系的sentinel也会收到订阅通知，sentinel自己也会收到自己发出的消息的订阅通知
（7）sentinel默认会每两秒一次，向所有建立链接和订阅的主从服务器，发送广播消息
命令：publish_sentinel__:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>"
可以看到主要包含
s_ip : sentinel自己 IP地址
s_port : sentinel自己端口号
s_runid : sentinel自己的运行ID
s_epoch : sentinel当前的配置纪元
m_name, m_ip, m_port, m_epoch : 当前监控服务器的名称（主或者从）、IP地址、端口号、当前配置纪元
这个消息，也会被其他订阅该通道的sentinel收到
sentinel在接收到订阅消息后（就是上文中自己与别的sentinel，publish的消息），首先过滤掉自己发，然后接收别人的消息，就能获取监听改主服务器的所有sentinel节点
（8）通过上一步，sentinel能够感知到其他监控主服务器的sentinel节点，然后和其他sentinel建立连接，最终，所有监视主服务器的sentinel节点组成了一个相关连接的网络！
sentinel会默认每1s向自己所建立连接的服务器发送PING命令，这些服务器包括（监视master的其他sentinel，master、salve服务器），根据收到的返回值，来确定目标服务器的状态
常见返回值：+PONG、-LOADING、-MASTERDOWN，含义在此处先不关注
判定条件：目标服务器在一定的时间内（配置文件字段：down-after-milliseconds的值），一直返回“失败”
对失败的定义：
（1）目标服务器没有在规定时间内返回（该时间可配置）
（2）目标服务器返回了上述三种返回值之外的值
确定一个目标服务器失败之后，会在sentinel自己的实例表中记录该实例的状态，用：
SRI_S_DOWN表示，S=subjective客观
注：一个master服务器会被多个sentinel监控，多个sentinel可能设置了不同的
down-after-milliseconds
和我们设想的一样，单一的sentinel并不能决定目标master服务器的生死存亡，会拿着自己实例表里的“客观”下线的服务器地址和端口，去向同样监控这台服务器的sentinel询问，看看“别人”这个服务器到底下线没？ 当能够从别的sentinel那里询问到“足够数量”的已下线（客观下线或者主观下线）结果后，sentinel就可以判断目标服务器真的下线了，就可以执行故障转移了。
（1）sentinel发送命令is-master-down-by-addr
SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>
发送的目标：监控master服务器的其他sentinel
参数解析：ip、port=自己监控的master服务器的IP，端口，current_epoch=源sentinel当前的配置纪元，runid=源sentinel的唯一标识ID
（2）sentinel对命令is-master-dowm-by-addr的回复
1) <down_state> ：下线的状态，0-未下线，1-已下线
2) <leader_runid> ：当前sentinel的局部leader，为 “” 时表示没有leader
3) <leader_epoch> ：当前sentinel的局部leader的配置纪元，当没有leader时，该项为0
（3）sentinel收到命令is-master-down-by-addr的回复后
sentinel收到足够数量（可配置）的“已下线”回复（即down_state=1），就会在自己的实例表里将对应的master服务器状态（flags）设置为 SRI_O_DOWN，O=Objective。
监控同一个master服务器的sentinel，对客观下线的条件可以不一致，即收到多少已下线回复才认定客观下线，可以不尽相同。
由于监控同一个master服务器的sentinel有很多，并不能决定是哪个sentinel去执行故障转移，所以需要多个sentinel进行选leader头结点。
具体步骤：
(1)sentinel通过向其他sentinel节点发送is-master-down-by-addr命令，已经可以判断当前master服务器是否客观下线
（2）已经判断master服务器客观下线的sentinel，再次向其他节点发送
is-master-down-by-addr命令，携带自己的runId和配置纪元
这里再复习一遍命令 ：
sentinel is-master-down-by-addr <ip>,<port>,<cur_epoch>,<runid>
（3）目标sentinel收到源sentinel的 is-master…命令之后，执行以下判断
1>判断epoch和自己的纪元是否相等，不相等直接舍弃这条命令
2>判断自己的配置表里是否有局部leader，没有的话，将源sentinel的runid设置为自己的局部了leader
如果已经有了局部leader，那么会返回自己的局部leader的信息
3>对源sentinel的is-master-down-by-addr命令进行回复
示例：
源sentinel向目标sentinel发送命令，
SENTINEL is-master-down-by-addr 127001 8080 0 11522852334a
源sentinel收到命令的回复
1
11522852334a
0
表示有一个sentinel将自己成功设置成为leader（需要把返回的runid和自己的runid比对）
4>当过半的sentinel将自己成功设置为局部leader，标识选主成功，如果在一段时间内没有收到过半的成功数，那么会进行下一轮命令的发送，epoch递增+1
例如，共有10个sentinel监视同一个master服务器，其中一个sentinel必须收到10/2+1=6个及以上的成功数，才能认为自己成功当选leader
（1）筛选master节点的备胎（即就是哪些slave节点可以成为新的master）
选择master节点备胎就一个要求，数据尽量完整，状态尽量好
1>删除，客观下线或者主观下线的slave服务器
2>删除，在最近5s没有回复过头sentinel节点的INFO命令的slave服务器
剩下的slave服务器，根据优先级进行排序，遇到优先级一样的，再根据偏移量排序（目的是筛选出和master服务器数据较同步的slave服务器）。再遇到偏移量一样的，继续根据runid排序，找出runid最小的（没有什么依据，只是个排序），至此，可以作为master的slave服务器就筛选好了。
（2）slave服务器升级为master
头sentinel向步骤（1）中筛选出来的slave服务器发送slaveof_no_one，发送完该转移命令。之后，头sentinel每秒一次的频率向上述slave服务器发送INFO命令，观察INFO命令返回的role字段，看是否变为master，变为master表示成功升级为master服务器。
（3）修改原slave服务器列表的复制/同步目标
头sentinel向原slave服务器列表发送命令：
slave of 127001:8080，修改slave的复制目标
（4）修改已下线的master服务器为新master的slave节点
头sentinel保持对已下线master的监控，当已下线master重新上线（对PING命令有回复），就对他发送slave of 127001命令，让其成为slave。
至此，故障转移全部结束。
0Redis主从架构的问题
1哨兵服务介绍
2架构图
3主从服务搭建
4配置哨兵服务
5启动哨兵服务
6验证哨兵服务
对于Redis的主从架构而言，无法实现 master 和 slave 角色的自动切换， 即当 master 出现 redis 服务异常、主机断电、磁盘损坏等问题导致 master 无法使用，而 redis 高可用无法实现自故障转移(将 slave 提升为 master)，需要手动改环境配置才能切换到 slave redis 服务器。另外无法横向扩展 Redis 服务的并行写入性能， 当单台 Redis 服务器性能无法满足业务写入需求的时候就必须需要一种方式解决此问题。
1master和slave角色的无缝切换，让业务无感知从而不影响业务使用
2可以横向动态扩展Redis服务器, 从而实现多台服务器并行写入以实现更高并发的目的。
Sentinel进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，其已经被集成在 redis26+的版本中，Redis的哨兵模式到了28版本之后就稳定了下来。一般在生产环境也建议使用Redis28以后版本。哨兵(Sentinel)是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master。每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，英文名称：Subjective Down，简称SDOWN。有主观宕机，肯定就有客观宕机。当“哨兵群”中的多数 Sentinel 进程在对 Master 主服务器做出 SDOWN 的判断，并且通过SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是“客观宕机”，英文名称是： Objectively Down， 简称 ODOWN。通过一定的 vote 算法，从剩下的 slave 从服务器节点中，选一台提升为 Master 服务器节点，然后自动修改相关配置，并开启故障转移（failover）。Sentinel 机制可以解决 master 和 slave 角色的切换问题。
安装
修改配置文件
启动服务
192168177139
192168177140
其他地方配置和主服务器一致
启动服务
查看主从状态
MASTER
SLAVE1
SLAVE2
MASTER
SLAVE1
SLAVE2
主服务器
SLAVE1：升级为主服务器
SLAVE2：主服务器变为node10
主服务器
从服务器
hdfs的主服务器名称：由一个NameNode和若干个DataNode组成的。
其中NameNode作为主服务器，管理文件系统的命名空间和客户端对文件系统的访问 *** 作；集群中的DataNode管理存储的数据。
对于集群来说，取决于集群中所有DataNode节点的硬盘大小之和。但是需要注意考虑集群的备份数量，假设备份数量为3，集群总容量为3TB,则实际可以存储1TB的文件。
名字节点和数据节点：
这些块被存储在一组数据节点中。名字节点用来 *** 作文件命名空间的文件或目录 *** 作，如打开，关闭，重命名等等。它同时确定块与数据节点的映射。数据节点负责来自文件系统客户的读写请求。数据节点同时还要执行块的创建，删除，和来自名字节点的块复制指令。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）