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>单机器复制风暴
机器宕机后,大量全量复制
主节点分散多机器

原文地址:https://www.cnblogs.com/xixi18/p/11137281.html