redis：主从复制

   个人主页 ： 个人主页
个人专栏 ： 《数据布局》 《C语言》《C++》《Linux》《网络》 《redis学习条记》
  
  

---

媒介

分布式系统，涉及到一个关键的标题：单点标题。
假如某个服务器步伐，只有一个节点(只有一个物理服务器，来部署这个服务器步伐)；有两个标题：

• 可用性标题：假如这个机器挂了，意味着服务就停止了
  
• 性能/支持的并发量也是比较有限的
  

在分布式系统中为了解决单点标题，通常会把数据复制多个副本部署到其它服务器，满足故障恢复和负载均衡等需求。redis为我们提供了复制功能，实现了类似数据的多个redis副本，复制功能是高可用redis的基础。
在分布式系统中，利用多个服务器来部署redis，存在以下几种redis的部署方式：

• 主从模式
  
• 主从 + 哨兵模式
  
• 集群模式
  

---

主从模式

redis的主从模式中，存在多个redis服务器节点，它们被分别为主节点(master)和从节点(slave)；每个从节点只能有一个主节点，但一个主节点可以有多个从节点；从节点是主节点的副本，会同步主节点上的所有数据，同时，当主节点对数据有任何修改时，这些修改也会同步到从节点上；从节点不允许直接修改数据，所有写操作都必须通过主节点来完成
假设有三个物理服务器(三个节点)，分别部署一个redis-server进程；此时就可以把其中一个节点，作为主节点；别的两个节点作为从节点

现在，假如挂掉了某个从节点，没什么影响，此时继续从主节点或者其它从节点读取数据得到的效果完全类似；假如挂掉主节点，照旧有一定影响，不能写数据了。
所以主从模式，重要是针对 读操作 举行 并发量 和 可用性 的提高；而 写操作 无论可用性照旧并发量，都非常依靠主节点

---

复制拓扑布局

一主一从布局是最简朴的复制拓扑布局。

假如写数据请求太多了，此时也会给主节点造成一些压力；可以通过关闭主节点的AOF(关闭向硬盘写入)，只在从节点开启AOF；
但这种设定方式，有一个严重的缺陷，主节点一旦挂了，不能让它自己重启，假如自动重启，此时没有AOF文件，就会丢失数据，进一步的主从同步，会把从节点的数据也给删除了
改进办法，当主节点挂了之后，需要让主节点在从节点这里获取到AOF的文件，在启动

---

一主多从布局使得应用端可以利用多个从节点实现读写分离，对于读比重较大的场景，可以把读下令负载均衡到不同的从节点上来分担压力。同时一些耗时的读下令可以指定一台专门的从节点实行，避免破坏团体的稳定性

但从节点过多，也会导致主节点带宽压力过大；主节点实行的写入下令需要被复制到所有的从节点，从节点数量越多，主节点需要发送的写下令次数也越多

---

树形主从布局(分层布局)使得从节点不但可以复制主节点数据，同时可以作为其它从节点的主节点继续向下层复制，通过引入复制中间层，可以有用降低系统按负载和需要传送给从节点的数据量

但子节点层数过多会对网络延迟造成影响

• 网络传输延迟：当子节点层数过多时，数据需要经过更多的网络节点和链路
  
• 子节点处理惩罚延迟：每个子节点在接受数据时都需要举行处理惩罚；当子节点层数增多时，中间节点的处理惩罚延迟会累加，进一步增长团体延迟
  
• 同步服从降低：在树形布局中，假如某个中间节点出现故障或网络标题，可能会导致其下游的从节点无法及时同步数据
  

---

主从节点创建复制流程

• 从节点内部通过每秒运行的定时器任务维护复制相关逻辑，当定时器发现存在新的主节点后，会尝试与主节点创建基于TCP的网络连接；假如从节点无法创建连接，定时任务会无穷重试直到连接乐成或者用户停止主从复制
  
• 发送ping下令；连接创建乐成之后，从节点通过ping下令确认主节点在应用层上是工作良好的；假如ping下令的结果pong回复超时，从节点会断开TCP连接，期待定时任务下次重新创建连接
  
• 权限验证；假如主节点设置了requirepass参数，则需要密码验证，从节点通过配置masterauth参数来设置密码，假如验证失败，则从节点的复制将会停止
  
• 同步数据集，对于首次创建复制的场景，主节点会把当前持有的所有数据全部发送给从节点，
  
• 下令持续复制，当从节点复制了主节点的所有数据之后，针对之后的修改下令，主节点会持续的把下令发送给从节点，从节点指向修改下令，包管主从数据的一致性
  

---

数据同步 psync

redis利用 psync 下令完成主从数据同步，同步过程分为：全量复制 和 部分复制

• 全量复制：一样寻常用于初次复制场景，会把主节点全部数据一次性发送给从节点，当数据流较大时，会对主从节点和网络造成很大的开销
  
• 部分复制：用于处理惩罚在主从复制中由于网络闪断等原理造成的数据丢失场景，当从节点再次连上主节点后，假如条件允许，主节点会补发数据给从节点
  

   PSYNC replicationid offset
  psync不需要我们手动实行，redis服务器会在创建好主从同步关系之后，自动实行psync(从节点负责实行)

---

replication复制，是主节点天生的；主节点启动的时候就会天生，从节点提升成主节点的时候也会天生，但纵然是同一个主节点，每次重启，天生的replication id都是不同的。
从节点和主节点创建复制关系，就会从主节点这边获取replication id
通过info replication查察

每个节点都需要记载两组master_replid；
   当前有两个节点A 和 B，A为master，B为slave；此时 B 就会记载 A 的 master_replid；假如网络抖动，B 认为 A挂了，B自己就会称为主节点，于是 B 给自己分配了新的master_replid；此时就会利用master_replid2来保存之前A的master_replid
假如后续网络恢复了，B就可以根据master_replid2找回之前的主节点
假如后续网络没有恢复，B就按照新的master_replid自成一派，继续处理惩罚后续的数据
  

---

offset偏移量
主节点和从节点上都会维护 偏移量(整数)；

• 主节点的偏移量：主节点会收到许多的修改操作的下令，每个下令都要占据几个字节，主节点会把这些修改下令，每个下令的字节数举行累加
  
• 从节点的偏移量：现在从节点这里数据同步到哪里了
  

通过对比主从节点的偏移量，可以判断主从节点数据是否一致

---

replication id 和 offset 共同形貌了一个“数据集合”；replication id相当于原所在，offset相当于巨细
假如发现两个机器，replication id 和 offset都类似，就可以认为这两个redis机器上存储的数据就是完全一样的

---

psync运行流程

psync可以从主节点获取全量数据，也可以获取一部分数据；重要看offset的值，offset写作-1，就是获取全量数据；offset写详细的正整数，则是从当前偏移量位置来举行获取

• 从节点发送psync下令给主节点，replid 和 offset的默认值分别是？和-1
  
• 主节点根据psync参数和自身数据环境决定响应结果：+FULLRESYNC replid offset，则从节点需要举行全量复制流程；+CONTINEU，从节点举行部分复制流程；-ERR，redis主节点版本过低，不支持psync下令，从节点可以利用sync下令举行全量复制
  

什么时候举行全量复制：

• 首次和主节点举行数据同步
  
• 主节点不方便举行部分复制的时候
  

什么时候举行部分复制：

• 从节点之前已经从主节点复制过数据了，由于网络抖动或者从节点重启；从节点需要重新从主节点这边同步数据；此时看能不能只同步一小部分数据
  

---

psync一样寻常不需要手动实行，redis会在主从复制模式下自动调用实行

---

全量复制流程

全量复制是redis最早支持的复制方式，也是主从第一次创建复制时必须履历的阶段

• 从节点发送psync下令给主节点举行数据同步，由于是第一次举行复制，从节点没有主节点的复制ID(replid)和 复制偏移量(offset)，发送 psync ? -1
  
• 主节点根据下令，剖析出要举行全量复制，回复+FULLRESYNC响应
  
• 从节点接受到主节点的运行信息(包括复制ID和复制偏移量等)举行保存
  
• 主节点实行bgsave举行RDB文件长期化
  
• 主节点发送RDB文件给从节点，从节点保存RDB数据到当地硬盘
  
• 主节点将从天生RDB到接受完成期间实行的写下令，写入缓冲区中，等从节点保存完RDB文件后，主节点再将缓冲区内的数据补发给从节点，补发的数据仍然按照RDB的二进制格式追加写入到收到的RDB文件中，保持主从一致性
  
• 从节点清空自身原有旧数据
  
• 从节点加载RDB文件得到与主节点一致的数据
  
• 假如从节点加载RDB完成之后，并且开启了AOF长期化功能，会举行bgrewrite操作，得到最近的AOF文件
  

注意：
主节点实行 bgsave 天生RDB文件，不能利用已有的RDB文件，而是必须重新天生一个，已有RDB文件可能会和当前最新的数据存在较大差别；

---

主节点举行全量复制，也支持"无硬盘模式"(diskless)；
主节点天生的RDB的二进制数据，不保存到文件中，而是直接举行网络传输(避免一系列读硬盘和协硬盘的操作)；从节点直接把收到的数据举行加载，避免了将收到的RDB数据，写入硬盘，然后在加载；
但纵然引入了无硬盘模式，全量复制整个操作照旧比较耗时的；所以一样寻常应该尽可能避免对已经有大量数据集的redis举行全量复制

---

部分复制流程

从节点要从主节点这里举行全量复制，全量复制，开销很大；有些时候，从节点自己已经持有了主节点的绝大部分数据，这个时候，就不太需要举行全量复制；
部分复制重要是redis针对全量复制的过高开销做出的一种优化步伐，利用 psync replicationID offset 下令实现。当从节点正在复制主节点时，假如出现网络闪断或者下令丢失等异常环境时，从节点会向主节点要求补发丢失的下令数据，假如主节点的复制积存缓冲区存在数据则直接发送给从节点，这样就可以保存主从节点复制的一致性；补发的这部分数据一样寻常远远小于全量数据，所以开销很小

• 当主从节点之间出现网络停止时，假如超过repl-timeout时间，主节点会认为从节点故障并停止复制连接
  
• 主从连接停止期间，主节点依旧响应下令，但这些复制下令都因网络停止无法及时发送给从节点，所以暂时将这些下令滞留在复制积存缓冲区中
  
• 当主从节点网络恢复后，从节点再次连上主节点
  
• 从节点将之前保存的 复制ID(replicationId) 和 复制偏移量(offset) 作为psync的参数发送给主节点，请求举行部分复制
  
• 主节点接到 psync 请求后，举行必要的验证；随后根据 offset 去复制积存缓冲区查找符合的数据并响应+CONTINUE给从节点
  
• 主节点将需要从节点同步的数据发生给从节点，最终完成一致性
  

replicationId 实在就是在形貌“数据的来源”；offset 形貌“数据的复制进度”

---

复制积存缓冲区可以看成一个内存中的循环队列；会记载最近一段时间修改的数据，总量有限，随着时间的推移，就会把之前的旧的数据渐渐删除；
主节点就看offset是否在当前的复制积存缓冲区之内，假如确着实复制积存缓冲区之内，此时就可以直接举行部分复制；假如确实当前从节点的进度已经超出复制积存缓冲区的范围，只能举行全量复制。

---

及时复制

主从节点在创建复制连接后(此时从节点已经和主节点数据一致了)，主节点会把自己收到的修改操作，通过TCP长连接的方式，源源不停的传输给从节点。从节点就会根据这些请求来同时修改自身的数据，从而保持和主节点数据的一致性。
在举行及时复制的时候，需要包管连接处于可以状态；即通过心跳包的方式来维护连接状态(应用层自己实现的心跳)

• 主从节点彼此都有心跳检测机制，各自模拟成对方的客户端举行通信
  
• 主节点默认每隔10秒对从节点发送 ping 下令，判断从节点的存活和连接状态
  
• 从节点默认每隔1秒向主节点发送replconf ack offset 下令，给主节点上报自身当前的复制偏移量
  

假如主节点发现从节点通信延迟超过repl-timeout配置的值，则判断从节点下线，断开复制客户端连接。从节点恢复连接后，心跳机制继续举行

---

总结

以上就是我的redis学习条记

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