Redis复制和原理与优化

什么是主从复制

单机有什么问题?

单机器故障,内存、硬盘、或主板故障,不可避免的错误。一旦故障导致整个服务死掉,client无法访问。

主从复制的作用

为redis提供高可用,当一台Mster节点,死机后能够快速的有一台一模一样的机器去替代它

  • 数据副本
  • 扩展读的性能

结构模式

  • 一主一从
  • 一主多从
  • 主从从

主从工作原理

  • slave向master发送sync命令

  • Master启动后台”存盘进程”,同时收集所有修改数据命令

  • Master执行完后台”存盘进程”后,传送整个数据文件到slave

  • Slave接收数据文件后,将其存盘并加载到内存中完成首次完全同步 -> 全量同步

  • 后续有新数据产生时,master继续将新的所以收集到的修改命令依次传给slave,完成同步

实现主从两种同步方式

  • 命令实现:slaveof

取消复制

此时此刻的从终止对指定master的数据同步,当想更改Master的时候一定要清除上一次同步的内容

  • 配置文件修改
slaveof ip port
salve-read-only yes
  • 命令和配置文件的比较

实际的配置效果

mkdir-p ./conf/{redis-3680,redis-3681}/
cp redis.conf conf/redis-3680/3681/改名

修改配置文件

bind 1270.0.0.1
port 6380       #(默认6379)
pidfile /var/run/redis_6380.pid     #进程的PID
logfile "6380.log"      #不同的日志文件名称
daemonize yes       #守护进程
dbfilename dump-3680.rdb        #主从复制依赖RDB,使用的都是一个工作目录文件一样就导致串在一起,主和从不能使用一个RDB文件。(单机)
masterauth 密码       #如果主节点有密码则需要配置

查看配置是否主从同步

info replication

测试主从

全量复制和部分复制

流程图

解释

  • 1.当我开启主从同步之后,从服务会主动给master发送一个psync [run_id] [主_偏移量],不知道会发送?-1
  • 2.master收到信息回复从节点[自己的run_id] [单前偏移量(offset)]
  • 3.当收到来自主的信息后slave会主动的保存master的信息
  • 4.master主动生成bgsave快照,自动写入信息,repl_back_buffer记录变化。
  • 5.将制作好的RDB发送给slave
  • 6.将收集到的BUFFER发送给slave
  • 7.当收到master的buffer后会自动的删除老旧的数据
  • 8.将RDB文件进行加载,同时也会加在buffer文件,这样就是实现了主从同步的功能

全量复制的开销

  • 1.bgsave时间

  • 2.RDB文件网络传输时间

  • 3.从节点清空数据时间

  • 4.从节点加载RDB的时间

  • 5.可能的AOF重写时间

部分复制

故障处理

主从结构-故障转移

  • slave宕机

  • master宕机

开发和运维中的问题

  • 1.读写分离

  • 2.主从配置不一致

  • 3.规避全量复制

  • 4.规避复制风暴

读写分离

  • 读写分离:读流量分摊到从节点

  • 现代互联中大多数都是读的业务多,写的少

可能遇见的问题

  • 复制数据延迟

  • 读到过期数据

  • 从节点问题

配置不一致

  • maxmemory不一致:丢失数据

  • 数据结构优化参数(例如hash-max-ziplist-entries):内存不一致

规避全量复制

第一次全量复制

  • 是无法避免的。

  • 小主节点、低峰

节点运行ID不匹配

  • 主节点重启(运行ID变化)

  • 故障转移,例如哨兵或集群

复制积压缓冲区不足

  • 网络中断,部分复制无法满足

  • 增大复制缓冲区配置rel_backlog_siza,网络“增强”。

规避复制风暴

单主节点复制风暴

  • 问题:主节点重启,多从节点复制

  • 解决:更换复制拓扑

单机器复制风暴

  • 机器宕机后,大量全量复制

  • 主节点分散多机器

发表评论

电子邮件地址不会被公开。 必填项已用*标注