前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Redis主从复制与优化

Redis主从复制与优化

作者头像
用户2781897
发布2020-12-15 10:12:54
2590
发布2020-12-15 10:12:54
举报
文章被收录于专栏:服务端思维

主从复制

我们关注主从复制之前,首先要考虑单机有什么问题?

  • 机器故障
  • 容量瓶颈
  • QPS瓶颈

这些都是单节点所遇到的问题,所以这个时候出现了主从复制(一主一从,一主多从)

使用主从复制可以:

  • 数据副本
  • 扩展读性能

注意:

  • 一个master可以有多个slave
  • 一个slave只有一个master
  • 数据流向是单向的,master到slave

主从复制的配置

两种实现方式

  • slaveof命令

两台机器:主节点:47.11.11.11 从节点 47.22.22.22

在从节点执行 slaveof 命令

代码语言:javascript
复制
47.22.22.22-6379 > slacefof 47.11.11.11 6379
OK

取消复制:

代码语言:javascript
复制
47.22.22.22-6379 > slacefof no one
OK
  • 修改配置
代码语言:javascript
复制
slaveof ip  port    //从节点ip + 端口
slave-read-only yes //开启只做读的操作
  • 两种方式比较
  • 查看主从
代码语言:javascript
复制
127.0.0.1:6379> info replication
# Replication
role:master   //主节点 
connected_slaves:0
master_replid:1d43401335a5343b27b1638fc9843e3a593fc1a7
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

知识点 :

  • 主节点 runID:

每个redis节点启动后都会动态分配一个40位的十六进制字符串为运行ID。运行ID的主要作用是来唯一识别redis节点,比如从节点保存主节点的运行ID识别自已正在复制是哪个主节点。如果只使用ip+port的方式识别主节点,那么主节点重启变更了整体数据集(如替换RDB/AOF文件),从节点再基于偏移量复制数据将是不安全的,因此当运行ID变化后从节点将做全量复制。可以在info server命令查看当前节点的运行ID。

需要注意的是redis关闭再启动,运行的id会随之变化。


全量复制和部分复制等

全量复制

用于初次复制或其它无法进行部分复制的情况,将主节点中的所有数据都发送给从节点。当数据量过大的时候,会造成很大的网络开销。

redis2.8+ 全量复制流程

开销:

  1. bgsave时间
  2. RDB文件网络传输
  3. 从节点清空数据时间
  4. 从节点加载RDB时间
  5. 可能的AOF重写时间

部分复制

用于处理在主从复制中因网络闪退等原因造成数据丢失场景,当从节点再次连上主节点,如果条件允许,主节点会补发丢失数据给从节点,因为补发的数据远远小于全量数据,可以有效避免全量复制的过高开销。但需要注意,如果网络中断时间过长,造成主节点没有能够完整地保存中断期间执行的写命令,则无法进行部分复制,仍使用全量复制 。

流程:

复制偏移量:

  • 参与复制的主从节点都会维护自身复制偏移量,主节点在处理完写入命令操作后,会把命令的字节长度做累加记录,统计信息在info replication中的master_repl_offset指标中。
  • 从节点每秒钟上报自身的复制偏移量给主节点,因此主节点也会保存从节点的复制偏移量slave0:ip=192.168.1.3,port=6379,state=online,offset=116424,lag=0
  • 从节点在接收到主节点发送的命令后,也会累加记录自身的偏移量。统计信息在info replication中的slave_repl_offset中。

复制积压缓冲区:

  • 复制积压缓冲区是保存在主节点上的一个固定长度的队列,默认大小为1MB,当主节点有连接的从节点时被创建,这时主节点响应写命令时,不但会把命令发给从节点,还会写入复制积压缓冲区。 在命令传播阶段,主节点除了将写命令发送给从节点,还会发送一份给复制积压缓冲区,作为写命令的备份;除了存储写命令,复制积压缓冲区中还存储了其中 的每个字节对应的复制偏移量(offset) 。由于复制积压缓冲区定长且先进先出,所以它保存的是主节点最近执行的写命令;时间较早的写命令会被挤出缓冲区。

生产中常见问题

读写分离

分流到从节点。主节点写数据,从节点读数据,可能遇到读问题

  1. 复制数据延迟
  2. 读到过期数据
  3. 从节点故障

主从配置不一致

  1. 例如maxmemory 不一致 会导致 丢失数据
  2. 例如数据结构优化参数(例如hash-max-ziplist-entries):内存不一致

规避全量复制

  1. 第一次全量复制的时候 - 第一次不可避免,尽量小节点 ,低峰处理
  2. 节点 运行ID不匹配 - 故障转移,例如哨兵或者集群
  3. 复制积压缓存区不足 - 增大复制缓存区配置rel_backlog_size ,网络增强

规避复制风暴

  1. 单机器复制风暴(redis<4.0当master宕机重启,会导致该机器下所有slave同时产生复制。避免单机部署一套redis主从)====》主节点分散多台机

最后的注意事项:

  • 在上述的过程的实现是从库不开启AOF持久化情况下,如果从库开启的AOF持久化,重启时候依然使用全量复制。
  • 之前从master复制过来的数据并不会丢失,只是不再同步之前master(如上图的6379节点)后续写入的数据
  • slaveof 可以用来改变其所属的master节点,即重新成为另一台master的slave,但是新的master首先就会把从节点的数据全部清除掉
  • 关于读写分离延时: 读写分离 ,master会一步将数据复制到slave,如果slave发生阻塞,则会延迟master数据的写命令,造成数据不一致的问题。-------一般不考虑这个问题
  • 读到过期数据:redis在删除key时有两种策略,一种是懒惰型策略,即只有当redis操作这个key时才会将key删除,第二种是定期采样key删除--------当key数据非常多时,采样速度比不上key生成速度会造成很多过期数据没有删除,因为redis一般都是在master节点(增加删除数据),slave查询到过期数据也不能删除。会导致slave读到过期数据(在redis3.2中已经解决)
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-11-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 服务端思维 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 主从复制的配置
  • 全量复制和部分复制等
    • 全量复制
      • 部分复制
        • 复制积压缓冲区:
        • 生产中常见问题
          • 最后的注意事项:
          相关产品与服务
          云数据库 Redis
          腾讯云数据库 Redis(TencentDB for Redis)是腾讯云打造的兼容 Redis 协议的缓存和存储服务。丰富的数据结构能帮助您完成不同类型的业务场景开发。支持主从热备,提供自动容灾切换、数据备份、故障迁移、实例监控、在线扩容、数据回档等全套的数据库服务。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档