关于redis:Redis主从复制与优化

38次阅读

共计 2775 个字符,预计需要花费 7 分钟才能阅读完成。

简介: Redis 主从复制与优化

Redis 主从复制与优化

主从复制

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

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

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

应用主从复制能够:

  • 数据正本
  • 扩大读性能

留神:

  • 一个 master 能够有多个 slave
  • 一个 slave 只有一个 master
  • 数据流向是单向的,master 到 slave
    • *

主从复制的配置

两种实现形式

  • slaveof 命令

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

在从节点执行 slaveof 命令

47.22.22.22-6379 > slacefof 47.11.11.11 6379
OK

勾销复制:

47.22.22.22-6379 > slacefof no one
OK
  • 批改配置
slaveof ip  port    // 从节点 ip + 端口
slave-read-only yes // 开启只做读的操作 
  • 两种形式比拟

  • 查看主从
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 中曾经解决)
  • 举荐 redis 主从文章 https://www.cnblogs.com/wdliu/p/9407179.html
  • 举荐 redis 全量复制与局部复制文章 https://blog.csdn.net/gaobinzhan/article/details/106536326

集体博客:[http://blog.yanxiaolong.cn/ 集体博客:http://blog.yanxiaolong.cn/
)

正文完
 0