redis集群—哨兵

redis sentinel 哨兵原理，配置和使用

Redis主从复制哨兵模式

Redis进阶实践之十 Redis哨兵集群模式

深入浅出Redis-redis哨兵集群

 

如果redis哨兵宕机了怎么办

 

redis 的默认端口是6379

sentinel监听端口，默认是26379

 

Redis Ping 命令使用客户端向 Redis 服务器发送一个 PING ，如果服务器运作正常的话，会返回一个 PONG 。通常用于测试与服务器的连接是否仍然生效，或者用于测量延迟值。

 

Redis Info 命令以一种易于理解和阅读的格式，返回关于 Redis 服务器的各种信息和统计数值。

Redis Monitor 命令用于实时打印出 Redis 服务器接收到的命令，调试用。

 

Redis哨兵模式

 Redis主从复制的功能非常强大,它有以下好处:

 

1、避免Redis单点故障

2、构建读写分离架构，满足读多写少的应用场景

 

哨兵架构

sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。

 

哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过 sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis 主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)

 

 

哨兵的几个不足点：

 

1、哨兵集群中只要有一台宕了，整个集群的故障转移机制就失效了。

2、哨兵启动时候redis主库必需运行正常，否则故障转移机制也失效。

3、应用端需要先询问哨兵才能访问到redis主库，是否对效率也有明显的影响。

 

一、简介

在使用主从复制的情况下，Master服务器进行了down机的情况，我们的系统就不能再进行写的操作，所以此时redis在2.6版本引入了哨兵模式，但是并不稳定，2.8版本之后哨兵模式才稳定了起来。

顾名思义Redis的哨兵模式就是对redis系统进行实时的监控，其主要功能有下面两点

1.监测主数据库和从数据库是否正常运行。

2.当我们的主数据库出现故障的时候，可以自动将从数据库转换为主数据库，实现自动的切换。

 

 

Sentinel是Redis高可用性的解决方案：

由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将已下线主服务器属下的模模个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

 

Redis提供的sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，

基本原理是：心跳机制+投票裁决

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

 

 

哨兵(sentinel) 虽然有一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)，哨兵(sentinel) 的一些设计思路和zookeeper非常类似。

 

Sentinel集群之间会互相通信，沟通交流redis节点的状态，做出相应的判断并进行处理，这里的主观下线状态和客观下线状态是比较重要的状态，它们决定了是否进行故障转移，可以 通过订阅指定的频道信息，当服务器出现故障得时候通知管理员，客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器，你不可以使用 PUBLISH 命令向这个服务器发送信息，但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。 

 

 

二、步骤：

1. 启动并初始化Sentinel(哨兵)

a、初始化服务器

b、将普通redis服务器使用的代码替换成Sentinel专用代码

c、初始化Sentinel状态，sentinelState结构中保存了服务器中所有和Sentinel功能有关的状态：

当前纪元，用于实现故障转移：uint64_t current_epoch

所有被这个sentinel监视的主服务器：dict *masters

是否进入了tilt模式：int tilt

正在执行的脚本数量：int running_scripts

进入tilt模式的时间：mstime_t tilt_start_time

最后一次执行时间处理器的时间：mstime_t previous_time

FIFO队列，包含了所有需要执行的用户脚本：list *scripts_queue

d、根据给定的配置文件，初始化Sentinel的监视主服务器列表(dict *masters)：字典的键是被监视主服务器的名字，字典的值则是被监视主服务器对应的sentinelRedisInstance结构

e、创建连向主服务器的网络连接

命令连接：专门用于向主服务器发送命令，并接收命令回复

订阅连接：专门用于订阅主服务器的_sentinel_：hello频道

 

2. 获得主服务器信息

Sentinel默认会以每10s/次的频率，通过命令连接向它已知的所有Master，Slave发送 INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息。

 

3. 获取从服务器信息  

当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构之外，还会创建连接到从服务器的命令连接和订阅连接。

 

4. 向主服务器和从服务器发送信息

默认情况下，Sentinel会以2s/次的频率，通过命令连接向所有被监视的主服务和从服务器发送信息

 

5. 接收来自主服务器和从服务器的频道信息

对于监视同一个服务器的多个Sentinel来说，一个Sentinel发送的信息会被其他Sentinel接收到，这些信息会被用于更新其他sentinel对发送信息sentinel的认知，也会被用于更新其他sentinel对被监视服务器的认知。

 

6. 检测主观下线状态

默认情况下，sentinel会以1s/次的频率向所有与它创建了命令连接的实例（包括主服务器、从服务器、其他sentinel在内）发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。

 

7. 检查客观下线状态

当sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线，他会向同样监视这一主服务器的其他Sentinel进行询问，看他们是否也任务主服务器已经下线。当Sentinel从其他sentinel那里接收到足够数量的已下线判断之后，sentinel就会将主服务器判定为客观下线，并进行故障转移操作。

 

8. 选举领头sentinel

a、每个成为candidate的sentinel将自己纪元数+1，并向其他sentinel发送要求选举自己为局部领头sentinel的命令

b、每个folloewer-candidate都选举第一个接收到的请求作为自己的局部领头sentinel并回复，然后将自己的纪元数+1

c、 每个candidate统计自己的票数，如果>=n/2+1，则该sentinel成为领头sentinel。

 

9. 故障转移

a、 在已下线主服务器属下的所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器

b、让已下线主服务器属下的所有从服务器改为复制新的主服务器

c、将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，他就会成为新的主服务器的从服务器。

 

 

三、Sentinel的工作方式:

1)：每个Sentinel以 1s/次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 

2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线（SDOWN）。 

3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以 1s/次的频率确认Master的确进入了主观下线状态。 

4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线（ODOWN）。 

5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 

6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 

7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

 

 

四、配置 

配置哨兵模式核心文件

sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379(主机IP端口) 1

上面最后一个数字1，表示主机挂掉后salve（从机）投票看让谁接替成为主机，得票数多少后升为主机

 

 

启动哨兵模式

redis-sentinel /myredis/sentinel.conf

 

查看状态

INFO replication

 

Sentinel常用命令

1.  ping  //返回 PONG 。

2.  sentinel masters  //列出所有被监视的主服务器，以及这些主服务器的当前状态。

3.  sentinel slaves <master name>  //列出给定主服务器的所有从服务器，以及这些从服务器的当前状态。

4.  sentinel get-master-addr-by-name <master name>  //返回给定名字的主服务器的 IP 地址和端口号。如果这个主服务器正在执行故障转移操作，或者针对这个主服务器的故障转移操作已经完成，那么这个命令返回新的主服务器的IP 地址和端口号。

5.  sentinel reset <pattern>  //重置所有名字和给定模式 pattern 相匹配的主服务器。pattern参数是一个 Glob风格的模式。重置操作清除主服务器目前的所有状态，包括正在执行中的故障转移，并移除目前已经发现和关联的，主服务器的所有从服务器和Sentinel 。

 sentinel failover <master name>  //当主服务器失效时，在不询问其他 Sentinel意见的情况下，强制开始一次自动故障迁移（不过发起故障转移的 Sentinel 会向其他Sentinel 发送一个新的配置，其他Sentinel 会根据这个配置进行相应的更新）。

 

 

Sentinel配置详解

1. port 26379  //sentinel监听端口，默认是26379，可以修改。

2.  sentinel monitor <master-name> <ip> <redis-port> <quorum> 

//告诉 sentinel去监听地址为ip:port的一个master，这里的master-name可以自定义，quorum是一个数字，指明当有多少个sentinel认为一个master失效时，master才算真正失效。master-name只能包含英文字母，数字，和“.-_”这三个字符。

配置示例：sentinel monitor master-1 127.0.0.1 6379 2

 

3. sentinel down-after-milliseconds <master-name> <milliseconds>   

//sentinel会向master发送心跳PING来确认master是否存活，如果 master在“一定时间范围”内不回应PONG或者是回复了一个错误消息，那么这个sentinel会主观地 (单方面地)认为这个master已经不可用了 (subjectively down, 也简称为SDOWN)。而这个down-after-milliseconds就是用来指定这个“一定时间范围”的，单位是毫秒。

配置示例：sentinel down-after-milliseconds master-1 5000

 

4.  sentinel failover-timeout <master-name> <milliseconds> 

//如果在该时间（ms）内未能完成failover操作，则认为该failover失败。

配置示例：sentinel failover-timeout master-1 18000

 

5. sentinel parallel-syncs <master-name> <numslaves> 

//在发生 failover主备切换时，这个选项指定了最多可以有多少个slave同时对新的 master进行同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为 1来保证每次只有一个slave处于不能处理命令请求的状态。

配置示例：sentinel parallel-syncs master-1 1

 

6.  sentinel notification-script <master-name> <script-path>  //通知型脚本

当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。

 

配置示例：sentinel notification-script master-1 D:\script.bat

 

7.  sentinel client-reconfig-script <master-name> <script-path> 

//当一个 master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。以下参数将会在调用脚本时传给脚本:<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>目前<state>总是“failover”, <role>是“leader”或者“observer”中的一个。参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的。这个脚本应该是通用的，能被多次调用，不是针对性的。

 

配置示例：sentinel client-reconfig-script mymaster D:\script.bat

 

8.  sentinel auth-pass <master-name> <password> 

//设置连接master和 slave时的密码，注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码应该设置相同。

配置示例：sentinel auth-pass master-1 grs