Redis Replication

Redis Replication

1、前言

在单节点搞事情, 存在的问题包括存量问题和增量问题两类, 解决方案就是1个不行上N个, 做到单机维度宕机但服务维度是可用的。

1.1 存量问题

如果目前的单节点QPS满足(也就是综合瓶颈还没达到), 那么只有宕机能影响到。如果业务量不大, 又是出于成本考虑, 做好宕机自动重启, 就是可用性差点其他没毛病。

1.2 增量问题

1. 内存资源瓶颈, 单节点的Redis宕机时，会导致缓存不可用。比如原来4G, 后来有钱要升级到16G, 因为不能停没法升级;
2. CPU资源瓶颈, CPU的利用率上，单台Redis实例只能利用单个核心。
3. 综合瓶颈(CPU+内存+网络带宽), 单节点的Redis能够支撑QPS大概在5W左右，超过之后就成为高并发的瓶颈, 然而在单节点上这些都无法升级;

2 复制的作用

2.1 数据冗余

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

2.2 故障恢复

当主节点出现了问题，可以由从节点提供服务，实现快速的故障恢复, 算是一种服务级别的冗余。

2.3 负载均衡

在主从复制的基础上, 配合读写分离, 分担数据读取负载。尤其是在写少读多的情况下，通过多个从节点分担读负载，可以大大提高redis服务器的并发量。

2.4 高可用基础

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

3. 复制的实现

Redis的复制包括两个阶段, 全量同步和增量同步;

3.1 角色说明

1. 复制包含两个角色, master和slave, 其中slave复制master中的数据;
2. 一个master实例可以有多个slave实例;
3. 一个slave实例则只能有一个master实例;
4. 一个slave实例可以从任何角色的实例上复制数据, 这意味着replication支持级联;

3.2 全量同步

使用场景

slave节点首次同步master数据, 同步内容包含RDB快照, 以及在RDB快照同步期间缓存的数据更新命令(存储在ReplicationBuffer中)。

具体流程

slave master Connect Connected PING PONG 1. PSYNC ? -1 (全量复制) 2. FLULLRSYNC {runset} {offset} (设置当前快照位置) 3.1 save server info 3.2 bgsave RDB (创建快照), 并将之后的命令写入ReplicationBuffer 4. send RDB (发送快照) 5. 对当前DB flushall后基于接收的RDB恢复 6. 发送快照到现在ReplicationBuffer中的命令 7. 回放ReplicationBuffer中的命令 slave master

3.3 增量同步

使用场景

slave节点临时与master节点断开, 后续又建立连接。此时slave节点的offset依然可以在master的ReplicationBacklogBuffer中找到。

具体流程

slave master Connect Connected 1. PSYNC {runset} {offset} (增量复制) 2. + CONTINUE 3. send partical data slave master

4. 配置参数

参数	说明
replica-ignore-maxmemory	在slave节点对带有TTL key的删除依赖于master节点生成的del命令, 因此可能会使用更多的内存。在完全一致的配置参数下可能会有问题, 因此在slave节点建议设置为yes
replica-read-only	slave节点是否只读
replica-lazy-flush	slave节点进行全量同步时flush本地DB的过程是同步还是异步
repl-ping-replica-period	slave节点与master节点之间的心跳间隔, 保持master和slave的链接有效性
replica-serve-stale-data	在slave节点与master节点做全量同步过程中, 是否响应client请求
repl-backlog-size	复制积压缓冲区大小, 每秒产生的命令 *（master执行rdb bgsave的时间）+ (master发送rdb到slave的时间) + (slave load rdb文件的时间) ，来估算积压缓冲区的大小，repl-backlog-size 值不小于这两者的乘积。 例如，如果主服务器平均每秒产生1 MB的写数据，而从服务器断线之后平均要5秒才能重新连接上主服务器，那么复制积压缓冲区的大小就不能低于5MB。为了安全起见，可以将复制积压缓冲区的大小设为2*5=10M，这样可以保证绝大部分断线情况都能用增量从而避免全量同步数据。
repl-backlog-ttl	复制积压缓冲区中命令保持的最长时间
repl-timeout	全量复制的超时时间, 如果RDB文件比较大, 可能需要调大该数值
client-output-buffer-limit	不同客户端使用的buffer限制(hard/soft/time),影响全量同步过程中可 normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60。参数值设置太小，就会导致replication_buffer不够用，新增的数据也就无法存入该缓冲区。在Redis 7.0下, master会提示由于overcoming of output buffer limits而停止数据发送, slave则持续在全量同步阶段等待。 待超时之后, slave重新发起同步, 最终slave永远都无法全量同步成功, 从而影响到整个服务的性能和质量。

5. 极限测试

5.1 slave复制自己

1. 配置操作可以成功;
2. 日志显示开启成功连接并响应PING, 然后开始尝试部分复制, 但是没有什么数据可以复制, client断开链接;

Master is currently unable to PSYNC but should be in the future: -NOMASTERLINK Can't SYNC while not connected with my master

3. 循环1,2直到timeout, slave认为master无法复制停止;

6. 总结

本文介绍了Redis Replication的作用，以及相关的阶段和具体实现，希望能帮助你更好地理解Redis Replication的实现，感谢您的阅读。