5 个维度深度剖析「主从架构」原理

若有收获,请记得分享和转发哦

前言

玩过王者荣耀的同学，应该都知道里面有个英雄叫做镜，她释放技能时，会出现一个长相一模一样的分身，而且动作也是一样的。

那么我们今天要讨论的主从架构原理其实就是多个节点中有一个作为本体，其他节点作为分身存在，但是本体和分身的数据都是一样的，数据总是保持一致，是不是和镜很相似呢？

为了保证缓存的高可用，我们经常听到采用主从架构来保证高可用，那如何去理解主从架构核心原理呢？

这次我们还是用最熟悉的 Redis 缓存来理解主从架构，只要理解了一个主从架构，其他技术的主从架构都是一通百通。

Redis 的主从架构，其实就是利用多副本，将一份数据同时保存在多个实例上。单个实例出现故障后，一般都会过一段时间才能恢复，那么其他节点还是可以提供服务的。

本篇我会带着大家一起探讨缓存的主从架构几个问题：

• Why：为什么需要主从架构？

• What：主从架构原理？

• Who：谁需要关心主从架构？

• When：什么时候用主从架构？

• Question：主从架构会带来哪些问题？

一主多从结构：一个主节点，多个从节点，对于读命令较大的场景，可以把读命令分摊到多个从节点。

而对于一主多从结构，还可以再扩展一点：当日常开发中需要执行一些比较耗时的读命令时，比如 keys、sort等，可以用其中一个从节点专门作为耗时查询用的从节点，避免慢查询对主节点造成阻塞，而影响服务的稳定性。我们也可以用图来进行说明：

• 命令传播：将写命令持续发送给所有从服务器，保持主从数据一致。这个就可以理解为持续复制了。

• 复制积压缓冲区：其实就是一个有界队列，保存着最近传播的写命令，而队列里面的每个字节都有一个偏移量标识。复制积压缓冲区的作用和原理在部分复制的时候再细讲。

全量复制

用于主从节点第一次复制的场景。这在我们的软件开发中也很常见，比如你要把第三方的用户数据同步到自己的系统中，一开始肯定是把存量用户一次性给复制过来，后续有新增或更新的用户就采用增量更新就可以了。

全量复制总共可以分为 9 步：

（1）从节点发送 psync 命令进行数据同步，会发送 psync 命令，来告诉主节点我想干啥。

psync 命令格式如下：

psync {runId} {offset}

runId 是 每个 Redis 实例启动时随机生成的一个 ID，用来唯一标记这台 Redis 实例。由于第一次复制时，刚启动时会随机生成 runId，只有自己知道，外人是不知道的，所以从节点是不知道主节点的 runId 的，这个时候发送 psync 命令时 runId 就是一个问号。第一次复制时，offset 默认为 -1。

总结

本篇从宏观和微观上讲解了主从架构的原理：

微观视角：涉及了主从架构的三种拓扑结构来应对不同的场景，然后深入讲解了持续复制、全量复制、部分复制的区别。以及大家特别关心的复制积压缓冲区，客户端缓冲区的使用场景，以及会遇到的坑。

宏观视角：讲解了主从架构谁需要来关心、什么时候用、以及主从架构会带来的问题。