六、Redis 主从复制 Replicaof、哨兵 Sentinel

一、Replicaof 主从复制

在复制的概念中，数据库分为两类，主数据库master和从数据库slave，master可以进行读写操作，当写操作会自动将数据同步给slave，而slave一般只读，并接受master同步过来的数据。slave可以有多个，而只能拥有一个master。

1. 配置主从复制:

环境准备2台机，分配安装好 Redis 服务
192.168.791.150:6379 主 (Master)
192.168.791.151:6379 从 (Slave)

主从复制的机制：

• 当一个 master 实例和一个 slave 实例连接正常时， master 会发送一连串的命令流来保持对 slave 的更新，以便于将自身数据集的改变复制给 slave，包括客户端的写入、key 的过期或被逐出等等。
• 当 master 和 slave 之间的连接断开之后，因为网络问题、或者是主从意识到连接超时， slave 重新连接上 master 并会尝试进行部分重同步：这意味着它会尝试只获取在断开连接期间内丢失的命令流。
• 当无法进行部分重同步时， slave 会请求进行全量重同步。这会涉及到一个更复杂的过程，例如 master 需要创建所有数据的快照，将之发送给 slave ，之后在数据集更改时持续发送命令流到 slave 。

1). 命令行方式

5.0版本使用REPLICAOF代替了之前版本的SLAVEOF，如果使用5.0及之后版本，则建议新命令REPLICAOF。
登录 Slave Redis 命令行，执行以下命令（重启后失效），此时在 master 中的任何数据变化都会自动地同步到 slave 中。

127.0.0.1:6379> replicaof 192.168.79.150 6379
OK

# 检查配置是否成功
127.0.0.1:6379> info replication
# Replication
# 打印当前为从节点
role:slave
# 主节信息和状态为UP，说明连接成功
master_host:192.168.79.150
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:318
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:3d16649fccd4d9ddcb8e07370fd9dbb8eefdb413
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:318
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:318

命令REPLIACOF NO ONE 会关闭当前服务器的复制并转变为主服务器，原来同步所得的数据集不会被丢弃，可以写入新数据了。

127.0.0.1:6379> replicaof no one
OK
127.0.0.1:6379> set k9 v9
OK

2). 配置方式（永久生效）

Redis slave 节点 /etc/redis/6379.conf 配置文件中添加如下配置，重启 Redis slave 服务

replicaof 192.168.102.69 6379

2. 其它设置

• 通过设置slave的slave-read-only为no使slave可读写，默认是只读。但对slave的修改不会同步给任何其它数据库，并且master中更新了对应的数据就会覆盖slave的改动。

• 设置配置只有N个连接复制的时候才允许主实例写操作 set min-replicas-to-write 3

  表示只有当3个或以上的slaves连接到master，master才是可写的，否则会返回错误 “(error) NOREPLICAS Not enough good replicas to write.”。主从同步强一致性但影响可用性。
  默认值为0，表示不启用该功能。主从异步弱一致性，但影响到一致性，可能会丢数据。

• 表示允许slave最长失去连接的时间 min-slaves-max-lag 10

  表示允许slave最长失去连接的时间，（即发送REPLCONF ACK命令）的时间小于这个值，则认为slaves还在保持与master的连接。

  例:

  master与3个slave相连，其中一个slave上一次与master联系是9秒前,这时master是可以写入的，一旦10秒过后，该slave仍没联系，则master认为只有2个slaves，从而拒绝写入数据。这一特性默认是关闭的。在分布式中，打开并合理配置可以降低主从架构中因为网络分区导致的数据不一致问题。

• slave也可以同时作为master存在(master→slave(master)→slave)

3. Slave持久化

1). 配置3台机，其中master 关闭掉rdb & aof，主从启动成功后添加一些数据：
192.168.79.152:6379 master
192.168.79.153:6379 slave
192.168.79.154:6379 slave

info replication:

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.79.153,port=6379,state=online,offset=56,lag=0
slave1:ip=192.168.79.154,port=6379,state=online,offset=56,lag=0
master_replid:8a2625d03aef74f4945e3ac1409f19e18d03fc7b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:56
127.0.0.1:6379> keys *
1) "n"
127.0.0.1:6379> set n1 v1
OK

2). 通过kill 模拟 master 崩溃

[root@localhost 6379]# ps -ef | grep redis 
root      15382  13771  0 17:34 pts/3    00:00:00 redis-cli
root      15496      1  0 17:38 ?        00:00:00 redis-server 0.0.0.0:6379
root      15588  14748  0 17:43 pts/1    00:00:00 grep --color=auto redis
[root@localhost 6379]# kill -9 15496

3). 重启 master

[root@localhost 6379]# redis-server /etc/redis/6379.conf 
15599:C 15 Aug 2020 17:44:26.793 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
15599:C 15 Aug 2020 17:44:26.793 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=15599, just started
15599:C 15 Aug 2020 17:44:26.793 # Configuration loaded

4.) 检查主从节点的数据，发现已经丢失

127.0.0.1:6379> keys *
(empty array)

在master中禁用持久化，并在slave中开启持久化，如果slave崩溃了，master会自动同步过去，但master崩溃后，手工通过slave 恢复数据时需要严格按照以下两步进行

1. 在slave中使用SLAVEOF NO ONE命令将从数据库提升成master继续服务。

2. 启动之前崩溃的master，然后使用salveof命令将其设置成新的master的slave。

当开启复制且master关闭持久化功能时，一定不能使用Supervisor以及类似进程管理工具令master自动重启。

同样当master因故关闭时，也要避免直接重新启动，因为master重启会因没有持久化，所有数据都被清空了，这时slave依然会从master中同步数据。致使slave也被清空。

4. 无硬盘复制

前面的复制都是基于RDB持久化实现

当master禁用RDB快照时（即删除了所有的配置文件中的save语句），如果执行了复制初使化操作，Redis依然会生成RDB快照，所以下次启动后master会以该快照恢复据。因为复制的时间不确定，使得恢复的数据可能是在任何时间点的。

复制初使化时需要创建RDB快照文件，导致性能降低。

无硬盘复制选项，开启该选项时，Redis 在与 slave 进行复制初始化时将不会将快照内容存储在硬盘上，而是直接通过网络发送给 slave。

repl-diskless-sync yes

5. 增量复制

slave会存储master的运行id，每个Redis运行实例都会拥有一个唯一的id，重启后会生成一个新id。

在复制同步阶段，master每将一个命令传给salve时，都会把该命令存放在一个积压队列中，并记录下当前积压队列中存入的命令的偏移量范围。

slave接收到master传来的命令时，会记录下该偏移量。

主从连接准备就绪后，slave发送psync “PSYNC masterid 断开前的偏移量”

master会判断slave传来的id是否正确

master判断偏移量是否在积压队列中，如果存在执行增量复制，并将积压队列中相应的命令发送给slave,如果条件不符则会进行一次全部同步

repl-backlog-size 设置积压队列的大小，默认为1M，积压队列越大，其允许的主从数据断线的时间就越长。

repl-backlog-ttl 设置主从断开连接后多久会释放积压的内存空间，默认是1 小时。

二、Sentinel 哨兵

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是**哨兵通过发送命令，等待Redis服务器响应，监控master和slave是否运行正常，master出现故障时自动将slave 转换为 master **

需要注意的是，哨兵只是配置提供者，而不是代理。 二者的区别在于：如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求(如set/get)会直接发向主节点；如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。

这里的哨兵有两个作用:

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

1. 基本配置

准备3台机：
192.168.79.152:6379 master
192.168.79.153:6379 slave
192.168.79.154:6379 slave

1). 配置 sentinel.conf

在redis 安装包解压目录下可以找到文件：sentinel.conf

1). 复制到 /etc/redis 目录下

cp sentinel.conf /etc/redis/setinel.conf

2). 修改配置信息

port 26379
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
dir /tmp
sentinel monitor mymaster 192.168.79.152 6379 2
sentinel down-after-milliseconds mymaster 10000
sentinel failover-timeout mymaster 30000
sentinel parallel-syncs mymaster 1

• 配置 sentinel monitor mymaster 192.168.79.152 6379 2

  该配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 最后的2表示最低通过票数，将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。

  不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移。

  换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。

• 配置 sentinel down-after-milliseconds mymaster 10000

  配置 Sentinel 认为服务器已经断线所需的毫秒数

• 配置 sentinel failover-timeout mymaster 30000

  指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟

• 配置 sentinel parallel-syncs mymaster 1

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

2). 运行Sentinel

在三台机上分别运行 sentinel 服务

$ redis-sentinel /etc/redis/sentinel.conf

在启动成功后，mater 的sentinel 服务上可以看到打印 +slave 和 +sentinel 的信息，再停掉 master redis 服务。

+slave slave 192.168.79.153:6379 192.168.79.153 6379 @ mymaster 192.168.79.152 6379
+slave slave 192.168.79.154:6379 192.168.79.154 6379 @ mymaster 192.168.79.152 6379
+sentinel sentinel 4d4134db0497f3ae3e087cc8719ad18eac75ebf2 192.168.79.153 26379 @ mymaster 192.168.79.152 6379
+sentinel sentinel e7e7291d5e381d5722d0ed422c724db34da68d3d 192.168.79.154 26379 @ mymaster 192.168.79.152 6379

通过日志可以看到，新的master 已经切换到 153这台服务，原来的master 也变成了slave：

+switch-master mymaster 192.168.79.152 6379 192.168.79.153 6379
+slave slave 192.168.79.154:6379 192.168.79.154 6379 @ mymaster 192.168.79.153 6379
+slave slave 192.168.79.152:6379 192.168.79.152 6379 @ mymaster 192.168.79.153 6379

查看153状态，已经切换为 master 角色：

192.168.79.153:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:6753afa081839fe0324597556ebeed2ce23b173f
master_replid2:705c4306a2e71ef9bd015c44e7204a57b54055b1
master_repl_offset:104544
second_repl_offset:88077
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:104544

• 哨兵监控一个系统，只需要配置其监控master即可，哨兵会自动发现所有slave。

• 当master停止服务后，sentinel 会选举一个 slave 转换会 master，并把原 master 转换为 slave (当原 master 重新提供服务后就会是 slave 身份)

2. 选举优先规则，选择优先级最高的 slave，（通过slave-priority）来配置

1). 复制命令偏移量越大越优先

2). 运行id越小越优先

3. 每个 Sentinel 都需要定期执行的任务

• 每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
• 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
• 如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
• 如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。
• 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
• 当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时， 主服务器的主观下线状态就会被移除。

4. 主观下线和客观下线：

1). 主观下线（Subjectively Down， 简称 SDOWN）
如果超过 down-after-milliseconds 选项时间还没有回复，则sentinel认为其主观下线。

2). 客观下线（Objectively Down， 简称 ODOWN）
sentinel 发送 SENTINEL is-master-down-by-addr 命令询问其它sentinel， 如果认为下线达到指定数量时（大于前面配置的 “sentinel monitor mymaster 127.0.0.1 6379 2” 中的数量2），sentinel会认为其客观下线。

5. sentinel 选举规则

1. 发现主数据库客观下线的节点向每个节点哨兵节点发送请求对方选自己成为领头sentinel

2. 如果目标sentinel没有选择过别的节点，就会同意

3. 如果有超过半数且超过 quorum 参数值的节点同意则选举成功

4. 如果多个 sentinel 同时参选出现没有任何节点当选，则随机时间后重新选举

使用复制功能,总数据量的存储量受限于内存最小的节点，形成木桶效应。

解决方案1.使用客户端分片解决，即启动多个 Redis数据库节点，由客户端决定哪个键存放在哪个节点。维护成本高，增加移除节点麻烦

解决方案1.使用集群，集群支持几乎所有的单机实例支持的命令，对于涉及多键的命令（如MGET）,如果每个键都位于一个节点中，则可以正常支持，否则会提示错误。除此之外，集群只能使用默认的0号数据库。如果执行select 切换数据库会报错。