redis-主从复制

什么是主从复制

🚀主从复制是一种分布式系统的结构，与传统的单点系统相比，分布式系统的健壮性更好，当某一个节点挂了，其他的节点还能继续工作。并且，服务器如果只有一个节点的情况下，能够承受的并发量也是有限的。

🚀主从复制是redis部署的一种常见方式，这种部署方式中，redis会有一个主节点和若干个从节点。其中客户端传来的修改数据的请求，只有主节点能够处理，也就是说从节点只能帮助主节点分担读请求的压力。

配置主从复制结构

🚀配置主从复制结构有三种方式：
1.在redis.conf中加上 slaveof 选项： slaveof masterIP masterPort
2.启动redis-server的时候加上 slaveof选项： slaveof masterIP masterPort
3.在redis客户端中执行 slaveof masterIP masterPort 命令也可以配置
🚀通过配置文件的方式，搭建redis主从复制结构(在一台服务器上演示)

• 首先，配置从节点的工作目录（避免从节点和主节点使用同一个aof文件），配置从节点的配置文件
  
  

• 配置从节点的slaveof选项，改变从节点绑定的端口（由于是在一台服务器上）
  
  

🚀启动从节点

可以看到从节点已经启动了起来，并且每个从节点还和主节点之间建立了tcp连接，这是因为主节点和从节点之间的数据传输是通过网络进行的。

验证主节点会将修改的数据同步到从节点

🚀在主节点插入一条数据

🚀在从节点中查看在主节点中插入的数据

info replication命令

🚀在主节点执行此命令：

1.可以直接看到角色为主节点，并且其有两个子节点。
2.slave选项记录了从节点的信息，如ip/port/是否在线等，offset表示主从节点之间同步的进度，lag表示延迟。
3.replid是一个用于标识主节点的id，主节点每次启动这个id都会改变，这个relid主要在psync命令中使用。
4.repl_backlog是主节点的挤压缓冲区，在后面的部分复制中会介绍。

🚀在从节点执行info replication命令：

从节点这里会比主节点多一些字段，比如，priority字段（在从节点替换主节点时用到），slave_read_only表示从节点的只读属性。

主从复制的拓扑结构

一主一从

🚀读请求可以减轻主节点的压力，但是写请求无法减轻主节点的压力，但是可以通过关闭主节点的aof，开启从节点的aof来减缓主节点的压力。但是这又会引起一个新的问题，就是主节点挂掉后不要立即重启，因为主节点的aof时关闭的，在重启的时候，会丢失数据，进一步的在同步数据到从节点的时候，会删除掉从节点的一些数据，导致从节点也会丢失数据。
改进：主节点挂掉之后，从 从节点这里获取aof文件，进行重启。

一主多从

🚀一主多从相比一主一从能更好的减轻主节点的读请求压力，但是同时增加了主节点同步数据到从节点的压力。

树形结构

🚀这种树形结构可以改善一主多从的问题，从节点也可以有从节点，主节点不用一份数据直接同步到所有从节点上了，但是这种结构会加大数据同步的延迟时间，这种树形结构的每条路径越长，数据同步的延迟时间越大。

数据同步

主从复制的执行流程

🚀主从复制的流程即一个从节点挂接到一个主节点上的整个流程：

🚀1.从节点首先会保存主节点的ip+port。
🚀2.从节点与主节点建立tcp长连接，这个长连接是通过发送心跳包来实现的，一般从节点没1s就会给主节点发送一个数据包，告诉主节点其数据同步的进度，同样主节点会每10s给从节点发送一个心跳包来维护连接。
🚀3.使用ping命令是在应用层的角度，检测双方能够正常的进行通信。
🚀4.权限验证指的是，当主节点的redis服务器设置了密码的时候，从节点想要与其建立主从连接的时候，也要进行密码的验证。
🚀5.从节点刚与主节点建立连接的时候，主节点会把其数据同步给从节点，第一次同步数据是同步了全量的数据。
🚀6.经过第一次全量数据同步后，后面主节点再收到的写请求，会实时的同步到从节点。

psync指令

sync replicationid offset

🚀redis提供的psync命令，用于主节点和从节点之间的数据同步，psync不用手动执行，redis服务器会在建立好主从关系后自动执行psync命令，从节点负责执行这个命令，从节点从主节点拉取数据。

🚀replicationid：

主节点生成的复制id，主节点在每次启动的时候都会生成一个复制id，从节点和主节点建立好主从关系后，会从主节点这边获取replicationid，从节点第一次执行psync命令 psync ？-1，这时主节点会对从节进行全量数据的同步，并且将自己的复制id传送给从节点。

🚀offset：

主节点和从节点都会维护这个offset变量，对于主节点，主节点会收到许多修改操作的命令，每个命令占用几个字节，主节点会把这个命令所占用的字节数累加。对于从节点，offset表示数据同步的进度，从节点会每秒钟上报自己的offset给主节点。

全量复制

🚀当从节点首次连接上主节点的时候需要进行全量复制，从节点会向主节点发送psync指令，并且通常第一次为psync ？-1，这个指令就告诉主节点要进行全量的复制了。
🚀全量复制的过程：
1.从节点向主节点发送psync命令，由于是第一次复制从节点没有 replicationid和offset的信息，所以发送的是psync ？ -1。
2.主节点对psync命令进行解析，解析出从节点想要全量复制，回复FULLRESYNC响应。
3.从节点保存必要的信息，例如replicationid。
4.主节点执行bgsave命令，生成rdb文件。
5.主节点将生成的rdb文件传送给从节点，从节点保存到本地磁盘。
6.主节点将从生成bgsave开始，到从节点接受rdb成功这个期间接受到的修改命令记录在缓冲区中，主节点再将缓冲区的这些命令发送给从节点，以保持主从间的一致性。
7.从节点清空自身的数据。
8.从节点加载rdb文件以及主节点缓冲区中的命令，恢复数据的一致性。
9.如果从节点开启的aof持久化方式，会触发bgrewrite命令，进行aof的重写操作，得到最新的aof文件。

无硬盘模式的全量复制

🚀无硬盘模式就是对全量复制的优化，就是减少了与磁盘IO的消耗，即全量复制时主节点通过bgsave生成的rdb文件不要再去写磁盘了，而是直接发送给从节点。同样，从节点收到主节点的rdb文件也不用去写磁盘，而是直接利用rdb文件的数据进行数据的一致性恢复。

部分复制

🚀部分复制是全量复制的特殊情况，即也是发生在建立主从关系的时候。通常是由于网络抖动或者从节点重启等原因，从节点重新连接主节点建立连接关系。这个时候从节点已经有了大部分的主节点的数据，不需要进行全量复制了。
🚀部分复制的过程：
1.当主从节点之间网络中断时，如果超过了配置的reli-timeout时间，主节点会认为从节点故障，并且断开连接。
2.但是在这期间主节点会将收到的修改命令记录在挤压缓冲区当中。
3.当网络恢复时，从节点再次连接主节点，从节点发送psync replid offset命令，请求主节点进行部分复制。
4.主节点接收到psync命令后会进行解析，首先判断replid的一致性，如果不一致直接进行全量复制，再根据offset去判断当前的挤压缓冲区能否满足部分复制的需求，响应给从节点CONTINUE。
5.主节点将需要同步的数据发送给从节点，进行数据的一致性恢复。

实时复制

🚀实时复制就是已经建立的主从的关系，那么会将主节点时时刻刻收到的修改命令都要同步给从节点，保证数据的一致性。主从节点之间会建立TCP的长连接，主节点会将自己收到的命令通过长连接发送给从节点。
🚀这种长连接的维护：主节点会定期发送心跳包给从节点，并且从节点会每秒将自己的offset上报为主节点。

从节点与主节点断开连接的情况

🚀1.如果是从节点主动的执行slave no one断开的主从关系，那么此时这个从节点会成为新的主节点。
🚀2.如果是主节点崩溃导致的，那么从节点不会自动晋升为新的主节点，需要人工干预。如果是配置了哨兵模式，那么哨兵也能替代人工完成从节点晋升为新主节点的操作。