本地缓存带来的挑战

分布式缓存相比于本地缓存，在实现层面需要关注的点有哪些不同。梳理如下：

从上述几个维度的对比可以发现，同样是缓存，但 集中式缓存 所承担的使命是完全不一样的，业务对集中式缓存的 存储容量 、 可靠性 、 承压性 等方面的诉求也是天壤之别，不可等同视之。以 Redis 为例：

• 如何打破redis缓存容量受限于机器单机内存大小的问题？
• 如何使得redis能够扛住多方过来的请求压力？
• 如何保证redis不会成为单点故障源？

其实答案很简单，加机器！通过多台机器的叠加使用，达到比单机更优的效果 —— 现在业务系统的集群化部署，也都是采用的这个思路。Redis的分布式之路亦是如此，但相比于常规的业务系统分布式集群化构建更加复杂：

1. 很多业务实现集群化部署会很简单，因为每个业务进程节点都是 无状态 的，只需要部署下然后通过负载均衡的方式对外提供请求应答即可。
2. Redis作为一个集中式缓存数据库，它是 有状态 的，不仅需要将进程分别部署在多个节点上，还需要将数据也分散存储在各个节点上，同时还得保证整个Redis集群对外是一个统一整体。

所以对于一个集中式缓存的分布式能力构建，必须要额外提供一些机制，来保障数据在各个节点上的安全与 一致性 ，还需要将分散在各个节点上的数据都组成一个逻辑上的整体。

主从复制简介

主从复制是什么

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点，而对于redis来说， 一主两从 是比较常见的搭配。

主从模式按照读写分离的策略来提升整体的请求处理能力：

1. 主节点(Master)同时对外提供 读和写 操作
2. 从节点(Slave)通过 replicate 同步的方式，从主节点复制数据，保持自身数据与主节点一致
3. 从节点只能对外提供 读操作

当然，对于读多写少类的操作，为了提升整体读请求的处理能力，可以采用 一主多从 的方式。所有的从节点都从主节点进行数据同步，这样会导致主节点的同步处理压力过大而成为瓶颈。为了解决这个问题，redis还支持了从slave节点分发的能力，也就是从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个主从链。这样可以分摊主服务器压力。

主从复制的作用

• 数据备份：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。
• 读写分离：由主节点提供写服务，由从节点提供读服务，提高Redis服务器的并发量。

主从复制流程

全量复制

在第一次同步时会进行全量复制（但并非只有第一次同步时全量复制，其他情况看后文）

第一次同步时流程：

第一阶段：建立链接、协商同步

从服务器向主服务器发送PSYNC ? -1 命令，主动请求进行完整重同步

psync 命令包含两个参数，分别是主服务器的 runID 和复制进度 offset。

• runID，每个 Redis 服务器在启动时都会自动生产一个随机的 ID 来唯一标识自己。当从服务器和主服务器第一次同步时，因为不知道主服务器的 run ID，所以将其设置为 "?"。
• offset，表示复制的进度，（也叫复制偏移量），主要为增量复制服务，这里因为是全量复制，所以使用-1表示。

主服务器收到 psync 命令后，会向从服务器发送FULLRESYNC响应命令并带上两个参数：主服务器的 runID 和主服务器目前的复制进度 offset。从服务器收到响应后，会记录这两个值。

FULLRESYNC 响应命令的意图是采用全量复制的方式，也就是主服务器会把所有的数据都同步给从服务器。

第二阶段：主服务器同步数据给从服务器

接着，主服务器会执行 bgsave 命令来生成 RDB 文件，然后把文件发送给从服务器（数据持久化）。

从服务器收到 RDB 文件后， 会先清空当前的数据，然后载入 RDB 文件 。这是因为从服务器在通过 replicaof 命令开始和主服务器同步前，可能保存了其他数据。为了避免之前数据的影响，从服务器需要先把当前数据库清空。

这里有一点要注意，主服务器生成 RDB 这个过程是不会阻塞主线程的，因为 bgsave 命令是产生了一个子进程来做生成 RDB 文件的工作，是异步工作的，这样 Redis 依然可以正常处理命令。

就像RDB文件生成过程中Redis不停止提供服务一样，从服务器在接收并载入RDB文件的过程中，主服务器仍然可以写入数据，那怎么将这部分数据传给从服务器呢？

第三阶段：主服务器发送新写操作命令给从服务器

为了保证主从服务器的数据一致性，主服务器为每个连接进来的从服务器准备了一个replication buffer缓冲区，这段时间内写入的数据都会被存入这个replication buffer中，从服务器完成 RDB 的载入后，会回复一个确认消息给主服务器。主服务器就将replication buffer中的数据推送过去。

长连接传播

主从服务器在完成第一次同步后，双方之间就会维护一个 TCP 连接，这个TCP连接是长连接

之后就会基于这个 长连接 进行命令传播。通过这种方式来保证第一次同步后的主从服务器的数据一致性。

增量复制

实际上，生成RDB文件是比较耗费资源的，同时，主服务器传输 RDB 文件给从服务器，这个操作会耗费主从服务器大量的网络资源，并对主服务器响应时延产生影响。而对从服务器而言，载入 RDB 文件期间，会阻塞其他命令请求，这也会导致响应效率的降低。并且，当从服务器断开后重新连接，主从数据不一致，在数据少量不一致的情况下，也不需要全量复制。因此，就提供了增量复制

复制偏移量（replication offset）

主服务器和从服务器会分别维护一个复制偏移量。如果主从服务器的复制偏移量相同，则说明二者的数据库状态一致；反之，则说明二者的数据库状态不一致，此时从服务器需要使用增量复制来同步缺失的这一部分数据。

复制积压缓冲区（replication backlog）

主服务器的写命令，除了传给从服务器后，还会写入replication backlog（全局唯一），这是一个固定长度的先进先出（FIFO）队列，默认大小为 1MB。其在内存中是一个环形结构。

1. 主服务器按照顺时针方向写命令，主服务器最新写入的位置即为上文提到的主服务器的偏移量，这里叫master offset。
2. 假设从服务器在set key2 2后断开连接，也就是上图中slave offset的位置，当它重连时，再次给主服务器发送psync指令时，会带上自己的offset（注意和全量复制的区别，全量复制时offset设置为-1，此时是从服务器真实的offset值）。
3. 接着，主服务器发现从服务器的偏移量与自己不一致，需要进行增量复制。此时主服务器会计算出master offset与slave offset之间的指令，并发送给该为从服务器准备的replication buffer中，进而发送给从服务器。
4. 从服务器进行写入后便又恢复到和主服务器一致的状态。

断开重连并不一定总是增量复制

网络断开后，当从服务器重新连上主服务器时，从服务器会通过 psync 命令将自己的复制偏移量 slave_repl_offset 发送给主服务器，主服务器根据自己的 master_repl_offset 和 slave_repl_offset 之间的差距，然后来决定对从服务器执行哪种同步操作：

1. 整个replication backlog是个环形结构，也就是说最新的写命令会将最老的写命令覆盖。换句话说，如果从服务器断开时间太久，环形缓冲区被主服务器的写命令覆盖了，那么从服务器连上主服务器后只能通过 全量复制 来获取数据了。所以replication backlog配置要尽量大一些，可以降低主从断开后全量复制的概率。
   • 如果判断出从服务器要读取的数据还在 repl_backlog_buffer 缓冲区里，那么主服务器将采用增量同步的方式；
   • 相反，如果判断出从服务器要读取的数据已经不存在 repl_backlog_buffer 缓冲区里，那么主服务器将采用全量同步的方式。
2. 上文中有提到每个实例有自己的RunID，这个值在服务器启动时自动生成，由 40 个随机的十六进制字符组成。从服务器断开重连时会将之前主服务器的RunID一起发送过去（这里注意和第一次连接的区别，第一次连接时发送的RunID是“？”），主服务器会判断这个RunID是否为自己，如果不是（比如出现脑裂，出现两个主服务器），则会和全量复制时一样返回FULLRESYNC响应命令，告知从服务器需要进行全量复制。

总结

主从服务器第一次同步的时候，就是采用全量复制。

第一次同步完成后，主从服务器都会维护着一个长连接，主服务器在接收到写操作命令后，就会通过这个连接将写命令传播给从服务器，来保证主从服务器的数据一致性。

如果遇到网络断开，就需要进行增量复制（当然不一定是增量复制，具体还需要看replication backlog的大小，以及对应的主服务器RunID）。

面试题专栏

Java面试题专栏 已上线，欢迎访问。

• 如果你不知道简历怎么写，简历项目不知道怎么包装；
• 如果简历中有些内容你不知道该不该写上去；
• 如果有些综合性问题你不知道怎么答；

那么可以私信我，我会尽我所能帮助你。