Redis总结集群方式之主从复制[通俗易懂]

2022-09-22 18:00:53 浏览数 (1)

大家好，又见面了，我是你们的朋友全栈君。

绪论

最近由于小编颈椎病犯了，所以最近停更了文章，今天下午刚收到几千里地老父亲寄来的艾灸贴，晚上贴上之后，伴随着火辣辣的感觉开始创作现在这篇文章；若大家get到了东西，请爱心三连。 废话不再多言，下面我们进入正题。

主从复制

同步策略

  • 全量同步 时机：slave初始化阶段； 机制：slave服务器需要将master服务器上的所有数据都复制一份。
  • 增量同步 时机：slave初始化之后且正常工作； 机制：master服务器每执行一次新的写操作命令同步到slave服务器上，从服务器接收并执行该写命令操作；

总结

  • 主、从服务器刚建立连接时，采用全量同步；
  • 全量同步结束且正常工作，则新的写命令采用增量同步；
  • 此外，从服务器（slave）可以任意时刻发起全量同步命令；
  • 总之，redis策略，正常工作之后先进行增量同步，如失败，则要求从服务器发起全量同步。

同步过程

全量复制

  1. 从服务器连接主服务器时，发送SYNC命令；
  2. 主服务器接收SYNC命令后，执行bgsave命令开始生成RDB文件，并将之后所有的写入命令存储到缓冲区；
  3. 主服务器bgsave命令执行结束后，向所有的从服务器发送RDB快照文件，发送期间所有的写入命令继续存储到缓冲区；
  4. 从服务器接收到快照文件之后，替换旧的快照文件，并载入数据；
  5. 主服务器传输结束快照文件后，将缓冲区中的所有写入命令发给从服务器；
  6. 从服务器载入快照文件结束后，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）；
  7. 主服务器每执行一个写命令，就会给从服务器发送相同的写命令，从服务器接收并执行写命令（从服务器初始化完成之后的操作：增量）；

部分复制

  • 工作原理： 主服务器端为复制流维护一个内存缓冲区（in-memory backlog）。主从服务器都维护一个复制偏移量（replication offset）和master run id ， 当连接断开时，从服务器会重新连接上主服务器，然后请求继续复制，假如主从服务器的两个master run id相同，并且指定的偏移量在内存缓冲 区中还有效，复制就会从上次中断的点开始继续。如果其中一个条件不满足，就会进行完全重新同步（在2.8版本之前就是直接进行完全重新同步）。 因为主运行id不保存在磁盘中，如果从服务器重启了的话就只能进行完全同步了。
  • 工作过程：
  1. 当主从节点之间网络出现中断时，如果超过了 repl-timeout 时间，主节点会认为从节点故障并中断复制连接。
  2. 主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内部存在复制积压缓冲区( repl-backlog-buffer )，依然可以保存最近一段时间的写命令数据，默认最大缓存 1MB。
  3. 当主从节点网络恢复后，从节点会再次连上主节点。
  4. 当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们作为 psync 参数发送给主节点，要求进行补发复制操作。
  5. 主节点接到 psync 命令后首先核对参数 runId 是否与自身一致，如果一致，说明之前复制的是当前主节点；之后根据参数 offset 在自身复制积压缓冲区查找，如果偏移量之后的数据存在缓冲区中，则对从节点发送 CONTINUE 响应，表示可以进行部分复制。
  6. 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

扩展点: 服务器运行ID(run_id)：每个Redis节点(无论主从)，在启动时都会自动生成一个随机ID(每次启动都不一样)，由40个随机的十六进制字符组成；run_id用来唯一识别一个Redis节点。 通过info server命令，可以查看节点的run_id。

总结

特点

a. 采用异步复制的方式； b. 一个master服务器可以存着多个slave服务器；每个slave服务器可以接受其他slave服务器的连接； c. 无论对于master、slave服务器都是非阻塞的，master服务器进行主从复制期间时，master服务器依然可以处理外部访问请求； 而slave服务器依然可以处理外部的查询请求，但是查询的结果为旧数据。

优点

a. 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离 b. 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成 c. Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。 d. Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。 e. Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。

缺点

a. Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。 c. 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。 d. Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/170311.html原文链接：https://javaforall.cn

云数据库Redis

0 人点赞