Redis 集群之哨兵模式（sentinel）及测试实例

上一节实现了Redis集群的主从模式，这一节来实现一下哨兵模式。

有了主从模式，为什么还会需要哨兵模式呢？
上一节我们了解到，为了缓解服务器压力，我们可以对redis的系统实现一个主从分离，一个master主要实现写功能，一个或多个 slave 主要负责读功能。

那么这种模式有个什么问题呢，
万一我们的master 突然宕机了，不能提供写服务了，只能依靠slave实现读的功能，这种情况是很糟糕的。
所以为了解决这种困境，前辈们又提出了一种解决方式，哨兵模式。

1、概念

首先介绍一下哨兵模式的大致架构，还是一主多从模式，不过我们还需要加上一个或多个能提供监测服务的哨兵（sentinel）。

这个哨兵，或者说几个哨兵，能够实时检测我们的master的状态，当master处于正常运行状态时，一切都OK，平安夜。

一旦master出现故障，服务器宕机，内存满了等问题导致master不能再提供服务了。
哨兵就会马上监测到这个情况，在默认的等待时间30s后，如果master还是不能使用，那这些哨兵就会自动地从slave中间挑选一个作为 master，重新形成一个 一主多从的局面。

1、安装

本次模式的实现需要两样东西，redis 和 redis-sentinel。
Redis的安装就不再赘述了，sudo apt-get 在线安装即可
redis-sentinel 的安装也是使用在线安装：

sudo apt-get install redis-sentinel

2、集群详情

我这里设置为一主两从，master 地址为 192.168.31.218
两个 slave 地址分别为 192.168.31.220 192.168.31.222

3、redis配置

redis的配置都是在原始的 conf 文件上进行删改，我把原文件中注释的部分都删掉，如下是简洁版。
有很多参数我也不太明白是啥意思，以后有时间可以详细看看，这次这个博客只是用来跑通哨兵模式这个功能。

Redis 的 master 配置

#/etc/redis/redis.conf
protected-mode no
port 6379

tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes

supervised no
pidfile "/var/run/redis/redis-server.pid"

loglevel notice
logfile "/var/log/redis/redis-server.log"
databases 16
always-show-logo yes

save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

dbfilename "dump.rdb"
dir "/var/lib/redis"
slave-serve-stale-data yes

slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no

appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble no
lua-time-limit 5000

slowlog-log-slower-than 10000
slowlog-max-len 128

latency-monitor-threshold 0
notify-keyspace-events ""

hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000

activerehashing yes

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

hz 10
aof-rewrite-incremental-fsync yes

master 的配置的话，大概就只是把 protected-mode 改成 no 就行，以上是我在Ubuntu 18.04 的一个配置。

Redis 的 slave 配置
slave 的配置和主从模式一样，在配置中指向 master 即可，在这里我们指向的是 218。
所以在 配置末尾加上：

slaveof 192.168.31.218 6379

4、redis-sentinel 配置

在安装完 sentinel之后，在 /etc/redis/ 文件夹下回出现一个 sentinel.conf 文件，这个就是哨兵的配置。
（以下是把原始默认配置文件的注释删除之后剩下的东西进行一点修改的结果）
主从哨兵的 sentinel 配置都相同：

#/etc/redis/sentinel.conf
protected-mode yes
bind 192.168.31.218  #bind值为各个 sentinel 所在的服务器的ip

daemonize yes
pidfile "/var/run/sentinel/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
port 26379

dir "/var/lib/redis"
sentinel myid f392d8a65d028eb65b1baa94d4f981ab539a3ceb
#这里修改为 master 的地址
sentinel monitor mymaster 192.168.31.218 6379 1 

sentinel config-epoch mymaster 72
sentinel leader-epoch mymaster 72

其中，在

sentinel monitor mymaster 192.168.31.218 6379 1

这一行注意下，mymaster 可自定义名称，后面跟的 ip 就是 master 的 ip，这一行 三个 sentinel 配置文件都一样。

注意： 关于 protected-mode 的设置以及 bind 的 ip 地址，一定要看示例是怎么设置的，然后相应改成自己的值。
因为如果不这样，等你测试的时候， 使 master 宕机，会发生类似 -failover-abort-not-elected master mymaster 的报错导致 master 切换不成功。

5、集群服务启动

然后在三个服务器上依次通过以下命令启动 redis 以及 sentinel 服务：

sudo service redis restart
sudo service redis-sentinel restart

在 218 服务器，也就是我们的 master 上，进入 redis 的交互界面，
输入 info replication ，可以看到类似如下的信息：

可以看到它的角色 role 是作为 master 的，也可以看到所属的两个 slave 的 ip 端口等信息。

选择一个 slave 查看信息，可以看到如下信息：

其中，有 master 的 ip 和端口信息，
有连接到 master 的 状态 master_link_status 是 up，
如果 master 宕机了，则会变成 down。

master_link_status:up

6、测试宕机

当我们把 master 的 redis 关闭，那么哨兵会在等待默认时间 30s 之后，确认 master 宕机之后，将这两个slave 中自动选择一个作为 master。
这其中，有一个主观下线和客观下线的概念。
大致意思是，当一个 sentinel 确认 master 宕机，则称为主观下线，
当所有 sentinel 都表示联系不上 master时，这个时候就称为客观下线。

接下来，我们来通过以下命令关闭 218 master 的 redis：

sudo service redis stop

在 30s 内随机选择一个 slave，输入 info replication，查看集群状态，
可以看到大致信息如下：

在这里，可以看到 master_link_status 这个状态变成了 down，表示 master 连接不上了。
然后有一行参数 可以注意下：

master_link_down_since_seconds: 4

这个表示，与master失联的时间。
默认的时间为 30s，在这之后，哨兵们会自动在剩下的 slave 中挑选一个作为 master。
这个过程是不需要人为控制的，全部由哨兵自动完成。

…
…
…

好，30s 过去了，我们再来看看这个 slave 的信息，大致信息如下：

可以看到，哨兵已经把这个 redis 自动设置为了 master，然后 222 这个 slave 也自动变成了 新的 master 的 slave。
一朝天子一朝臣，现在所有的 slave 都会指向 新的 master，也就是测试中的 220 服务器。

注意： 看到这里，你可能会想，slaveof 这个参数的信息是在 redis.conf 文件里面写好的啊，为什么会变呢？
没错，哨兵会自动更改 redis.conf 文件，把仍然是 slave 的redis的 master 指向变成了新的 master 地址。
不信你可以去看看 redis.conf 这一行，slaveof 这个参数的值已经被自动篡改了。

那么这一步大概就是我们哨兵模式功能的一个配置以及演示过程，上面的参数配置是在我三个Ubuntu系统上完全跑通的一个实例。

如果你看到这里，然后自己配置之后还是不能实现 master 的自动切换，不妨把我的配置整体复制过去，然后再试一下。

7、最后再多测试一步

如果开始宕机的 master 218 在 30s之后，也就是 slave 中已经重新选出了一个新的 master之后，
这时候再把原来的 master，也就是218的 redis 启起来，那么218 还会不会是master呢？
答案是，不会！

原来的master， 也就是 218，起来后，哨兵也会修改他的配置，把它变成一个新的 slave，加入这个集群。
你以前是老大，但后来你失势了，又想重新当老大，不好意思，不行的，没办法，只能重新当个slave，慢慢熬吧。

以上全部就是使用 Redis 搭建一个 哨兵模式（sentinel）的全过程，其中包含了，我在服务器上跑通过的 redis.conf 和 sentinel.conf 实例。

接下来的话，感觉 redis.conf 以及 sentinel.conf 中的很多参数还可以再好好研究一下。