Redis高可用

第一种: 哨兵模式
第二种: 集群

哨兵模式

哨兵,顾名思义,放哨的,监控一些动态 Redis中的哨兵模式也是监控,不过哨兵是一个进程,运行在系统中,通过发送指令监控主从节点是否正常运作,当然除了键控之外,还可以只从自动切换等功能

单哨兵模式

多哨兵模式

哨兵模式内部原理

哨兵模式内部是依赖三个定时任务, 主观下线,客观下线 和sentinel Reft选举的
第一个定时任务
问题描述: 因为我们并没有在哨兵配置文件中配置从节点的信息,哨兵会把从节点切换成主节点,那么哨兵是如何知道从节点的信息的?
定时任务: 每隔10秒,每个Sentinel节点会向主节点发送info命令,用于获取最新的主从结构一级从节点信息
第二个定时任务
每隔两秒,每个sentinel都会向一个固定的频道(sentinel:hello) 上发送自己对主节点的判断以及自身的信息
其他的sentinel节点都会订阅这个频道,了解其他的sentinel节点对主节点的判断
第三个定时任务
每隔一秒,每个sentinel都会向主从节点和其他sentinel节点发送心跳(ping命令)用于彼此监测是否可用
主观下线 看图
客观下线 同上

Raft算法
问题说明: 当宕机的主节点被客观下线之后,从节点会变成主节点,那么是谁让从节点变成主节点的呢? 此时有多个 sentinel到底谁说了算 此时sentinel会选举出一个领导者Leader
选举流程: 当sentinel-A 对主节点主观下线之后,会向其他sentinel节点发送sentinel is-master-down-by-addr 命令,要求将自己设置为领导者
每个节点在每个选举轮次中只有一次投票权,接收到这个指令之后,节点将会给sentinel-A投票 同意这个,sentinel-A 成为领导者
如果sentinel-A的票数最高 则sentinel-A将会成为领导者 做故障转移

主从复制和哨兵模式的搭建，请参考其他文章，很简单，而且别人写的很详细，这里主要解决哨兵模式无法切换的问题。
目前我这边的配置为：
一主二从三哨兵
出现的问题主要有：

问题1：没有看到切换master节点的信息：

解决方法：修改redis-sentinel.conf 配置文件，将最少投票数改为1，(大于3个哨兵的，建议投票数为：哨兵数/2 -1 不为别的，我只怕redis抽风！！ ) 注：官方文档并没有说需要【(哨兵数/2)-1 】，是我自己设置并解决我当前的问题的，官方文档只说如果哨兵数过少，则故障转移是不会产生的，也就是说，一两个哨兵，并不是高可用配置，当master挂掉后，不一定会给你进行故障转移。：
详见：https://redis.io/topics/sentinel

问题二：哨兵选举后，无法真正地切换。

无法切换，有几种情况：
1-redis保护模式开启了
2-端口没有放开；
3-master密码和从密码不一致。
4-master节点的redis.conf没有添加masterauth

建议处理方法如下：
每一台机子下的：redis.conf配置文件，还有哨兵的redis-sentinel.conf 配置文件修改成：

bind 0.0.0.0
protected-mode no

2-各个哨兵，端口要能相互telnet 对应的ip 端口
查看想开的端口是否已开：firewall-cmd --query-port=26379/tcp
添加指定需要开放的端口：firewall-cmd --add-port=26379/tcp --permanent
重载入添加的端口：firewall-cmd --reload
查询指定端口是否开启成功：firewall-cmd --query-port=26379/tcp
返回yes即可

3–master密码和从密码不一致
由于哨兵配置的时候没有配置从密码，只配置了master的密码，那么问题来了，如果master挂掉了，哨兵sentinel切换master的时候，怎么去修改其他节点的配置信息呢。实际上，哨兵是拿master的密码去认证的，所以，我们在配置redis的时候，建议redis的账号密码一致(至少主账号的master-auth密码和从节点的一致)

4-master节点也要设置masterauth，避免当master重启后无法变成新master节点的从节点

各位参考以上的配置进行操作即可。如果还有其他的配置需要注意的，欢迎留言

哨兵模式的简介

• 主从切换技术的方法是︰当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel (哨兵）架构来解决这个问题。

• 哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

哨兵的作用

• 监控
  • 不断的检查master和slave是否正常运行。
  • master存活检测、master与slave运行情况检测
• 通知（提醒）
  • 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。
• 自动故障转移
  • 断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址

注意：

• 哨兵也是一台redis服务器，只是不提供数据服务
• 通常哨兵配置数量为单数

启用哨兵模式

配置哨兵

• 配置一主二从结构

• 配置三个哨兵（配置相同，端口不同）
  配置sentinel.conf

• 启动哨兵

  redis-sentinel sentinel-端口号.conf
  

查看哨兵配置文件
[root@maomao redis-6.2.1]# cat sentinel.conf | grep -v '^#' |grep -v '^$'
port 26379
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 2		# 自定义哨兵集群名字 最后一个2意思是 如果有两个哨兵判断master宕机 就真的宕机 
sentinel down-after-milliseconds mymaster 30000		# master连接了多少时间没有响应，则判断宕机 30000毫秒
acllog-max-len 128
sentinel parallel-syncs mymaster 1		# 当之前的master挂机之后 ，有新的master上位，一次有多少个master同步，根据性能
sentinel failover-timeout mymaster 180000	# 进行同步的时候多长时间同步完成算有效，多长时间同步超时
sentinel deny-scripts-reconfig yes
SENTINEL resolve-hostnames no
SENTINEL announce-hostnames no

然后将哨兵配置文件拷贝到redis配置文件那里
cat sentinel.conf | grep -v '^#' |grep -v '^$' > /usr/local/bin/redis_config/sentinel-26379.conf

然后修改配置
port 26379
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
dir /usr/lcoal/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
acllog-max-len 128
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
SENTINEL resolve-hostnames no
SENTINEL announce-hostnames no

修改另外两个哨兵的配置
sed 's/26379/26380/g' sentinel-26379.conf >sentinel-26380.conf 
sed 's/26379/26381/g' sentinel-26379.conf >sentinel-26381.conf 

清空之前的数据
[root@maomao data]# ll
total 476
-rw-r--r-- 1 root root 465174 Apr 18 09:22 6379.log
-rw-r--r-- 1 root root   4645 Apr 18 03:50 6380.log
-rw-r--r-- 1 root root   3833 Apr 18 09:38 appendonly-6379.aof
-rw-r--r-- 1 root root    391 Apr 18 22:25 dump-6379.rdb
-rw-r--r-- 1 root root    391 Apr 18 22:25 dump.rdb
[root@maomao data]# rm -rf *

补充：哨兵模式的全部配置

# Example sentinel.conf

# 哨兵sentinel实例运行的端口 默认26379		如果有哨兵集群，我们还需要配置每个 哨兵端口
port 26379

# 哨兵sentinel的工作目录
dir /tmp

# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd


# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

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



# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

# SCRIPTS EXECUTION

#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。

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

# 客户端重新配置主节点参数脚本
# 当一个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 <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh	# 一般都是由运维来配置

启动哨兵

先起主机，然后从机，最后哨兵

redis-sentinel redis_config/sentinel-26379.conf 

连接哨兵客户端
redis-cli -p 26379

当哨兵启动之后 哨兵的配置文件也会发生变化
在配置最后会自动添加从机信息
sentinel known-replica mymaster 127.0.0.1 6381
sentinel known-replica mymaster 127.0.0.1 6380

启动第二，三台哨兵
redis-sentinel redis_config/sentinel-26380.conf
redis-sentinel redis_config/sentinel-26380.conf

配置文件又添加了哨兵的信息
sentinel known-replica mymaster 127.0.0.1 6381
sentinel known-replica mymaster 127.0.0.1 6380
sentinel known-sentinel mymaster 127.0.0.1 26381 446d48f0913658b1cc89d5a9ea181864e63a5086
sentinel known-sentinel mymaster 127.0.0.1 26380 04d12b0c3b213a7e6b64a2ce71e5beb532a79324

验证主从是否正常
127.0.0.1:6379> set name maomao
OK

127.0.0.1:6380> get name
"maomao"

验证哨兵的功能
把master停掉
1903:X 18 Apr 2021 22:48:56.604 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
1903:X 18 Apr 2021 22:48:56.605 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
1903:X 18 Apr 2021 22:48:57.084 * +sentinel sentinel 4423fe6bdf4b9a76dc44149cb4c324f06d5a845c 127.0.0.1 26379 @ mymaster 127.
0.0.1 63791903:X 18 Apr 2021 22:48:57.305 * +sentinel sentinel 04d12b0c3b213a7e6b64a2ce71e5beb532a79324 127.0.0.1 26380 @ mymaster 127.
0.0.1 63791903:X 18 Apr 2021 22:52:00.711 # +sdown master mymaster 127.0.0.1 6379
1903:X 18 Apr 2021 22:52:00.777 # +new-epoch 1
1903:X 18 Apr 2021 22:52:00.778 # +vote-for-leader 4423fe6bdf4b9a76dc44149cb4c324f06d5a845c 1
1903:X 18 Apr 2021 22:52:00.801 # +odown master mymaster 127.0.0.1 6379 #quorum 3/2
1903:X 18 Apr 2021 22:52:00.801 # Next failover delay: I will not start a failover before Sun Apr 18 22:58:01 2021
1903:X 18 Apr 2021 22:52:01.454 # +config-update-from sentinel 4423fe6bdf4b9a76dc44149cb4c324f06d5a845c 127.0.0.1 26379 @ mym
aster 127.0.0.1 63791903:X 18 Apr 2021 22:52:01.454 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
1903:X 18 Apr 2021 22:52:01.454 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
1903:X 18 Apr 2021 22:52:01.454 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
1903:X 18 Apr 2021 22:52:31.484 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

6379停掉 主机从6379变成了6380

6380可以写数据
127.0.0.1:6380> set niu niu
OK

哨兵模式的工作原理

• 哨兵在进行主从切换过程中经历三个阶段
  • 监控
  • 通知
  • 故障转移

阶段一：监控阶段

• 用于同步各个节点的状态信息
  • 获取各个sentinel的状态（是否在线）
  • 获取master的状态
    • master属性
      • runid
      • role：master
    • 各个slave的详细信息
  • 获取所有slave的状态（根据master中的slave信息）
    • slave属性
      • runid
      • role：slave
      • master_host、master_port
      • offset

1. 当第一个哨兵启动之后，先连接master，发送info指令
2. 哨兵和master建立了一个cmd连接，专门用于发送数据。
   在这个过程中，还保存了所有主从哨兵信息
3. 在master端，也记录保存了主从哨兵信息
4. 哨兵根据获取到的slave信息，去连接每一个slave，发送info指令
5. 下一个哨兵进入之后，也是第一个连接master，但是它发现之前保存的信息，并建立cmd连接，保存了master，slaves，sentinels信息（哨兵信息中包含之前第一个进来的哨兵信息）
6. 为了保证两台哨兵信息同步，哨兵之间又建立了连接，发布订阅，可以相互对称信息，并且互相发送ping命令
7. 当第三个哨兵进来之后，进行相同操作，然后和另外两个哨兵组成一个循环的网络，通过订阅互相共享信息。这样获取信息速度快

阶段二：通知阶段

通知阶段是一个信息长期维护的阶段

1. 三个哨兵组成一个小的群体，进行信息的共享互通
2. 哨兵通过建立的cmd连接，获取master和slave的对应的工作状态
3. 不管哪个哨兵获取到信息，就会在群体之间互通，sentinel发布的信息就是一个hello的信息，查看主从能否回复
4. 其他sentinel都可以收到回复

阶段三：故障转移阶段

发现故障

1. 当sentinel向master发送指令，结果master没有回复，发到一定阶段以后，sentinel主观认为master掉线，因此会给master标记一个flags：SRI_S_DOWN（主观下线）
2. 然后sentinel会把master掉线的信息传给哨兵内网里，发送一条指令指名master挂了，同网内的其他sentinel接到这个指令后就会，一直给master发送指令，结果发现master果然不回复。确定master的确掉线。然后标记flags：SRI_O_DOWN（客观下线）
3. 只要超过半数以上的sentinel认为master挂了，则标记flags：SRI_O_DOWN

选出领头sentinel

1. 所有sentinel在一个网络中，每个sentinel都会相当领头的
2. 然后每个sentinel会发送一个信息，包含：挂掉master的ip、端口，和之前竞选的次数，自己的runid
3. 所有sentinel开始投票，每个sentinel可以投一票，sentinel按照获得信息的先后顺序，将票数投给它一个收到信息的sentinel
4. 循环投票后票数最高的sentinel被选作领头去选择新的master

• 监控
  • 同步信息
• 通知
  • 保持联通
• 故障转移
  • 发现问题
  • 竞选负责人
  • 优选新master
  • 新master上任，其他slave切换master，原master作为slave故障回复后连接

挑选备选master

1. 挑选在线的
2. 挑选响应速度快的
3. 与原master断开时间最近的
4. 优先原则
   • 优先级
   • offset
   • runid
5. 发送指令（sentinel）
   • 向新的master发送slaveof no one
   • 向其他slave发送slaveof 新的masterIP、端口

主从切换总结

• 服务器列表中挑选备选master
  • 在线的
  • 响应慢的
  • 与原master断开时间久的
  • 优先原则
    • 优先级
    • offset
    • runid

重启旧的master之后，作为从机