5.redis-复制的原理与优化

1.什么是主从复制
2.单机有什么问题？
(1)机器故障
(2)容量瓶颈
(3)QPS瓶颈
3.主从复制的模型：
(1)一主一从模型

(2)一主多从模型

4.主从复制的作用
(1)数据副本
(2)扩展读性能
5.主从复制需要注意的地方：
一个master可以有多个slave
一个slave只能有一个master
数据流向是单向的，master到slave
6.复制的配置
(1)两种实现方式
方式一：slaveof命令(优点：无需重启，缺点：不变于管理)
<1>设置：
master(主)：127.0.0.1端口6379
slave(从)：127.0.0.1端口6380
127.0.0.1:6379> slaveof 127.0.0.1 6380
OK
<2>取消：
master(主)：127.0.0.1端口6379
slave(从)：127.0.0.1端口6380
通过命令在slave：127.0.0.1端口6380上取消掉主从复制
127.0.0.1:6380> slaveof no one
OK
方式二：配置文件(优点：统一配置，缺点：需要重启)
<1>在从配置文件配将要同步的主ip和端口
slaveof 127.0.0.1 6379
#从节点只做读的操作
slave-read-noly yes
<2>启动主从
启动主：./redis-server ../data/redis-6379.conf
启动从：./redis-server ../data/redis-6380.conf
<3>
master(主)：127.0.0.1端口6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=15,lag=1
master_repl_offset:15(偏移量)
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:14
在主节点写入一条命令：
127.0.0.1:6379> set xixi 18
OK
127.0.0.1:6379> get xixi
"18"
<4>
slave(从)：127.0.0.1端口6380
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1(主ip)
master_port:6379(主端口)
master_link_status:up(成功)
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:15(从节点会向主节点做一个上报，会把从节点的状态同步给主节点，这样主节点就知道从节点的偏移量)
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
从节点查看是否同步成功
127.0.0.1:6380> get xixi
"18"
从节点是不可以自己写入任何
127.0.0.1:6380> set xixia 18a
(error) READONLY You can't write against a read only slave.
从节点取消对主节点的关系
127.0.0.1:6380> slaveof no one
OK
查看取消后
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:1301
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
7.全量复制
(1)全量复制：
(2)全量复制的流程
首先slave内部向master发送一条命令psync ? -1，master接收到命令能感觉到需要做全量复制的，因为跟本不知道我是谁也没有传偏移量,然后master告诉slave自己的偏移量和run_id是多少，slave会保存master的基本信息，master会做一个bgsave快照，master将本身的RDB文件同步到slave，在此期间，master会通过send buffer记录最新写入的命令，当slave的接收完RDB文件后紧接着收master传来的最新写入的命令，等都接收完毕后，清空本地内容，加载RDB文件和最新的命令，最后，master会通过偏移量的对比，将这个期间产生的值同步到slave
(3)全量复制的开销
<1>master节点bgsaver时间(对CPU，内存，硬盘都会有一定开销)
<2>>master节点RDB文件网络传输时间(占用网络带宽资源)
<3>从节点清空数据时间
<4>从节点加载RDB的时间
<5>从节点如果AOF开启，AOF重写的时间
8.部分复制：如果发生网络抖动造成主从复制长期没有复制成功，可以使用部分复制
(1)部分复制的流程
当slave跟master发生网络抖动，slave连接master失败，master会写入一份repl_back_buffer复制缓冲区的命令。当slave再次连接master成功的时候，会执行一条命令pysnc{offset}{runid}，把自己的offset和runid给master，告诉当前偏移量是多少，master接收到发现如果偏移量在当前repl_back_buffer的范围内的，如果在这个队列内，会返回continue,将数据发给slave,如果超过范围会执行全量复制
9.故障处理-自动故障转移
主从结构-故障转移
(1)slave宕掉
主从复制，一主两从，做读写分离

 

如果一个slave宕，把一个客户端改到另一个slave上
(2)master宕掉
主从复制，一主两从，做读写分离

 

主客户端从两个从客户端找一个客户端做主客户端
10.开发运维常见问题
(1)读写分离：读流量分摊到从节点
<1>可能遇到的问题：
复制数据延迟
读到过期数据
从节点故障
(2)主从配置不一致
例如maxmemory不一致：丢失数据
例如数据结构化参数(列如hash-max-ziplist-entries)：内存不一致
(3)规避全量复制
<1>第一次全量复制
第一次不可避免
小主节点，低峰
<2>节点运行ID不匹配
主节点重启(运行ID变化)
故障转移
<3>复制积压缓冲区不足
网络中断，部分复制无法满足
增大复制缓冲区配置rel_backlog_size,网络，"增强"
(4)规避复制风暴
<1>单主节点复制风暴：
问题：主节点重启，多从节点复制
解决：更换复制拓扑
<2>单机器复制风暴
机器宕机后，大量全量复制
主节点分散多机器