redis主从复制初识

一、作用

• 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:345dda992e5064bc80e01f96ea90f729b722b2ea

2.偏移量

通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。

• 参与复制的主从节点都会维护自身的复制偏移量。主节点（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.单机器复制风暴

• 如下图：机器宕机后，大量全量复制

• 解决：主节点分散多机器

•