Redis高可用之主从架构实战

系列文章目录

真正说透Redis五种数据结构
Redis持久化之RDB+AOF+混合持久化实战演练
Redis高可用之主从架构

---

---

前言

前面一些文章讲述了Redis的数据结构以及使用场景，持久化方式以及优缺点，本文主要讲解Redis的主从架构，Redis中文文档，主从的安装请查看Docker/Podman安装Redis主从，文中一些关于配置的详解请参考配置文件

---

一、主从复制介绍

1、作用

1. 读写分离，解决主节点压力
2. 数据备份，从节点当做备份使用
3. 哨兵模式高可用的基础

2、架构

1. 一主多从
   

2. 一主多从，一从多从

使用多从节点可以缓解一主多从情况下带来的复制风暴问题（多个从节点同时连接主节点导致主节点压力过大）

3、复制操作两种方式

• 手工方式
  在从节点上执行 CONFIG SET masterauth 【主节点密码】设置主节点密码，然后执行 REPLICAOF IP port，就可以加入主节点，重启后失效
• 配置方式 （推荐）

replicaof ip port
masterauth 【密码】

二、主从架构的数据同步方式

1、全量同步

1、从节点与主节点建立连接
2、从节点发生psync命令给主节点进行数据同步
3、主节点fork子进行执行bgsave生成RDB快照文件（client-output-buffer-limit replica 256mb 64mb 60 ，标识复制过程快照一旦超过256mb，又或者超过64mb持续60秒，那么服务器就会立即断开客户端连接）
4、主节点主进程正常接受客户端命令，所有的操作都会放到缓冲区中（repl-backlog-size ，默认是1M）
5、快照生成完毕后，将RDB快照发生给slave节点
6、slave节点收到RDB文件后，slave会先将其写入磁盘后会清空自己的旧数据，然后将RDB文件写到自己的内存中，如果从节点开启了AOF，那么会立即执BGREWRITEAOF，重写AOF。
7、master继续将之前缓存在内存中的命令发送给slave
8、master后续命令持续发给slave，后续的同步都是异步的

注意一

当从库同主库失去连接或者复制正在进行，在slave节点有两种工作方式提供配置
1：当配置文件中replica-serve-stale-data设置为yes(默认)时，从库会继续响应客户端的请求
2：设置为no时，除了AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG,SUBSCRIBE, UNSUBSCRIBE,PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB,COMMAND, POST, HOST: and LATENCY命令之外的任何请求都会返回一个错误”SYNC with master in progress”给客户端
但是在slave节点收到RDB文件后，需要删除旧的数据且将新的数据加载到内存中，在这期间，slave节点会阻塞客户端的请求（Redis 4.0 开始，可以配置 Redis 使删除旧数据集的操作在另一个不同的线程中进行，但是，加载新数据集的操作依然需要在主线程中进行并且会阻塞 slave）

注意二

在特殊情况下，当master 收到了多个 slave 要求同步的请求，它会执行一个一次RDB快照文件，以便于为多个 slave 服务

如果复制的数据量在4G~6G之间，那么很可能全量复制时间消耗到1分半到2分钟

2、增量同步

在redis2.8版本后，主从数据同步支持增量复制，因为slave节点有可能因为网络抖动而发生重连，如果进行全量同步，会产生不必要的性能开销。所以master会在其内存中创建一个复制数据用的环形缓存队列repl-backlog-size，默认是1M，master和slave都维护了最新的数据的偏移量offset。增量同步过程如下

1、从节点与主节点建立连接
2、从节点发生psync命令，并带上slave的复制偏移量（offset，master runId）给主节点进行数据同步
3、master节点会判断当前slave的offset是否在缓冲区中，如存在，master将缓冲区中offset之后的数据同步给slave节点，否则就会走全量同步的流程

满足增量复制前提

1、从节点如果第一次连接主节点，则执行全量复制
2、如果主节点判断从节点发生的runid与当前不至于，则全量复制
3、若从节点发生的偏移量不在缓冲区中，则全量复制
4、若上述情况都不满足，则发生增量复制

问题

测试了多种场景增量复制，但是每次都是全量复制，不知道哪里出现了问题，日志如下。
主节点日志

从节点日志

三、主从架构下的注意点

1、为什么使用runid而不是ip+port

如果根据IP+PORT作为master的标识是不准的，例如master没有做持久化，或者直接更换了master的持久化数据后重启，那么此时master的历史数据是发生了变化的，那么此时从节点若连接master后，可能slave节点不做全量同步，那么数据就发生了不一致的情况。也可以指定master重启后不更改runID，使用命令redis-cli debug reload

2、主从架构下过期key处理

在Redis 3.2版本之前，从节点不会主动删除过期的数据，而是等待主节点发生del命令进行删除，那么这种情况下会有一定的延迟，所有从节点可能会读取到过期的数据，在Redis 3.2版本之后，根据官网上描述从节点对过期key的处理

1. 从节点不会主动删除过期键，而是等主节点过期时生成 DEL 命令同步至从节点进行删除
2. 由于master 无法及时提供DEL命令，从节点使用其逻辑时钟来判断数据是否过期，若过期则不返回给客户端，而是等待master发生del命令
3. 在Lua脚本运行时，不会判断key到期处理。因为在执行脚本时，key有可能在脚本执行中间过期，但是此时master上的数据的时间是被冻结的（相当于事务的概念），所以从节点也需要保持数据的一致性。

3、master节点配置最小N个slave下才能写入功能

从 Redis 2.8 开始，可以将 Redis master节点配置为仅在当前至少有 N 个副本连接到主服务器时才接受写入查询，通过配置文件中min-replicas-to-write进行配置，当不满足时，主节点写入会报错 NOREPLICAS Not enough good replicas to write

4、主节点无持久化的问题

在主从架构中，尽量不要关闭master的持久化功能，因为master节点重启会导致master节点的数据会丢失，那么slave节点在master节点重启后会进行同步，这时数据就会丢失。 如果master 使用复制功能的同时未配置持久化，那么自动重启进程这项就该被禁用

---

总结

以上就是本人对于redis主从架构的实践以及查阅资料得到的理解，可能存在不对之处，包括存在不能理解的地方，欢迎大家在评论区指导，也能帮助本人得到更好的理解，谢谢大家