Redis高可用与哨兵

1、背景

虽然Redis可以实现单机的数据持久化，但无论是RDB也好或者AOF也好，都解决不了单点宕机问题，即一旦单台 redis服务器本身出现系统故障、硬件故障等问题后，就会直接造成数据的丢失，因此需要使用另外的技术来解决 单点问题。

1. 1. 配置redis主从

主备模式，可以实现Redis数据的跨主机备份

程序端连接到高可用负载的VIP，然后连接到负载服务器设置的Redis后端real server，此模式不需要在程序里面配 置Redis服务器的真实IP地址，当后期Redis服务器IP地址发生变更只需要更改redis 相应的后端real server即可， 可避免更改程序中的IP地址设置。

slave主要配置:

redis Slave 也要开启持久化并设置和master同样的连接密码，因为后期slave会有提升为master的可能,Slave 端切换master同步后会丢失之前的所有数据。

一旦某个slave成为一个master的slave，Redis Slave服务会清空当前redis服务器上的所有数据并将master的数据 导入到自己的内存，但是断开同步关系后不会删除当前已经同步过的数据。

修改主备配置文件vim /etc/redis.conf里密码，需要注意的是，主备密码必须一致，因为可能备机会提升对外提供服务。修改完以后，systemctl restart redis

主机端修改配置；bind 0.0.0.0，否则会导致主备同步失败，提示如下错误：123302:S 19 May 2022 00:42:44.014 * MASTER <-> REPLICA sync started

123302:S 19 May 2022 00:42:44.014 # Error condition on socket for SYNC: Connection refused

命令行配置：

当前状态为master，需要转换为slave角色并指向master服务器的ip+port+password

在备机端执行

redis-cli

127.0.0.1:6379> auth 123456  #本机密码认证

OK

127.0.0.1:6379> SLAVEOF 192.168.48.107 6379

OK

127.0.0.1:6379> CONFIG SET masterauth 123456

OK

从备机端查看信息，info

master_replid，表示当前master的ID；master_replid2，表示历史masterID，发生过master角色变更，即上一个master的ID信息

备机只读模式，在主机端配置文件中修改replica-read-only yes，此时备库只允许读，不能set数据。

主从复制过程：

Redis支持主从复制分为全量同步和增量同步，首次同步是全量同步，主从同步可以让从服务器从主服务器备份数 据，而且从服务器还可与有从服务器，即另外一台redis服务器可以从一台从服务器进行数据同步，redis 的主从同 步是非阻塞的，master收到从服务器的sync(2.8版本之前是PSYNC)命令会fork一个子进程在后台执行bgsave命 令，并将新写入的数据写入到一个缓冲区里面，bgsave执行完成之后并生成的将RDB文件发送给客户端，客户端将收到后的RDB文件载入自己的内存，然后redis master再将缓冲区的内容在全部发送给redis slave，之后的同步 slave服务器会发送一个offset的位置(等同于MySQL的binlog的位置)给主服务器，主服务器检查后位置没有错误将 此位置之后的数据包括写在缓冲区的积压数据发送给redis从服务器，从服务器将主服务器发送的挤压数据写入内 存，这样一次完整的数据同步，再之后再同步的时候从服务器只要发送当前的offset位 置给主服务器，然后主服务 器根据相应的位置将之后的数据发送给从服务器保存到其内存即可。

Redis全量复制一般发生在Slave首次初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体主从同 步骤如下：

1）从服务器连接主服务器，发送SYNC命令；

2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB快照文件并使用缓冲区记录此后执行的所有写命令；

3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；

5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

7）后期同步会先发送自己slave_repl_offset位置，只同步新增加的数据，不再全量同步。

从日志中也可以体现如上所述内容；

对于多节点环境，提升SLAVE为MASTER，在需要同步端执行SLAVEOF no one，这条命令在需要提升的备节点执行，其作用是停止属于某个节点slave角色，将此节点提升为master。

修改配置建议通过配置文件进行，而非命令行！！！

主从同步参数优化

Redis在2.8版本之前没有提供增量部分复制的功能，当网络闪断或者slave Redis重启之后会导致主从之间的全量同 步，即从2.8版本开始增加了部分复制的功能。

repl-diskless-sync no # 是否使用无盘同步RDB文件，默认为no，no为不使用无盘，需要将RDB文件保存到磁盘 后再发送给slave，yes为支持无盘，支持无盘就是RDB文件不需要保存至本地磁盘，而且直接通过socket文件发送 给slave。

repl-diskless-sync-delay 5 #Master准备好RDB文件后等等待传输时间

repl-ping-slave-period 10 #slave端向server端发送ping的时间区间设置，默认为10秒

repl-timeout 60 #设置超时时间

repl-disable-tcp-nodelay no #是否启用TCP_NODELAY，如设置成yes，则redis会合并小的TCP包从而节省带宽， 但会增加同步延迟（40ms），造成master与slave数据不一致，假如设置成no，则redis master会立即发送同步数 据，没有延迟，前者关注性能，后者关注redis服务中的数据一致性

repl-backlog-size 1mb #master的写入数据缓冲区，用于记录自上一次同步后到下一次同步过程中间的写入命 令，计算公式：repl-backlog-size = 允许从节点最大中断时长 * 主实例offset每秒写入量，比如master每秒最大写 入64mb，最大允许60秒，那么就要设置为64mb*60秒=3840MB(3.8G)

repl-backlog-ttl 3600 #如果一段时间后没有slave连接到master，则backlog size的内存将会被释放。如果值为0则 表示永远不释放这部份内存。

slave-priority 100 #slave端的优先级设置，值是一个整数，数字越小表示优先级越高。当master故障时将会按照 优先级来选择slave端进行恢复，如果值设置为0，则表示该slave永远不会被选择。

#min-slaves-to-write 1 #设置一个master端的可用slave少于多少个

#min-slaves-max-lag 20 #设置所有slave延迟时间都大于多少秒时，master不接收写操作(拒绝写入)。

取消备机角色

127.0.0.1:6379> slaveof no one

OK

再次查看状态，

slave节点再有slave：

在有slave的”master”查看状态，也就是中间那个slave：

常见问题总结：

master密码不对

即配置的master密码不对，导致验证不通过而无法建立主从同步关系。

Redis版本不一致：

 不同的redis 版本之间存在兼容性问题，因此各master和slave之间必须保持版本一致。

无法远程连接

在开启了安全模式情况下，没有设置bind地址或者密码。

[root@redis-s1 ~]# redis-cli -h 192.168.7.104

192.168.7.104:6379> KEYS *

(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions:

Sentinel(哨兵)：

Sentinel 进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现 Master和Slave服务器的切换，保证系统的高可用。

其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8 版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本。哨兵(Sentinel) 是一个分布式系 统，可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossip protocols)来接收关于Master 主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave作为新的Master。每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对 方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主 观认为宕机” ，主观是每个成员都具有的独自的而且可能相同也可能不同的意识，英文名称：Subjective Down， 简称SDOWN。有主观宕机，肯定就有客观宕机。当“哨兵群”中的多数Sentinel进程在对Master主服务器做出 SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判 断，这种方式就是“客观宕机”，客观是不依赖于某种意识而已经实际存在的一切事物，英文名称是：Objectively Down， 简称 ODOWN。通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节 点，然后自动修改相关配置，并开启故障转移（failover）。

Sentinel 机制可以解决master和slave角色的切换问题。

手动配置master：

需要手动先指定某一台Redis服务器为master，然后将其他slave服务器使用命令配置为master服务器的slave,哨兵 的前提是已经手动实现了一个redis master-slave的运行环境。

实现一个一主两从基于哨兵的高可用redis架构。

编辑配置文件sentinel.conf

  Server1 配置：

哨兵可以不和Redis服务器部署在一起

Server2 配置：

Server3配置：

启动哨兵：

三台哨兵都要启动

验证哨兵端口

哨兵日志：

当前redis master状态：

当前sentinel状态：

在sentinel状态中尤其是最后一行，涉及到masterIP是多少，有几个slave，有几个sentinels，必须是符合全部服 务器数量的。

停止Redis Master测试故障转移：

在主机端停止redis服务：systemctl stop redis

查看Redis集群master信息：

查看哨兵信息：

故障转移时sentinel的信息

故障转移后的redis配置文件：

故障转移后redis.conf中的replicaof行的master IP会被修改，sentinel.conf中的sentinel monitor IP会被修改。

当前reids状态：