redis ——主从复制与哨兵

快来打我* 2022-04-24 07:40 291阅读 0赞

# 一.  主从复制 #

主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性

### 1.1  主从结构 ###

1.  一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响 
2.  一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定
3.  树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。（如下图）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70][]

### 1.2 主从复制的相关操作： ###

*  配置主从复制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379启动完后再启6380，完成配置；（如下图1所示）
 *  配置主从复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效
 *  查看状态：info replication
 *  断开主从复制：在slave节点，执行6380:>slaveof no one（如下图2所示）
 *  断开后再变成主从复制：6380:> slaveof 192.168.152.128 6379
 *  数据较重要的节点，主从复制时使用密码验证： requirepass
 *  **从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 2][]

### 1.3  全量复制 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 3][]

psync是一个同步命令，master将runId和偏移量给slave，slave保存了master的的主要信息，然后master生成快照，我们不仅要传输全量数据，还要传输部分数据（RDB开始生成到RDB传输这段时间新增命令），这部分数据是写在repl\_back\_buffer里面的，当send完RDB后，master再将buffer里面的数据传给slave，slave会清除老的数据，再将这个RDB数据和buffer进行加载。

全量复制有以下开销：

1.  bgsave时间
2.  RDB文件网络传输时间
3.  从节点清空数据时间
4.  从节点加载RDB时间
5.  可能的AOF重写时间

### 1.4  部分复制 ###

如果网络发生抖动，2.8之前会重新生产rdb文件，然后重新执行。之后，提供部分复制功能、如果抖动，master会在复制缓冲区生成一个buffer（默认1M），如果offset在buffer范围内，则会将部分数据复制到slave，而不需要全量复制。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 4][]

### 1.5  主从的缺点 ###

a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；  
b)其它的节点成为新主节点的从节点，并从新节点复制数据；  
c)需要人工干预，无法实现高可用。

# 二  哨兵 #

哨兵机制的出现是为了解决主从复制的缺点的，当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

哨兵的架构图如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 5][]

### **Redis故障转移的六个步骤：** ###

1.  多个sentinel发现并确认master有问题。
2.  选举出一个sentinel作为领导
3.  选出一个slave作为master
4.  通知其余slave成为新master的slave
5.  通知客户端主从变化
6.  等待老的master复活成为新master的slave

## ##

### 2.1  安装与配置 ###

我们将按照下图进行主从节点与哨兵的配置。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 6][]

**主从节点配置**

我们先在config文件下建立一个redis-7000.conf的文件夹，这个作为maste的配置文件文件内容为：

![20190422135259899.png][]

然后再新建两个配置文件：redis-7001.conf和redis-7002.conf，这两个作为slave节点的配置文件，文件内容为：

![20190422135923478.png][]

![20190422135936361.png][]

我们分别在使用这三个配置文件启动三个redis进程：

![20190422140242158.png][]

然后我们再对端口为7000的redis使用info replication命令

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 7][]

可以看到7000端口为maste，它的有两个slave。

这样，一主两从的主从节点就配置好了

**sentinel安装配置**

首先我们将config目录下新建一个redis-sentinel-26379.conf的配置文件，文件内容为

![20190422145334859.png][]

我们通过此配置文件来启动redis-sentinel：

![20190422145731483.png][]

可以看到端口为26379的哨兵启动了，我们再重新进入config目录下的redis-sentinel-26379.conf，我们可以看到配置文件发生了变化，哨兵可以自动检测出maste与slave，且把一些自动配置去掉了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 8][]

现在我们再来建立两个哨兵

和上面一一样，分别建立两个配置文件redis-sentinel-26380.conf和redis-sentinel-26381.conf文件，里面内容出了端口号变化外其他一样，然后使用配置文件启动：

![20190422151506566.png][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70]: /images/20220217/0cc354884ac8457cbf8bdadc80aa3388.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 1]: /images/20220217/07fe1a93fc454ed3a88c33893573bac8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 2]: /images/20220217/c328a7364b904c71bc81154125f83e6c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 3]: /images/20220217/1ade28bc98d04fd186ce369fba7fa1d1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 4]: /images/20220217/f1637aaa532c434b93fa4c444808cc29.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 5]: /images/20220217/6ec7d649f1844bbf88195d3b1cd2b242.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 6]: /images/20220217/543817d806d14acebb4b1fdb455d1f3f.png
[20190422135259899.png]: /images/20220217/d2b995ed6e9e4d1abf4aa2d02e6755af.png
[20190422135923478.png]: /images/20220217/c6c3c50fce064cbca82d668f5edf5d61.png
[20190422135936361.png]: /images/20220217/0ecd850fce5e451583c40d8d556137fa.png
[20190422140242158.png]: /images/20220217/256bc1cbeed84cdf90c5d3a4839b5612.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 7]: /images/20220217/72d7993d1eda413eb604c6d4d3bd0ed5.png
[20190422145334859.png]: /images/20220217/cdeb8deec28e4a75a301ceff2d121289.png
[20190422145731483.png]: /images/20220217/c886dab252754a06bf609ff25f625b32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NTgyNjA0_size_16_color_FFFFFF_t_70 8]: /images/20220217/95a631fb50bf4ee4a9c8498160792915.png
[20190422151506566.png]: /images/20220217/ff5d3891a0194239aaaf8d285607e348.png