主从复制
一、作用
- slave会通过被复制同步master上面的数据，形成数据副本
- 当master节点宕机时，slave可以升级为master节点承担写操作。
- 允许有一主多从，slave可以承担读操作，提高读性能，master承担写操作。即达到读写分离
二、简单性质
- 一个master可以有多个slave
- 每个slave只能有一个master
- 每个slave也可以有自己的多个slave
- 数据流是单向的，从master到slave
三、创建主从的方式
1.slaveof命令
#在希望成为slave的节点中执行以下命令
slaveof ${masterIP} ${masterPort} 此过程会异步地将master节点中的数据全量地复制到当前节点中
2.通过配置实现
| 配置项 | 含义 |
|---|---|
| salveof ${masterIP} \${masterPort} | 设置当前节点作为其他节点的slave节点 |
| slave-read-only yes | 设置当前slave节点是只读的，不会执行写操作 |
3.取消主从的方式
#在不希望作为slave的节点中执行以下命令
salveof no one执行完成之后，该节点的数据不会被清除。而是不会再同步master中的数据
4.查看当前节点是否主从
- info replication
run_id与偏移量
1.run_id
run_id是Redis 服务器的随机标识符，用于 Sentinel 和集群，服务重启后就会改变；
当slave节点复制时发现和之前的 run_id 不同时，将会对数据进行全量同步。
查看runid
redis-cli -p 6379 info server | grep run
run_id:345dda992e5064bc80e01f96ea90f729b722b2ea2.偏移量
通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。
- 参与复制的主从节点都会维护自身的复制偏移量。主节点（master）在处理完写命令后，会把命令的字节长度做累加记录，统计信息在info replication中的master_repl_offset指标中。
- 从节点每秒上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量
- 从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。统计在info replication中的slave_repl_offset指标中
全量复制
一、全量复制流程
1.slave -> master : psync ? -1
- ? 代表当前slave节点不知道master节点的runid
- -1代表当前slave节点的偏移量为-1
2.master -> slave : +FULLRESYNC runId offset
- master通知slave节点需要进行全量复制
- runId：master发送自身节点的runId给slave节点
- offset：master发送自身节点的offset给slave节点
3.slave : save masterInfo
- slave节点保存master节点的相关信息（runId与偏移量）
4.master : bgsave
- master节点通过bgsave命令进行RDB操作
5.master -> slave : send RDB
- master将bgsave完的RDB结果发送给slave节点
6.master -> slave : send buffer
- master在执行写操作时，会将写命令写入repl_back_buffer中
- 为了维护bgsave过程中执行的写操作命令，并同步给slave，master将期间的buffer发送给slave。
7.slave : flush old data
- slave节点将之前的数据全部清空
8.load RDB
- slave节点加载RDB
二、全量复制的开销
- bgsave时间
- RDB文件网络传输时间
- slave节点清空数据时间
- slave节点加载RDB的时间
- 可能的AOF重写时间，当加载完RDB之后，如果开启了AOF重写，需要重写AOF，以保证AOF最新
三、全量复制的高版本优化
在redis4.0中，优化了psync，简称psync2，实现了即使redis实例重启的情况下也能实现部分同步
部分复制
一、部分复制流程
1.slave -> master : Connection lost
- 由于网络抖动等原因，slave对master的网络连接发生中断
2.slave -> master : Connection to master
- slave重新建立与master节点的连接
3.slave -> master : psync runId offset
- slave节点发送master节点的runId以及自身的offset
4.master -> slave ：CONTINUE
- 在第③步中，master节点校验offset，在当前buffer的范围中，则将反馈从节点CONTINUE表示部分复制。
- 如果offset不在当前buffer的范围中，则将反馈从节点FULLRESYNC表示需要全量复制
- buffer的大小默认为1MB，由repl_back_buffer维护
5.master -> slave : send partial data
- 发送部分数据给slave节点让slave节点完成部分复制
故障处理
一、slave宕机故障
- 会影响redis服务的整体读性能，对系统可用性没有影响，将slave节点重新启动并执行slaveof即可。
二、master宕机故障
- redis将无法执行写请求，只有slave节点能执行读请求，影响了系统的可用性
方法1：
- 随机找一个节点，执行slaveof no one，使其成为master节点
- 然后对其他slave节点执行slaveof newMatserIp newMasterPort
方法2：
- 马上重启master节点，它将会重新成为master
开发与运维中的问题
一、读写分离
- 含义：master只承担写请求，读请求分摊到slave节点执行
可能遇到的问题
复制数据延迟
- 当写操作从master同步到slave的时候，会有很短的延迟
- 当网络原因或者slave阻塞时，会有比较长的延迟
- 在这种情况下，可以通过配置一个事务中的读写都在主库得已实现
- 可以通过偏移量对这类问题进行监控
读到过期数据（在v3.2中已经解决）
- 删除过期数据的策略1：操作key的时候校验该key是否过期，如果已经过期，则删除
- 删除过期数据的策略2：redis内部有一个定时任务定时检查key有没有过期，如果采样的速度比不上过期数据的产生速度，会导致很多过期数据没有被删除。
- 在redis集群中，有一个约定，slave节点只能读取数据，而不能操作数据
- 从节点故障
二、配置不一致
maxmemory不一致：可能会丢失数据
- 例如master配置为4G，从节点配置为2G。
- 数据结构优化参数（例如hash-max-ziplist-entries)：导致内存不一致
三、规避全量复制
第一次全量复制
- 第一次不可避免
- 小主节点，低峰处理（夜间）
节点运行ID不匹配
- 主节点重启（运行ID变化）
- 可以使用故障转移进行处理，例如哨兵或集群。
复制积压缓冲区不足
- 如果offset在缓冲区之内，则可以完成部分复制，否则需要全量复制
- 可以增大复制缓冲区的大小：rel_backlog_size，默认1M，可以提升为10MB
四、规避复制风暴
1.单主节点复制风暴
- 问题：主节点重启，多从节点复制
- 解决：更换复制拓扑，由(m-s1,s2,s3)的模式改成（m-s1-s1a,s1b)的模式，可以减轻master的压力
2.单机器复制风暴
- 如下图：机器宕机后，大量全量复制
- 解决：主节点分散多机器
