2024年安卓最全Redis分布式基石——主从复制技术详述，头条面试失败简历锁多久

总结

最后小编想说：不论以后选择什么方向发展，目前重要的是把Android方面的技术学好，毕竟其实对于程序员来说，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提升自己，从来都是我们去适应环境，而不是环境来适应我们！

这里附上我整理的几十套腾讯、字节跳动，京东，小米，头条、阿里、美团等公司19年的Android面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

技术进阶之路很漫长，一起共勉吧~

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

Redis的主从复制机制，并不是一开始就像6.x版本一样完善，而是一个版本一个版本迭代而来的。它大体上经过三个版本的迭代：

• 2.8以前

• 2.8~4.0

• 4.0以后

随着版本的增长，Redis主从复制机制逐渐完善；但是他们的本质都是围绕同步（sync）和命令传播（command propagate）两个操作展开：

• 同步（sync）：指的是将从服务器的数据状态更新至主服务器当前的数据状态，主要发生在初始化或后续的全量同步。

• 命令传播（command propagate）：当主服务器的数据状态被修改（写/删除等），主从之间的数据状态不一致时，主服务将发生数据改变的命令传播给从服务器，让主从服务器之间的状态重回一致。

2.1 版本2.8以前

---

2.1.1 同步

2.8以前的版本，从服务器对主服务器的同步需要从服务器向主服务器发生sync命令来完成：

1. 从服务器接收到客户端发送的slaveof ip prot命令，从服务器根据ip:port向主服务器创建套接字连接

2. 套接字成功连接到主服务器后，从服务器会为这个套接字连接关联一个专门用于处理复制工作的文件事件处理器，处理后续的主服务器发送的RDB文件和传播的命令

3. 开始进行复制，从服务器向主服务器发送sync命令

4. 主服务器接收到sync命令后，执行bgsave命令，主服务器主进程fork的子进程会生成一个RDB文件，同时将RDB快照产生后的所有写操作记录在缓冲区中

5. bgsave命令执行完成后，主服务器将生成的RDB文件发送给从服务器，从服务器接收到RDB文件后，首先会清除本身的全部数据，然后载入RDB文件，将自己的数据状态更新成主服务器的RDB文件的数据状态

6. 主服务器将缓冲区的写命令发送给从服务器，从服务器接收命令，并执行。

7. 主从复制同步步骤完成

2.1.2 命令传播

当同步工作完成之后，主从之间需要通过命令传播来维持数据状态的一致性。

如下图，当前主从服务器之间完成同步工作之后，主服务接收客户端的DEL K6指令后删除了K6，此时从服务器仍然存在K6，主从数据状态并不一致。为了维持主从服务器状态一致，主服务器会将导致自己数据状态发生改变的命令传播到从服务器执行，当从服务器也执行了相同的命令之后，主从服务器之间的数据状态将会保持一致。

2.1.3 缺陷

从上面看不出2.8以前版本的主从复制有什么缺陷，这是因为我们还没有考虑网络波动的情况。了解分布式的兄弟们肯定听说过CAP理论，CAP理论是分布式存储系统的基石，在CAP理论中P(partition网络分区)必然存在，Redis主从复制也不例外。当主从服务器之间出现网络故障，导致一段时间内从服务器与主服务器之间无法通信，当从服务器重新连接上主服务器时，如果主服务器在这段时间内数据状态发生了改变，那么主从服务器之间将出现数据状态不一致。

在Redis 2.8以前的主从复制版本中，解决这种数据状态不一致的方式是通过重新发送sync命令来实现。虽然sync能保证主从服务器数据状态一致，但是很明显sync是一个非常消耗资源的操作。

​

sync命令执行，主从服务器需要占用的资源：

• 主服务器执行BGSAVE生成RDB文件，会占用大量CPU、磁盘I/O和内存资源

• 主服务器将生成的RDB文件发送给从服务器，会占用大量网络带宽，

• 从服务器接收RDB文件并载入，会导致从服务器阻塞，无法提供服务

从上面三点可以看出，sync命令不仅会导致主服务器的响应能力下降，也会导致从服务器在此期间拒绝对外提供服务。

2.2 版本2.8-4.0

---

2.2.1 改进点

针对2.8以前的版本，Redis在2.8之后对从服务器重连后的数据状态同步进行了改进。改进的方向是减少全量同步（full resynchronizaztion）的发生，尽可能使用增量同步（partial resynchronization）。在2.8版本之后使用psync命令代替了sync命令来执行同步操作，psync命令同时具备全量同步和增量同步的功能：

• 全量同步与上一版本（sync）一致

• 增量同步中对于断线重连后的复制，会根据情况采取不同措施；如果条件允许，仍然只发送从服务缺失的部分数据。

2.2.2 psync如何实现

Redis为了实现从服务器断线重连后的增量同步，增加了三个辅助参数：

• 复制偏移量（replication offset）

• 积压缓冲区（replication backlog）

• 服务器运行id（run id）

2.2.2.1 复制偏移量

在主服务器和从服务器内都会维护一个复制偏移量

• 主服务器向从服务发送数据，传播N个字节的数据，主服务的复制偏移量增加N

• 从服务器接收主服务器发送的数据，接收N个字节的数据，从服务器的复制偏移量增加N

正常同步的情况如下：

通过对比主从服务器之间的复制偏移量是否相等，能够得知主从服务器之间的数据状态是否保持一致。

假设此时A/B正常传播，C从服务器断线，那么将出现如下情况：

很明显有了复制偏移量之后，从服务器C断线重连后，主服务器只需要发送从服务器缺少的100字节数据即可。但是主服务器又是如何知道从服务器缺少的是那些数据呢？

​

2.2.2.2 复制积压缓冲区

复制积压缓冲区是一个固定长度的队列，默认为1MB大小。当主服务器数据状态发生改变，主服务器将数据同步给从服务器的同时会另存一份到复制积压缓冲区中。

复制积压缓冲区为了能和偏移量进行匹配，它不仅存储了数据内容，还记录了每个字节对应的偏移量：

当从服务器断线重连后，从服务器通过psync命令将自己的复制偏移量（offset）发送给主服务器，主服务器便可通过这个偏移量来判断进行增量传播还是全量同步。

• 如果偏移量offset+1的数据仍然在复制积压缓冲区中，那么进行增量同步操作

• 反之进行全量同步操作，与sync一致

Redis的复制积压缓冲区的大小默认为1MB，如果需要自定义应该如何设置呢？

很明显，我们希望能尽可能的使用增量同步，但是又不希望缓冲区占用过多的内存空间。那么我们可以通过预估Redis从服务断线后重连的时间T，Redis主服务器每秒接收的写命令的内存大小M，来设置复制积压缓冲区的大小S。

S = 2 * M * T

注意这里扩大2倍是为了留有一定的余地，保证绝大部分的断线重连都能采用增量同步。

​

2.2.2.3 服务器运行 ID

看到这里是不是再想上面已经可以实现断线重连的增量同步了，还要运行ID干嘛？其实还有一种情况没考虑，就是当主服务器宕机后，某台从服务器被选举成为新的主服务器，这种情况我们就通过比较运行ID来区分。

• 运行ID（run id）是服务器启动时自动生成的40个随机的十六进制字符串，主服务和从服务器均会生成运行ID

• 当从服务器首次同步主服务器的数据时，主服务器会发送自己的运行ID给从服务器，从服务器会保存在RDB文件中

• 当从服务器断线重连后，从服务器会向主服务器发送之前保存的主服务器运行ID，如果服务器运行ID匹配，则证明主服务器未发生更改，可以尝试进行增量同步

• 如果服务器运行ID不匹配，则进行全量同步

2.2.3 完整的psync

完整的psync过程非常的复杂，在2.8-4.0的主从复制版本中已经做到了非常完善。psync命令发送的参数如下：

psync 

文末

好了，今天的分享就到这里，如果你对在面试中遇到的问题，或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己，对于自己的未来还不够了解不知道给如何规划，可以来看看同行们都是如何突破现状，怎么学习的，来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。

这里放上一部分我工作以来以及参与过的大大小小的面试收集总结出来的相关的几十套腾讯、头条、阿里、美团等公司21年的面试专题，其中把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分免费分享给大家，主要还是希望大家在如今大环境不好的情况下面试能够顺利一点，希望可以帮助到大家~

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

【延伸Android必备知识点】

这里只是整理出来的部分面试题，后续会持续更新，希望通过这些高级面试题能够降低面试Android岗位的门槛，让更多的Android工程师理解Android系统，掌握Android系统。喜欢的话麻烦点击一个喜欢在关注一下~

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

让更多的Android工程师理解Android系统，掌握Android系统。喜欢的话麻烦点击一个喜欢在关注一下~

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！