版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/Francis123580/article/details/82494441
配置复制
- 配置文件添加：
slaveof {masterHost} {masterPort}，随启动生效 - redis-server启动命令后：
--slaveof {masterHost} {masterPort}，生效 - 直接使用命令：
slaveof {masterHost} {masterPort}，生效
其它命令
- 查看复制状态：
info replication - 断开复制：
slaveof no one - 开启传输延迟：
repl-disable-tcp-nodelay
数据同步
- 全量复制：初次复制场景，数据量大时，会对主从节点和网络造成很大开销
- 部分复制：主从复制中网络闪断，主节点会补发丢失数据给从节点
全量复制流程
- 发送
psync ? -1命令进行数据同步 - 主节点解析当前为全量复制，回复
+ FULRESYNC响应 - 从节点接收主节点的响应数据，保存运行ID 和 偏移量offset
- 主节点执行
bgsave保存RDB文件到本地 - 主节点发送RDB文件给从节点，从节点把接收的RDB文件保存在本地
- 从节点接收RDB快照期间，主节点把其它读写命令保存在客户端缓冲区，接收完成后再发送
- 从节点接收完主节点全部数据后会清空自身旧数据
- 从节点清空数据后开始加载RDB文件
- 从节点加载完RDB文件后，如果开启了AOF功能，会立刻做 bgrewriteaof 操作
部分复制流程
- 当主从节点之间网络中断超过 repl-time 时间，主节点认为从节点故障并中断复制连接
- 主从连接中断期间主节点把最近的写命令数据保存在复制积压缓冲区
- 主节点网络恢复后，从节点会再次连上主节点
- 主从连接恢复后，从节点发送 psync 进行部分复制操作
- 主节点把复制积压缓冲区里的数据发送给从节点
心跳判断机制
- 主从节点彼此有心跳监测机制，各自模拟成对方客户端进行通信，查看客户端信息
- 主节点默认每10秒对从节点发送
ping命令，判断连接状态 - 从节点在主线程每1秒发送
replconf ask {offset}命令，报告复制偏移量
异步复制
- 主节点自身处理完写命令后直接返回给客户端，并不等待从节点复制完成
- 从节点稍后会和主节点保持一致（延迟1秒以内）
场景问题
读写分离 - 数据延迟
- 在异步复制特性的基础上，由于网络带宽和命令阻塞，延迟无法避免
- 编写外部监控程序监听主从节点的偏移量，延迟较大时通知客户端避免读取延迟高的节点
读写分离 - 读到过期数据
- 惰性删除：主节点每次读取命令时，都会检查该键是否超时，超时则执行 del
- 定时删除：主节点定期循环采样，发现键过期则执行 del
- 升级到3.2版本，从节点读取键时会判断是否过期
读写分离 - 从节点故障
- 客户端维护可用从节点列表
- 从节点故障时立刻切换到其它从节点或主节点
主从配置不一致
- 内存相关配置需要一致
- 如果maxmemory从节点小于主节点，从节点数据因为maxmemory-policy策略而丢失
规避全量复制
- 第一次建立复制：在低峰时进行操作 或 尽量规避使用大数据量的Redis节点
- 节点运行ID不匹配：主节点故障重启导致ID改变，这种情况从架构上规避，提供故障转移功能
- 复制积压缓冲区不足：网络中断后，从节点连上主节点请求部分复制，如果偏移量不在积压缓冲区内，则退化为全量复制
规避复制风暴 - 单主节点复制风暴
- 主节点挂载多个从节点，主节点重启恢复后，从节点发起全量复制流程
- 同时向多个从节点发送RDB快照造成网络带宽消耗严重，延迟变大
- 解决：减少从节点 或 采用树状复制结构
规避复制风暴 - 单机器复制风暴
- 一台机器部署多个Redis实例（主节点）
- 此机器故障重启后，会有大量从节点进行全量复制，耗尽带宽
- 解决：主节点分散多台机器 或 主节点提供故障转移机制