网站建设比较好公司,网页设计与网站建设项目教程,微信安全中心官网,公司网站建立教程Redis 的主从复制经历了多次演进#xff0c;本文将从最基本的原理和实现讲起#xff0c;并层层递进#xff0c;逐步呈现 Redis 主从复制的演进历史。大家将了解到 Redis 主从复制的原理#xff0c;以及各个改进版本解决了什么问题#xff0c;并最终看清 Redis 7.0 主从复制…Redis 的主从复制经历了多次演进本文将从最基本的原理和实现讲起并层层递进逐步呈现 Redis 主从复制的演进历史。大家将了解到 Redis 主从复制的原理以及各个改进版本解决了什么问题并最终看清 Redis 7.0 主从复制原理的全貌。
什么是主从复制
在数据库语境下复制replication就是将数据从一个数据库复制到另一个数据库中。主从复制是将数据库分为主节点和从节点主节点源源不断地将数据复制给从节点保证主从节点中存有相同的数据。
有了主从复制数据可以有多份副本这带来了多种好处
第一提升数据库系统的请求处理能力。单个节点能够支撑的读流量有限部署多个节点并构成主从关系用主从复制保持主从节点数据一致如此主从节点可以一起提供服务。
第二提升整个系统的可用性。因为从节点中有主节点数据的副本当主节点宕机后可以立刻提升其中一个从节点为主节点继续提供服务。 Redis 主从复制原理
实现主从复制直观的思路是产生一份主节点数据的快照发送给从节点并以此做为基准随后将快照时刻之后的增量数据发送给从节点如此就能保证主从数据的一致。总体来看主从复制一般包含全量数据同步、增量同步两个阶段。
在 Redis 的主从复制实现中包含两个类似阶段全量数据同步和命令传播。
全量数据同步主节点产生一份全量数据的快照即 RDB 文件并将此快照发送给从节点。且从产生快照时刻起记录新接收到的写命令。当快照发送完成后将累积的写命令发送给从节点从节点执行这些写命令。此时基准已经建立完成主从节点间数据已经大体一致。命令传播全量数据同步完成后主节点将执行过的写命令源源不断地发送给从节点从节点执行这些命令保证主从节点中数据有相同的变更如此保证主从数据持续一致。
下图中给出了 Redis 主从复制的整个过程 主从关系建立后从节点向主节点发送一个 SYNC 命令请求进行主从同步。主节点收到 SYNC 命令后执行 fork 创建一个子进程子进程中将所有的数据按特定编码存储到 RDBRedis Database 文件中这就产生了数据库的快照。主节点将此快照发送给从节点从节点接收并载入快照。主节点接着将生成快照、发送快照期间积压的写命令发送给从节点从节点接收这些命令并执行命令执行后从节点中的数据也就有了同样的变更。此后主节点源源不断地新执行的写命令同步到从节点从节点执行传播来的命令。如此主从数据保持一致。需要说明的是命令传播存在时延的所以任意时刻不能保证主从节点间数据完全一致。
以上就是 Redis 主从复制的基本原理很简单很容易理解Redis 最初就采用这种方案但这种方案存在一些问题
fork 耗时过长阻塞主进程
执行fork 时需要拷贝大量的内存页表这是一个耗时较多的操作尤其当内存使用量较大的时候。组内同学曾做过测试内存占用 10GB 时fork 需要消耗 100 多毫秒。fork 的时候主进程阻塞 100 多毫秒这对 Redis 而言实在太长了。另外fork 之后如果主库中有不少的写入那么由于写时复制机制会额外消耗不少的内存还会增大响应时间。
主从间网络闪断会触发全量同步
假如主从之间的网络出现了故障连接意外断开主节点无法继续传播命令至该从节点。之后网络恢复从节点重新连接上主节点后主节点不能再继续传播新接收到的命令了因为从节点已经漏掉了一些命令。此时从节点需要从头再来再次执行全部的同步过程而这要付出很高的代价。
网络闪断是常发生的事情闪断期间主节点中可能只写入了比较少的数据但就因为这很少的一部分数据需要让从节点进行一次代价高昂的全量同步。这种做法是非常低效的该如何解决这问题呢下一节 Redis 部分重同步给你答案。
Redis 部分重同步
网络短暂断开后从节点需要重新同步这很浪费资源很不环保。从节点为什么需要重新同步呢因为主从断开期间有部分命令没有同步到从节点上去。如果忽略这些命令继续传播后续的命令则会导致数据的错乱因为丢失掉的命令是不能忽略的。为什么不将那些命令保存下来呢这样当从节点重新连接后就可以将断连期间的命令补充给它了这样就不需要重新全量同步了。
Redis 2.8 版本后引入了部分同步。它在主节点中维护了一个复制积压缓冲区命令一方面会传播到从节点另外还会记录在这个缓冲区中。保存所有的命令是不必要的Redis 中使用了一个环形的缓冲区这样就可以只保留最近的一些命令了。 命令是保存下来了但从节点重新连接后主节点该从什么地方开始给从节点发送命令呢如果能给所有命令编一个号则从节点只需要告诉主节点自己最后收到的命令的编号主节点就知道该从什么位置发送命令了。Redis 的实现中是对字节进行编号这个编号在 Redis 的语境中叫做复制偏移量。
有了部分同步后主从复制的流程变成了下面这样 主从复制的时候不再使用SYNC命令而是使用PSYNC意思的Partial SYNC部分同步。PSYNC的语法如下 PSYNC master id replication offset命令中的两个参数一个是主节点的编号一个是复制偏移量。每个Redis节点都有一个 40 字节的编号PSYNC 命令中携带的编号是期望进行同步的主节点的编号。复制偏移量则表示当前从节点想要从什么地方开始部分同步。
如果是第一次进行主从复制自然是不知道主节点的编号复制偏移量也无意义此时使用 PSYNC ? -1 来进行全量同步。另外如果从节点指定的复制偏移量不在主节点的复制积压缓冲区的范围内部分同步会失败会转向全量同步。
有了部分同步网络闪断后就可以避免全量同步了。但是因为主节点只能保留最近的部分命令保存多少取决于复制积压缓冲区的大小。如果从节点断开时间过长或者断开期间主节点新执行的写命令足够多漏掉的命令就无法全部保存到复制积压缓冲区中了。加大复制积压缓冲区可以尽可能多地避免全量同步但这同时会造成额外的内存消耗。
部分同步消耗了部分内存来保存最近执行的写命令避免闪断后的全同步这是很直观、很容易想象的解决方案。这种方案很好是否还存在其他问题呢考虑以下问题
假如从节点重启了怎么办
部分同步依赖主节点的编号和复制偏移量从节点在初次同步的时候会获取到主节点的编号并在之后的同步中不断调整复制偏移量这些信息都存储在内存中。当从节点意外重启后尽管本地存有 RDB 或 AOF 文件还是需要进行一次全量同步。但实际上完全可以载入本地数据并执行部分同步即可。
假如主从切换了怎么办
假如主节点意外宕机外围监控组件执行了主从切换。此时其他从节点对应的主节点就变化了从节点中记录的主节点编号就匹配不上新的主节点了此时会进行一次全量同步。但实际上所有的从节点在主从切换之前同步进度应该是差不多的而且新提升的从节点包含的数据应该最全切主后所有从节点都执行一次全量同步这实在不合理。 以上问题如何解决请继续往后看。
同源增量同步
从节点重启后丢失了原主节点编号和复制偏移量这导致重启后需要全量同步这很好办把这些信息存下来就可以了。
主从切换后主节点信息变化了导致从节点需要全量同步这也容易解决只需能确认新主节点上的数据是从原主节点复制来的那就可以继续从新的主节点上进行复制。
Redis 4.0 以后对 PSYNC 进行了改进提出了同源增量复制的解决方案该方案解决了前面提到的两个问题。
从节点重启后需要跟主节点全量同步这本质上是因为从节点丢失了主节点的编号信息在 Redis 4.0 后主节点的编号信息被写入到 RDB 中持久化保存。
切主后从节点需要和新主节点全量同步本质原因是新的主节点不认原主节点的编号。从节点发送 PSYNC 原主节点编号 复制偏移量 给新的主节点如果新的主节点能够认识 原主节点编号并明白自己的数据就是从该节点复制来的。那么新的主节点就应该清楚它和该从节点师出同门应该接受部分同步。如何才能识别呢只需要让从节点在切换为主节点时将自己之前的主节点的编号记录下来即可。
Redis 4.0 以后主从切换后新的主节点会将先前的主节点记录下来观察 info replication 的结果可以可以看到 master_replid 和 master_replid2 两个编号前者是当前主节点的编号后者为先前主节点的编号 127.0.0.1:6379 slaveof no one
OK
127.0.0.1:6379 info replication
#Replication
role:master
...
master_replid:b34aff08d983991b3feb4567a2ac0308984a892a
master_replid2:a3f2428d31e096a99d87affa6cc787cceb6128a2
master_repl_offset:38599
second_repl_offset:38600
...
repl_backlog_histlen:5180Redis 中目前值保留了两个主节点编号但完全可以实现一个链表将过往的主节点的编号信息都记录下来这样就可以追溯的更远了。这样以来如果一个从节点断开后执行了多次主从切换该从节重新连接后依然可以识别出它们的数据是同源的。但 Redis 没有这么做这是因为没有必要因为就算数据是同源的但复制积压缓冲区中保存的数据是有限的多次主从切换后复制积压缓冲区中保存的命令已经无法满足部分同步了。
有了同源增量复制后主节点切换后其他从节点可以基于新的主节点继续增量同步。
此时主从复制看起来已经不存在太大的问题了。但做 Redis 的那帮家伙总挖空心思想着能不能再做些优化。下面我将描述 Redis 主从复制的一些优化策略。
无盘全量同步和无盘加载
Redis 执行全量复制需要生成当前数据库的一份快照具体做法是执行 fork 创建子进程子进程遍历所有数据并编码后写入 RDB 文件中。RDB 生成后在主进程中会读取此文件并发送给从节点。
读写磁盘上的 RDB 文件是比较耗资源的在主进程中执行势必会导致 Redis 的响应时间变长。因此一个优化方案是 dump 后直接将数据直接发送数据给从节点不需要将数据先写入到 RDB 。Redis 6.0 中实现了这种无盘全量同步和无盘加载的策略。
采用无盘全量同步避免了对磁盘的操作但也有缺点。一般情况下在子进程中直接使用网络发送数据这比在子进程中生成 RDB 要慢这意味着子进程需要存活的时间相对较长。子进程存在的时间越长写时复制造成的影响就越大进而导致消耗的内存会更多。
在全量复制时候从节点一般是先接收 RDB 将其存在本地接收完成后再载入 RDB。同样地从节点也可以直接载入主节点发来的数据避免将其存入本地的 RDB 文件中而后再从磁盘加载。
共享主从复制缓冲区
在主节点的视角中从节点就是一个客户端从节点发送了 PSYNC 命令后主节点就要与它们完成全量同步并不断地把写命令同步给从节点。Redis 的每个客户端连接上存在一个发送缓冲区。
主节点执行了写命令后就会将命令内容写入到各个连接的发送缓冲区中。发送缓冲区存储的是待传播的命令这意味着多个发送缓冲区中的内容其实是相同的。而且这些命令还在复制积压缓冲区中存了一份呢。这就造成了大量的内存浪费尤其是存在很多从节点的时候。 在 Redis 7.0 中我们团队的同学提出并实现了共享主从复制缓冲区的方案解决了这个问题。该方案让发送缓冲区与复制积压缓冲区共享避免了数据的重复可有效节省内存。
总结
本文回顾并总结了 Redis 主从复制的演化过程并解释了各次演化所解决的问题。最后描述了对 Redis 主从复制进行优化的一些策略。
下面是对全文的总结
宏观来看 Redis 的主从复制分为全量同步和命令传播两个阶段。主节点先发送快照给从节点然后源源不断地将命令传播给从节点以此保证主从数据的一致。Redis 2.8 之前的主从复制存在闪断后需要重新全量同步的问题Redis 2.8 引入了复制积压缓冲区解决了这一问题。在 Redis 4.0 中同源增量复制的策略被提出解决了主从切换后从节点需要全量同步的问题。至此Redis 的主从复制整体上已经比较完善了。Redis 6.0 中为进一步优化主从复制的性能无盘同步和加载被提出避免全量同步时读写磁盘提高主从同步的速度。在 Redis 7.0 rc1 中采用了共享主从复制缓冲区的策略降低了主从复制带来的内存开销。
希望本文能帮助大家回顾 Redis 主从复制的原理并对其建立更加深刻的印象。
