Redis主从复制

概念

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为主节点

(master/leader) ，后者称为从节点 (slave/follower) ；数据的复制是单向的，只能由主节点到从节点。Master 以写为主， Slave 以读为主。

默认情况下，每台 Redis 服务器都是主节点；且一个主节点可以有多个从节点 ( 或没有从节点 ) ，但一个从节点只能有一个主节点。

主从复制的作用主要包括：

1 、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2 、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3 、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写 Redis 数据时应用连接主节点，读 Redis 数据时应用连接从节点），分担服务器负载；尤其是在写 少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。

4 、高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis 高可用的基础。

一般来说，要将 Redis 运用于工程项目中，只使用一台 Redis 是万万不能的，原因如下：

1 、从结构上，单个 Redis 服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；

2 、从容量上，单个 Redis 服务器内存容量有限，就算一台 Redis 服务器内存容量为 256G ，也不能将所有内存用作 Redis 存储内存，一般来说，单台 Redis 最大使用内存不应该超过 20G 。

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是 " 多读少写 " 。

对于这种场景，我们可以使如下这种架构：

环境配置

基本配置

配从库不配主库，从库配置：

• slaveof 主库ip 主库端口 # 配置主从
• Info replication # 查看信息

每次与 master 断开之后，都需要重新连接，除非你配置进 redis.conf 文件！

修改配置文件！

准备工作：我们配置主从复制，至少需要三个，一主二从！配置三个客户端！

 1、拷贝多个redis.conf 文件

2 、指定端口 6379 ，依次类推

3 、开启 daemonize yes

4 、 Pid 文件名字 pidfile /var/run/redis_6379.pid , 依次类推

5 、 Log 文件名字 logfile "6379.log" , 依次类推

6 、 Dump.rdb 名字 dbfilename dump6379.rdb , 依次类推

上面都配置完毕后，3个服务通过3个不同的配置文件开启，我们的准备环境就OK 了！  

一主二从

一主二仆

清理容器（可选)

docker rm -f $(docker ps -aq)

启动主服务器

# --net=host 容器直接使用宿主机的端口，不需要做端口映射
docker run -d --name redis6379 --net=host --restart=always redis

# 进入容器，运行redis客户端
docker exec -it redis6379 redis-cli

# 查看集群信息，默认是主服务器
> info replication

启动两个从服务器

# 启动redis6380容器，作为 redis6379 的从服务器启动
# --port 和 --slaveof 是 redis-server 命令的参数
docker run -d --name redis6380 --net=host --restart=always redis \
redis-server --port 6380 --slaveof 192.168.64.150 6379

# 启动redis6381容器，作为 redis6379 的从服务器启动
docker run -d --name redis6381 --net=host --restart=always redis \
redis-server --port 6381 --slaveof 192.168.64.150 6379

# 查看三个 redis 服务的角色
docker exec -it redis6379 redis-cli
> info replication

docker exec -it redis6380 redis-cli -p 6380
> info replication

docker exec -it redis6381 redis-cli -p 6381
> info replication

1、环境初始化

 

 

 默认三个都是Master 主节点

 2、配置为一个Master 两个Slave

 3、在主机设置值，在从机都可以取到！从机不能写值！

测试一：主机挂了，查看从机信息，主机恢复，再次查看信息

测试二：从机挂了，查看主机信息，从机恢复，查看从机信息

层层链路

上一个 Slave 可以是下一个 slave 和 Master ， Slave 同样可以接收其他 slaves 的连接和同步请求，那么该 slave 作为了链条中下一个的 master ，可以有效减轻 master 的写压力！

 

 测试：6379 设置值以后 6380 和 6381 都可以获取到！OK！

谋朝篡位

一主二从的情况下，如果主机断了，从机可以使用命令 SLAVEOF NO ONE 将自己改为主机！这个时 候其余的从机链接到这个节点。对一个从属服务器执行命令 SLAVEOF NO ONE 将使得这个从属服务器 关闭复制功能，并从从属服务器转变回主服务器，原来同步所得的数据集不会被丢弃。

 主机再回来，也只是一个光杆司令了，从机为了正常使用跑到了新的主机上！

复制原理

Slave 启动成功连接到 master 后会发送一个 sync 命令

Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后， master 将传送整个数据文件到 slave ，并完成一次完全同步。

全量复制：而 slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制： Master 继续将新的所有收集到的修改命令依次传给 slave ，完成同步

但是只要是重新连接 master ，一次完全同步（全量复制）将被自动执行

哨兵模式

概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑

哨兵模式。 Redis 从 2.8 开始正式提供了 Sentinel （哨兵） 架构来解决这个问题。

谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是 哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。

这里的哨兵有两个作用

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

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

假设主服务器宕机，哨兵 1 先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵 1 主观的认为主服务器不可用，这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用，并且数量达到一 定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进 failover[ 故障转移 ] 操作。 切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线 。

配置测试

1 、调整结构， 6379 带着 80 、 81

2 、自定义的 /myredis 目录下新建 sentinel.conf 文件，名字千万不要错

3 、配置哨兵，填写内容

• sentinel monitor 被监控主机名字 127.0.0.1 6379 1
• 上面最后一个数字1，表示主机挂掉后slave投票看让谁接替成为主机，得票数多少后成为主机

4 、启动哨兵

• Redis-sentinel /myredis/sentinel.conf
• 上述目录依照各自的实际情况配置，可能目录不同

5 、正常主从演示

6 、原有的 Master 挂了

7 、投票新选

8 、重新主从继续开工， info replication 查查看

9 、问题：如果之前的 master 重启回来，会不会双 master 冲突？ 之前的回来只能做小弟了

哨兵模式的优缺点

优点

1. 哨兵集群模式是基于主从模式的，所有主从的优点，哨兵模式同样具有。
2. 主从可以切换，故障可以转移，系统可用性更好。
3. 哨兵模式是主从模式的升级，系统更健壮，可用性更高。

缺点

1. Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。
2. 实现哨兵模式的配置也不简单，甚至可以说有些繁琐

哨兵配置说明

# Example sentinel.conf

# 哨兵 sentinel 实例运行的端口 默认 26379

port 26379

# 哨兵 sentinel 的工作目录

dir /tmp

# 哨兵 sentinel 监控的 redis 主节点的 ip port

# master-name 可以自己命名的主节点名字 只能由字母 A-z 、数字 0-9 、这三个字符 ".-_" 组成。

# 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