Redis主从集群搭建及主从复制原理解析

Redis框架除缓存之外的实用功能

前言

上篇文章主要介绍redis的实用功能，也就是数据类型。包括string、hash、set、zset、发布订阅、stream等类型；并解析了他们的应用场景；本篇文章会紧接着写redis主从集群的搭建，并详解其中配置，以及主从复制的原理解析。

高可用主从集群

在Redis中要达到高可用，有两种集群架构方式，有分片和主从集群，这里讨论的是读多写少的场景采用主从集群。 

redis 配置及 常见命令展示.zip 提取码:jrd3

主从复制架构分析

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。

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

在集群中都是有状态的节点，每个节点都会有自己的数据，可能会导致一些问题的出现，最显示的问题就是数据一致性问题，网络出现异常时数据问题。  

主从复制的好处

1. 数据冗余 持久化：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。利用从节点达到数据持久化，而不是单独依靠主节点实现，从而实现提升主性能
2. 故障恢复 转移 容灾：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。   
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。 单台集群Qps有限，从节点进行分担。
4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制应用场景分析

• 读写分离场景，规避redis单机瓶颈
• 故障切换，master出问题后还有slave节点可以使用

主从集群

主Redis Server以普通模式启动， 主要是启动从服务器的方式 ，比较简单，通过三种方式去启动

• 第一种方式：命令行
• 第二种方式：redis.conf 配置文件

# 配置文件中增加
slaveof [ip] [port]
# 从服务器是否只读(默认yes)
slave-read-only yes

搭建一个主从服务器

对于master ，什么都不用做，默认启动就是

对于slave,需要指定 主服务器

首先启动redis

进入客户端  ，通过命令行来指定

 在打印的日志就能看到去连接master的信息

 并且能看到同步的过程

分析启动的过程这里有个replicationid ，会将这个id发master 节点，使之成为master节点的从节点

携带的偏移量和 replicationid   复制流程

• 从服务器通过psync命令发送服务器已有的同步进度(同步源ID、同步进度offset)

• master收到请求，同步源为当前master，则根据偏移量增量同步  通过 replicationid进行判断是否是同步的master

• 同步源非当前master，则进入全量同步：master生成rdb，传输到slave，加载到slave内存

退出主从集群的方式

Slaveof no one

查看主从复制信息

 登录客户端直接使用 info replication 命令就能看到， 也是来自 replicationid 的

这里的角色为master时，信息展示位

• role:master   角色 为主服务器
• connected_slaves:1   当前从服务器数量1
• 从服务器信息  包括 ip  端口号，和状态 ，以及偏移量等等 

  slave0:ip=127.0.0.1,port=6380,state=online,offset =15,lag=1
•  同步的replicationid   maseter_repliid 
• 当出现故障时用于选举新的master的 maseter_repliid 
• master_repl_offset  计数器，主节点复制偏移量(复制的字节数)
• 主从同步缓存区  

        repl_backlog_active:1

        repl_backlog_size:1048576

        repl_backlog_first_byte_offset:2

        repl_backlog_histlen:14

故障转移情况下的同步

当角色为slave 从节点时

信息展示为

• 从节点优先级  slave_priority:100
• 是否为只读节点 slave_read_only
• 同步的进度 master_sync_in_progress
• 同步的偏移量 master_repl_offset
• 包括下面的 缓冲区信息  backlog

# 角色 master或者 slave
role:master
# 已连接的Redis从机的数量
connected_slaves:0
# 主从复制过程中master的标识id
master_replid:6ea01bd968c7f14cb6de138462ddaf11930a4269
master_replid2:0000000000000000000000000000000000000000
# 全局的复制偏移量
master_repl_offset:0
second_repl_offset:-1
# 表示Redis服务器是否为部分同步开启复制备份日志
repl_backlog_active:0
# 备份日志的循环缓冲区的大小
repl_backlog_size:1048576
# 备份日志缓冲区中的首个字节的复制偏移量
repl_backlog_first_byte_offset:0
# 备份日志的实际数据长度
repl_backlog_histlen:0
# 主从复制情况下可能会有的一些额外信息
# master_host：Redis主机的主机名或IP地址
# master_port：Redis主机监听的TCP端口
# master_link_status：链路状态（连接/断开
# master_last_io_seconds_ago：最近一次和Redis主机交互至今的消耗时间，以秒为单位
# master_sync_in_progress：表示Redis主机正在将数据同步至从机
# master_sync_left_bytes：在同步完成之前，还剩余的数据总量，以字节为单位
# master_sync_last_io_seconds_ago：在一次SYNC操作期间，最近一次传输数据的I/O操作至今的消耗时间，以秒为单位
# master_link_down_since_seconds：从链路断开至今的时间，以秒为单位

主从复制流程

 当数据写入到master时，通过开启子线程去同步数据给从节点

这里会涉及到一个问题，当有 新的子从节点添加到 master下时，网络比较不好，master在不断更新数据，在master中会堆积大量的更新数据，redis会更具同步时间，不在同步

 主从复制核心原理

• Redis 默认使用异步复制，slave 和 master 之间异步地确认处理的数据
• 一个master可以拥有多个slave
• slave可以接受其他slave的链接。slave可以有下级sub slave
• 主从同步过程master侧是非阻塞的
• slave初次同步需要删除旧数据，加载新数据，会阻塞到来的连接请求

这里可以允许一部分数据丢失。

 网速够快的话，直接使用传输，不用rdb的方式

在redis.conf中开启

repl-diskless-sync no
#  主从数据复制是否使用无硬盘复制功能。
#  新的从站和重连后不能继续备份的从站，需要做所谓的“完全备份”，即将一个RDB文件从主站传送到从站。
#  这个传送有以下两种方式：
#  1）硬盘备份：redis主站创建一个新的进程，用于把RDB文件写到硬盘上。过一会儿，其父进程递增地将文件传送给从站。
#  2）无硬盘备份：redis主站创建一个新的进程，子进程直接把RDB文件写到从站的套接字，不需要用到硬盘。
#  在硬盘备份的情况下，主站的子进程生成RDB文件。一旦生成，多个从站可以立即排成队列使用主站的RDB文件。
#  在无硬盘备份的情况下，一次RDB传送开始，新的从站到达后，需要等待现在的传送结束，才能开启新的传送。
#  如果使用无硬盘备份，主站会在开始传送之间等待一段时间（可配置，以秒为单位），希望等待多个子站到达后并行传送。
#  在硬盘低速而网络高速（高带宽）情况下，无硬盘备份更好。

 以及下面的延迟同步的时间

repl-diskless-sync-delay 5
#  当启用无硬盘备份，服务器等待一段时间后才会通过套接字向从站传送RDB文件，这个等待时间是可配置的。
#  这一点很重要，因为一旦传送开始，就不可能再为一个新到达的从站服务。从站则要排队等待下一次RDB传送。因此服务器等待一段
#  时间以期更多的从站到达。
#  延迟时间以秒为单位，默认为5秒。要关掉这一功能，只需将它设置为0秒，传送会立即启动。

Redis 集群的目标

Redis 集群是 Redis 的一个分布式实现，主要是为了实现以下这些目标（按在设计中的重要性排序）：

• 在1000个节点的时候仍能表现得很好并且可扩展性（scalability）是线性的。
• 没有合并操作，这样在 Redis 的数据模型中最典型的大数据值中也能有很好的表现。
• 写入安全（Write safety）：那些与大多数节点相连的客户端所做的写入操作，系统尝试全部都保存下来。不过公认的，还是会有小部分（small windows?）写入会丢失。
• 可用性（Availability）：在绝大多数的主节点（master node）是可达的，并且对于每一个不可达的主节点都至少有一个它的从节点（slave）可达的情况下，Redis 集群仍能进行分区（partitions）操作。

主从复制的注意事项

如何读写分离的情况下数据尽量不丢失

在reads.conf中可以设置配置，其次redis是异步进行写入的，因此 他并不管数据是否完整写入了。

# min-replicas-to-write 3
# min-replicas-max-lag 10
#  主站可以停止接受写请求，当与它连接的从站少于N个，滞后少于M秒，N个从站必须是在线状态。
#  延迟的秒数必须<=所定义的值，延迟秒数是从最后一次收到的来自从站的ping开始计算。ping通常是每秒一次。
#  这一选项并不保证N个备份都会接受写请求，但是会限制在指定秒数内由于从站数量不够导致的写操作丢失的情况。
#  如果想要至少3个从站且延迟少于10秒，如上配置即可

 读写分离场景：

• 数据复制延时导致读到过期数据或者读不到数据（网络原因、slave阻塞）

• 从节点故障（多个client如何迁移）

全量复制情况下：

• 第一次建立主从关系或者runid不匹配会导致全量复制
• 故障转移的时候也会出现全量复制

复制风暴：

• master故障重启，如果slave节点较多，所有slave都要复制，对服务器的性能，网络的压力都有很大影响。
• 如果一个机器部署了多个master

写能力有限

• 主从复制还是只有一台master，提供的写服务能力有限

master故障情况下：

• 如果是master无持久化，slave开启持久化来保留数据的场景，建议不要配置redis自动重启。
• 启动redis自动重启，master启动后，无备份数据，可能导致集群数据丢失的情况下。

带有效期的key：

• slave不会让key过期，而是等待 master 让 key 过期
•  在Lua脚本执行期间，不执行任何 key 过期操作