第75篇 Redis主从库复制原理先容

媒介

当地缓存带来的挑战有哪些

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

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

• 如何打破redis缓存容量受限于机器单机内存巨细的问题？
  
• 如何使得redis可以或许扛住多方过来的哀求压力？
  
• 如何保证redis不会成为单点故障源？
  

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

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

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

1.1 主从复制是什么

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；
数据的复制是单向的，只能由主节点到从节点，而对于redis来说，一主两从是比较常见的搭配。
主从模式按照读写分离的策略来提拔团体的哀求处理能力：

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

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

1.2 主从复制的作用

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

2.主从复制流程

2.1 全量复制

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

第一阶段：创建链接、协商同步
从服务器向主服务器发送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。其在内存中是一个环形结构。

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

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

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

总结

• 主从服务器第一次同步的时间，就是采用全量复制。
  
• 第一次同步完成后，主从服务器都会维护着一个长毗连，主服务器在接收到写操作下令后，就会通过这个毗连将写下令流传给从服务器，来保证主从服务器的数据同等性。
  
• 如果碰到网络断开，就需要举行增量复制（当然不一定是增量复制，具体还需要看replication backlog的巨细，以及对应的主服务器RunID）。
  

出自：https://www.cnblogs.com/seven97-top/p/18580132

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。