redisson 主从延迟 redis主从复制延时问题

主从复制

（高可用问题）
机器故障：上短时间中不能恢复，我们这时候不能访问Redis的服务了。
（分布式问题）
容量瓶颈：内存不够
qps瓶颈：redis号称能提供十万的qps，但是现在我们现在有个业务是需要搞定一百万的qps
qps指的是每秒查询率。并发量/平均访问时间

一、作用

• 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节点是只读的，不会执行写操作

主从都以配置文件的方式启动。
修改主配置文件中的设置

redis.conf中将bind行注释掉，取消ip绑定可以让任何ip中的客户端访问，也可以设置多个ip的绑定
bind 127.0.0:1 x.x.x.x 以空格方式区分

设置redis访问密码
CONFIG SET requirepass password

修改master的conf

daemonize yes --进程后台启动
pidfile /var/run/redis-master.pid 修改pid文件进行区分
logfile /var/log/redis-slave.log --日志文件
syslog-enabled no --日志不写进系统日志
dir /usr/local/redis/data --数据文件存放
requirepass 123456 --认证密码
port 6379

slave的conf

daemonize yes
pidfile /var/run/redis-slave.pid 修改pid文件进行区分
logfile /var/log/redis-slave.log
syslog-enabled no
dir /usr/local/redis/data
slaveof 192.168.0.1 6379 --主服务器的IP地址和端口
masterauth 123456 --主服务器上的认证密码
port 6380

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

[外链图片转存失败(img-Fx6rVPOl-1562748610118)(F:\workspace\imooc_workspace\carlosfu_workspace\one_redis_workspace\20180925214632675.png)]

二、全量复制的开销

• 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.单机器复制风暴

• 如下图：机器宕机后，大量全量复制
• 解决：主节点分散多机器