Redis中的Sentinel机制

Redis的Sentinel文档

概述：Redis的Sentinel系统用于管理多个Redis服务器，该系统执行以下三个任务：

如何使用？

启动Sentinel

    对于 redis-sentinel 程序，你可以用一下命令来启动Sentinel系统：

    对于 redis-server 程序，你可以用下面的命令来启动一个运行在Sentinel模式下的Redis服务器

    两种方式都可以启动一个sentinel实例，启动sentinel实例必须指定相应的配置文件，系统会使用配置文件来保存sentinel的当前状态，并在Sentinel重启时通过载入配置文件来进行状态还原。

    注意：如果启动Sentinel时没有指定相应的配置文件，或者指定的配置文件不可用（not writabel），那么Sentinel会拒绝启动。

    如何配置Sentinel？

    Redis 源码中包含了一个名为 sentinel.conf 的文件， 这个文件是一个带有详细注释的 Sentinel 配置文件示例。

运行一个 Sentinel 所需的最少配置如下所示：

    解读一下第一条指令的意思：

    其他选项的基本格式如下

学到这里我们进行实 *** 一下，感受一下哨兵的威力！

    我们先在test目录下，新建三个配置文件：26379.conf、26380.conf、26381.conf（Sentinel服务器端口号默认是在redis服务器前拼个2），用 vi 命令创建这三个配置文件，然后我们在配置文件中写入一些简单的配置：

端口号：26379，哨兵名称：mymaster，主机地址：127.0.0.1，监控的redis端口号：6379，必须要2台从Sentinel服务器同意才会切换master，并进行故障迁移。（注意，这三个配置文件监控的redis服务器端口都是6379）

用相同的方法，创建了另外两个sentinel配置文件

我们先启动一个6379作为master

再启动6380、6381，作为两个slave

接下来正菜上场了！启动Sentinel！

可以发现，有两个slave正在跟随master，我们只要拿哨兵监控master，就可以看到有几个slave

我们继续启动，再接着启动两个Sentinel服务器

现在我们做一个小实验：如果我们将master服务器（6379）关闭，两个slave之间会发生什么？

当把master关闭之后，两个slave直接会有一段时间提示主服务器拒绝访问：

而哨兵开始也没有立马进行选举投票，选出新master，因为redis选举默认配的时间是有些长的，要过一点时间才开始选举投票，经过重新选举之后，sentinel选择了6381作为新的master。

那既然6381作为新秀，它应该有了很大的指导权，我们现在看看：

我们可以看到，在6381中设置的数据，确实在6380中可以查的到！说明6380在跟随6381，说明哨兵自动帮我们实现了故障转移。

我们再查看一下配置文件，看看有何变化？

可以发现，和原来我们写进去的2句配置完全不一样了，也就是说哨兵会自己改动配置文件。现在的master是6381。

接下来探讨一个问题：哨兵是如何发现其他哨兵的？

答案是：发布订阅机制。活着的master会去查看slave是谁，然后会去订阅其他的slave

我们可以用 psubscribe 去查看相关的发布订阅情况

    redis集群模式，丢失master主服务器是无法继续工作的，所以随时都需要一个master节点。但是服务器宕机是经常出现的事情，集群本身是无法完成故障转移的，所以需要一个第三方的解决方案，帮redis集群完成故障转移（选择主节点、通知从节点修改同步master地址，让原来的主节点成为从节点）。

（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 127.0.0.1 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 127.0.0.1:8080，修改slave的复制目标

   （4）修改已下线的master服务器为新master的slave节点

            头sentinel保持对已下线master的监控，当已下线master重新上线（对PING命令有回复），就对他发送slave of 127.0.0.1命令，让其成为slave。

            至此，故障转移全部结束。

redis版本为redis-3.2.12，使用工具将安装包上传到data目录。

在data目录下创建文件夹redis，将redis安装在此目录。

第一步：解压。

第二步：安装，PREFIX=/data/redis用来设置安装目录。

到此，redis已经安装完成，剩下就是配置和启动服务。

进入redis目录， 创建配置文件conf、日志logs、数据库dump、进程号pid四个目录，用来存放对应的文件，这四个目录也可以存放在其他文件夹，只要与配置文件中的配置一致即可，否则在启动服务时会报错。 其中bin目录就是redis安装成功后的一些命令文件。

redis服务配置一主二从，哨兵模式。注意：如果在实际开发中用不到哨兵模式，redis服务配置一主一从即可。

主Redis配置：redis_6379.conf

从Redis配置，redis_6380.conf和redis_6381.conf，与主Redis配置基本上一样，不一样的地方在于 端口、数据库、日志、pid文件名称 ，都以6380或6381为标志， 最重要的地方是建立主从关系和同步验证。

注意： 对只使用redis服务 ，只需要在主Redis里面配置requirepass，在从Redis里面配置masterauth，密码保持一致，密码尽可能复杂，以免被攻击破解。

注意： 对只使用redis服务 ，如果从Redis也有必要加入访问验证，也可以设置requirepass，而且密码可以与主Redis密码不同。

将配置文件放置到/data/redis/conf目录下，然后就可以启动服务了。

启动服务要按照主从顺序依次启动。

查看服务启动情况：

也可以通过查看日志文件来确认服务是否正常启动。

通过客户端登录Redis验证数据同步情况：

主Redis登录验证，设置数据：

从Redis登录，获取数据：从Redis并没有设置密码，所以无需验证就可以 *** 作。

配置哨兵模式：

Redis Sentinel集群通常由3到5个节点组成，如果个别节点挂了，集群还可以正常运作。Sentinel负责监控Redis集群的 健康 情况。

如果主Redis挂掉，Sentinel集群会通过投票选择一个新的主Redis。 当原来的主Redis恢复时，它会被当做新的主Redis的从Redis重新加入Redis集群。

设置连接master和slave的密码，需要注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码必须设置相同。也就是说主Redis和从Redis都必须设置requirepass和masterauth，而且密码必须相同。

sentinel.conf配置信息：

将该配置文件放置到/data/redis/conf目录下，启动sentinel服务：

验证sentinel是否起作用，可以手工shutdown掉主Redis。

这时从Redis想要访问主Redis同步数据就会提示错误信息：

sentinel在监测到主Redis宕机之后，通过选举，将一个从Redis选定为新的主Redis。通过查看sentinel日志可以发现，选定6380为新的主Redis，同时将另外两个Redis作为从Redis。

注意：选定6380为主Redis后，所有的配置文件都会被修改，主要是重新建立主从关系。

6379会新增：slaveof 127.0.0.1 6380

6380会删掉：slaveof 127.0.0.1 6379

6381会修改：slaveof 127.0.0.1 6380

由于6379服务已经关掉，所以虽然sentinel将6379作为6380的从服务，但是没有真正的建立。

重新启动6379服务，这时sentinel会重建建立一次主从关系：

---