Redis分布式集群实战（4）——集群方案二（redis哨兵模式来进行主从替换以及故障恢复）

1、sentinel哨兵模式介绍

（1）Sentinel（哨兵）是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，
以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，
自动将下线主服务器属下的某个从服务器升级为新的主服务器。

（2）Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，
sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案，
sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；
当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

（3）sentinel可让redis实现主从复制，当一个集群中的master失效之后，sentinel可以选举出一个新的master用于自动接替master的工作，
集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。

2.sentinel哨兵模式的结构

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案
假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换
而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换
Sentinel由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器
并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器

3.哨兵模式的其他知识

（1）Sentinel状态持久化
snetinel的状态会被持久化地写入sentinel的配置文件中。
每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳。
这意味着，可以安全的停止和重启sentinel进程。

（2）Sentinel作用

Master状态检测
如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave。
Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，
即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

（3）Sentinel工作方式（每个Sentinel实例都执行的定时任务）

1）每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个PING命令。
2）如果一个实例（instance）距离最后一次有效回复PING命令的时间超过 own-after-milliseconds 选项所指定的值，
则这个实例会被Sentinel标记为主观下线。
3）如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4）当有足够数量的Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，
则Master会被标记为客观下线。
5）在一般情况下，每个Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
6）当Master被Sentinel标记为客观下线时，Sentinel 向下线的 Master 的所有Slave发送 INFO命令的频率会从10秒一次改为每秒一次。
7）若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除。
若 Master重新向Sentinel 的PING命令返回有效回复，Master的主观下线状态就会被移除。

（4）三个定时任务

sentinel在内部有3个定时任务

1）每10秒每个sentinel会对master和slave执行info命令，这个任务达到两个目的：
a）发现slave节点
b）确认主从关系
2）每2秒每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个发布订阅的频道(sentinel:hello)。
sentinel节点通过__sentinel__:hello频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。
3）每1秒每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。

（5）主观下线

所谓主观下线（Subjectively Down， 简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，
即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。
主观下线就是说如果服务器在down-after-milliseconds给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复，
或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（SDOWN ）。
sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，
通过判断ping回复是有效回复，还是无效回复来判断实例时候在线（对该sentinel来说是“主观在线”）。
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，
如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel回认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。

（6）客观下线

客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，
并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断，然后开启failover。
客观下线就是说只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（ODOWN）。
只有当master被认定为客观下线时，才会发生故障迁移。
当sentinel监视的某个服务主观下线后，sentinel会询问其它监视该服务的sentinel，看它们是否也认为该服务主观下线，
接收到足够数量（这个值可以配置）的sentinel判断为主观下线，既任务该服务客观下线，并对其做故障转移操作。
sentinel通过发送 SENTINEL is-master-down-by-addr ip port current_epoch runid，（ip：主观下线的服务id，port：主观下线的服务端口，current_epoch：sentinel的纪元，runid：*表示检测服务下线状态，如果是sentinel 运行id，表示用来选举领头sentinel）来询问其它sentinel是否同意服务下线。
一个sentinel接收另一个sentinel发来的is-master-down-by-addr后，提取参数，根据ip和端口，检测该服务时候在该sentinel主观下线，
并且回复is-master-down-by-addr，回复包含三个参数：down_state（1表示已下线，0表示未下线），leader_runid（领头sentinal id），leader_epoch（领头sentinel纪元）。
sentinel接收到回复后，根据配置设置的下线最小数量，达到这个值，既认为该服务客观下线。
客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

（7）在redis-sentinel的conf文件里有这么两个配置

1）sentinel monitor

四个参数含义：
masterName这个是对某个master+slave组合的一个区分标识（一套sentinel是可以监听多套master+slave这样的组合的）。
ip 和 port 就是master节点的 ip 和 端口号。
quorum这个参数是进行客观下线的一个依据，意思是至少有 quorum 个sentinel主观的认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

2）sentinel down-after-milliseconds
这个配置其实就是进行主观下线的一个依据，masterName这个参数不用说了，timeout是一个毫秒值，
表示：如果这台sentinel超过timeout这个时间都无法连通master包括slave（slave不需要客观下线，因为不需要故障转移）的话，
就会主观认为该master已经下线（实际下线需要客观下线的判断通过才会下线）

那么，多个sentinel之间是如何达到共识的呢？
这就是依赖于前面说的第二个定时任务，某个sentinel先将master节点进行一个主观下线，然后会将这个判定通过sentinel is-master-down-by-addr这个命令问对应的节点是否也同样认为该addr的master节点要做客观下线。最后当达成这一共识的sentinel个数达到前面说的quorum设置的这个值时，就会对该master节点下线进行故障转移。quorum的值一般设置为sentinel个数的二分之一加1，例如3个sentinel就设置2。

（8）主观下线（SDOWN）和客观下线（ODOWN）的更多细节
sentinel对于不可用有两种不同的看法，一个叫主观不可用(SDOWN),另外一个叫客观不可用(ODOWN)。
SDOWN是sentinel自己主观上检测到的关于master的状态，
ODOWN需要一定数量的sentinel达成一致意见才能认为一个master客观上已经宕掉，
各个sentinel之间通过命令SENTINEL is_master_down_by_addr来获得其它sentinel对master的检测结果。
从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。
这个时间在配置中通过is-master-down-after-milliseconds参数配置。

4.Redis Sentinel的主从切换方案

Redis 2.8版开始正式提供名为Sentinel的主从切换方案，通俗的来讲，
Sentinel可以用来管理多个Redis服务器实例，可以实现一个功能上实现HA的集群，Sentinel主要负责三个方面的任务：
1）监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2）提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3）自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统， 可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

5.哨兵模式具体的实现过程如下

上一篇文章我已经实现了server1（master）和server2（slave）之间的主从复制
现在将server3也设置为server1的slave节点

（1）配置server3上的redis，并且设置为salve节点
解压，进入解压目录


编译和安装

编译完之后开启redis

修改配置文件，设置主从复制



重新启动服务

测试：可以看出server3也可以同步server1的数据

到此为止，我已经实现了一主（server1）二从（server2、server3）的主从复制
接下来实现哨兵模式
也就是master坏了，从master的所有slave中选举出一个新的master出来

（2）在server1（master）节点上面进行配置
编辑哨兵模式的配置文件sentinel.conf

关闭保护模式

Sentinel监听的master地址，第一个参数是给master起的名字，第二个参数为master IP，第三个为master端口，第四个为当该master挂了的时候，若想将该master判为失效，在Sentine集群中必须至少2个Sentine同意才行，只要该数量不达标，则就不会发生故障迁移。
也就是说只要有2个sentinel认为master下线，就认为该master客观下线，
启动failover并选举产生新的master。通常最后一个参数不能多于启动的sentinel实例数。
这个配置是sentinel需要监控的master/slaver信息，格式为sentinel monitor
其中应该小于集群中slave的个数，当失效的节点数超过了,则认为整个体系结构失效
不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效，
一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移，
并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。
换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。

至少多少时间连不上认为主机离线，单位是ms

表示master被当前sentinel实例认定为失效的间隔时间。
master在多长时间内一直没有给Sentinel返回有效信息，则认定该master主观下线。
也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。
如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误，
那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移：
只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。

主要是设置这三个参数，其他的可以使用默认的

（3）在server1上将配置好之后的sentinel.conf文件给两个slave节点各传送一份

注意要在开启sentinel进程之前发送文件，否则文件内容会发生变化

（4）在server1上开启sentinel进程

（5）在server2上开启sentinel进程

（6）在server3上开启sentinel进程

可以看到，此时的master节点是正常工作的，三个节点都很正常

（7）接下来模拟哨兵模式
用真机重新连接一台server1

使用命令查看此时的master节点和slave节点的信息

可以看到server1是master节点，server2和server3是slave节点

down掉server1的redis服务

查看进程，可以看到server1的redis-server进程已经关闭
但是server1的redis-sentinel进程依然正常运行，可以参加选举

在server2上可以看到将master由server1切换为server2

在server1上使用命令远程登陆redis集群中的server2，可以看到
server2是master，server3是slave


在server1查看进程，redis-server进程依然没有开启，因为我们down掉了它

编辑redis的配置文件，发现已经恢复为原来的样子

再次设置server1作为slave节点，它的master节点是server2


重启server1上的redis服务

查看进程，已经恢复好了

注意：
这里为什么要我们手动去把server1变为slave，而不是选举完之后直接将master置为slave？
因为server1原来是master，上面会有重要的数据，而且它的slave节点server2和server3上的数据有可能不完全和server1同步
如果这个时候直接将server1置为slave的话，它会以新的master节点作为参考，丢弃原来的所有数据
这时候就有可能造成严重的数据丢失

测试：登陆server2，新的master

可以看到server2是master节点，server1和server3是slave节点

同时数据依然存在，保留在我们集群中的每一个节点之上

总结来说，故障转移分为三个步骤：

1）从下线的主服务的所有从服务里面挑选一个从服务，将其转成主服务
sentinel状态数据结构中保存了主服务的所有从服务信息，领头sentinel按照如下的规则从从服务列表中挑选出新的主服务；
删除列表中处于下线状态的从服务；删除最近5秒没有回复过领头sentinel info信息的从服务；
删除与已下线的主服务断开连接时间超过 down-after-milliseconds*10毫秒的从服务，
这样就能保留从的数据比较新（没有过早的与主断开连接）；
领头sentinel从剩下的从列表中选择优先级高的，如果优先级一样，选择偏移量最大的（偏移量大说明复制的数据比较新），
如果偏移量一样，选择运行id最小的从服务。

2）已下线主服务的所有从服务改为复制新的主服务
挑选出新的主服务之后，领头sentinel 向原主服务的从服务发送 slaveof 新主服务 的命令，复制新master。

3）将已下线的主服务设置成新的主服务的从服务，当其回复正常时，复制新的主服务，变成新的主服务的从服务
同理，当已下线的服务重新上线时，sentinel会向其发送slaveof命令，让其成为新主的从。

温馨提示：还可以向任意sentinel发生sentinel failover 进行手动故障转移，这样就不需要经过上述主客观和选举的过程。