redis主从复制

一)什么是主从复制？

分布式系统涉及到一个非常关键的问题，就是单点问题，如果某一个服务器程序，只有一个节点，也就是说只是搞一个物理服务器来部署这个服务器程序，就会出现以下问题

1)可用性问题:如果这个机器挂了，意味着服务器就中断了，内存满了，硬盘坏了，无法启动，网线断了，导致机器无法正常工作，就意味着redis服务中断了，此时其他节点想要使用这台机器上的数据，就无法访问；

2)性能和系统的并发量也是有限的，一个请求需要消耗CPU，内存，磁盘，网络带宽，一个主机毕竟提供硬件资源是有限的

1)所以引入分布式系统，主要是解决上述的单点问题，在分布式系统往往希望有多个服务器来部署redis服务从而构成一个redis集群，此时就可以让这个集群给整个分布式系统中其他的服务提供更稳定也更高效的数据存储功能；

2)假设有三个物理服务器，称之为是三个节点，分别部署了一个redis-server进程，此时就可以把其中的一个节点称之为是主节点，另外两个节点称之为是从节点，从节点上的数据要和主节点保持一致

3)本来在主节点上保存着一堆数据，引入从节点以后，就是要把主节点上面的数据，复制出来放到从节点上面去，后续在主节点上面对于数据有任何的修改，都会把这样的修改同步到从节点上面去，从节点就是从节点的副本，在Redis主从模式中，从节点上面的数据，不允许修改，只是允许读数据；

4)由于从节点上面的数据都是时刻和主节点是保持一致的，因此其他的客户端从从节点这里面读取数据，和从主节点这里面读取数据是没有本质区别的，如果后续有客户端来读取数据了，就可以从上述节点中，随机挑选一个节点，给这个客户端提供读取数据的服务，引入了更多的计算资源，自然就能够支撑的并发量也就大幅度提高了；

5)主从模式主要是针对读操作进行并发量和可用性的提升，而写操作的话无论是可用性还是高并发，都是十分依赖于主节点的，主节点又不能搞多个，但是在实际操作中，读操作还是比写操作更频繁；

正常来说，配置redis主从结构，需要首先启动多个redis服务器，正常来说，每一个redis服务器程序，应该在一个单独的主机上才是分布式系统，但是我们是可以在一个云服务器主机上运行多个redis-server进程的，但是这多个进程之间redis-server的端口号是不同的

1)本来redis-server的端口就是6379，此时就不可以让新启动的redis-server进程继续使用6379了，只需要修改端口和是以后台的方式运行即可

上面直接可以通过cp命令来进行复制操作cp /etc/redis.conf ./redis1.conf即可

2)当前这几个节点没有构成主从结构，redis-cli -p 端口号 -a 密码，下面的配置都是以127.0.0.1充当云服务器的主节点IP，修改完成配置文件以后重新启动redis生效

3)此时进行搭配的时候需要注意使用kill -9 的方式停止，是和之前通过直接运行redis-server命令的方式来进行搭配的，而如果是使用service redis-server start方式来进行启动的，就必须要使用service redis-server stop来进行停止，如果要是使用kill -9的方式来进行停止，那么kill掉以后，redis-server这个进程能够正常启动，服务器本身就是稳定性和高可用，但是服务器上面的某些程序，可能也难以避免出现挂了的情况，如果服务器进程挂了，要是可以自动重启进程，对于整体的服务就不会有太大的影响，往往会有另外一个进程，来专门监控指定服务器进程运行的运行状态，况且我们的从节点启动以后就会和主节点建立TCP连接

4)主节点这边数据产生任何的修改，从节点就可以立即感知到，通过info implication查看主从之间的状态

Redis主从第一次同步是全量同步，会将内存生成快照，整体发送给salve，下面来解析一下全量同步的过程

1)从节点要执行一个replicaof命令，建立连接，并且指定master的IP地址和端口号，一旦建立成功slave就可以向master发送请求了，发送一个sync命令，来进行请求数据同步；

2)主节点会进行判断你是否是第一次来，如果你是第一次来，那么主节点会把所有的数据返回给从节点，如果客户端不是第一次来，那么只是会返回部分的数据，你缺多少，服务器给多少，同时slave自身会将原有数据全部清除，自动的替换成master数据；

3)如果是第一次来，那么主节点会向从节点发送自己的版本信息，然后从节点会将这个版本的信息记录；

4)如果主节点判断是全量同步，那么主节点的主线程会执行bgsave命令，生成一个子进程来生成一个RDB文件，这样对于主进程没有什么影响，主进程继续去处理用户请求；

5)RDB文件里面记录了完整的内存信息，然后主进程会发送这个RDB信息发送给我们的从节点，从节点拿到这个RDB文件就是相当于是拿到了主节点的全部数据了，然后从节点会把本地的RDB文件进行清空，然后会进行加载发送过来的RDB文件，这样master和slave节点基本一致，这里是基本一致；

6)因为在bgsave异步执行的过程中，那么主进程还是会进行处理用户的请求的，那么会有新的数据写入到主节点的内存中，但是这些新的数据并没有发送给从节点，所以master的主进程除了要进行处理新的数据之外，主进程还会把这些命令记录到repl_backlog这样的内存缓冲区中，repl_backlog这样的缓冲区会进行记录在bgsave期间收到的新的命令，只要未来从节点成功收到了bgsave的RDB文件再来执行主节点在bgsave中向repl_backlog中的写入的所有命令，就是master节点的完整数据；

7)主节点会将repl_backlog中的所有的命令发送给从节点，从节点去执行接收到的命令，从而保证master和slave节点中的数据是完全一致的

8)后续主进程再次执行客户端发送过来的命令，都会写入到repl_backlog中，master节点有独立进程将这些repl_backlog中的命令发送给slave节点，master发出ping包的周期，默认是10s

这样的全量同步会将内存生成快照，整体发送给slave节点，所以叫做全量同步，生成rdb文件比较慢，况且全量同步速度比较慢，只有在第一次建立连接才去做；

主从复制的拓扑结构:

1)如果写请求太多，此时也是会给主节点造成一些压力，可以通过关闭主节点的AOF，只在从节点上开启AOF

2)但是这种设定有一个缺陷，主节点一旦挂了，不能让他自动重启，如果自动重启，此时没有AOF文件，就会丢失数据，主从同步也会把从节点数据也搞没了，改进方法就是当主节点挂了以后，就需要让主节点从从节点这里来获取到AOF文件，再启动

3)实际开发中读请求多于从节点

4)当主节点上面的数据发生改变，就会将改变的数据同时同步给所有的从节点，随着从节点数据的增加，同步一条数据就需要主节点通过网络传输多次，多次传输给不同的从节点

5)主节点就不需要那么高的网卡带宽，一旦数据进行修改，同步的延时是比刚才更长的，层数越多，需要同步的时间就越长，更关注想要单台网络带宽消耗，总体网络时间延迟更高

由此可知master是如何来进行判断slave是不是第一次来进行同步数据呢？

1)Replication ID:简称为是replid，是数据集的标记，ID相同则说明是同一数据集，每一个master都具有唯一的ID，后续的salve会进行继承master节点的repliID，如果是从节点第一次来，那么主节点会把这个repliID给从节点，这样后续从节点和主节点的repliID就一致了，就说明使用一个数据集了；

2)offset:也被称之为是偏移量，随着记录在repl_backlog中的数据增多而逐渐增大，slave在完成同步的时候也会进行记录当前同步的offset，如果slave的offset小于master节点的offset，说明slave数据落后于master，需要进行数据的更新，slave中的offset是永远小于master中的offset的，因为从节点的offset是从主节点中拷贝过来的，如果主节点的offset值等于从节点的offset值，说明主从数据一致，描述的是拷贝的进度；

3)因此slave在做数据同步的时候，必须向master声明自己的replication ID(判断是不是非第一次同步)和offset(判断进度)，master才可以进行判断自己到底要同步哪些数据；

offset偏移量：主节点和从节点上面都会维护一个偏移量，也就是一个整数，主节点的偏移量，因为本身主节点上收到了很多的修改操作的命令，每一个命令都是需要占据几个字节的，主节点会将这些修改命令，每一个命令的字节数进行累加，从节点的偏移量就描述了从节点这里面的数据同步到那里了，从节点会定期也就是每分钟会上报自身的复制偏移量给从节点

1)replicationID表示数据从哪一个机器上进行同步，offset表示从这个机器上获取数据的进度

2)如果发现两台机器，replicationID一样，offset也是一样的，就可以认为这两个redis机器上面存储的数据是相同的

master是如何来进行判断slave节点是不是第一次来做同步的？

1)直接判断offset是否为0即可；

2)难道说主要offset大于0就一定是第一次做同步吗？就一定不是第一次来吗？假设你的offset很大，但是此时发送过来的主节点的Replication ID和主节点ReplicationID不相同，之前从节点是从其他的master节点拷贝过来的，所以此时的offset是无意义的；

3)总结:因为每一个节点都存在着唯一的Replication ID，所以判断从节点是否是第一次来进行更新数据的依据是，如果主节点的Replication ID和从节点的Replication ID相同，那么说明不是第一次，如果Replication ID不相同，则说明是第一次；

slave no one断开从节点和主节点之间的关系，直接在redis客户端里面执行即可

slaveof 主机IP 主机端口号

上面的这样的修改命令都是临时命令，但是重启以后还是会按照配置文件的方式来进行启动

1)slave of no one从节点断开复制并不会抛弃原有数据，只是⽆法再获取主节点上的数据变化，从节点断开主从关系，他就不再属于其他节点了，但是里面的已经存在的数据是不会发生变化的，但是如果后续主节点如果针对于数据本身进行修改，从节点就无法自动同步数据

2)通过slave of命令还可以实现切主操作，也是认从其他节点

主从节点⼀般部署在不同机器上，复制时的⽹络延迟就成为需要考虑的问题，Redis为我们提供了repl-disable-tcp-nodelay参数⽤于控制是否关闭TCP_NODELAY，默认为no，即开启tcp-nodelay功能，说明如下：
1)当关闭时，主节点产⽣的命令数据⽆论⼤⼩都会及时地发送给从节点，这样主从之间延迟会变⼩，但增加了⽹络带宽的消耗,适⽤于主从之间的⽹络环境良好的场景，如同机房部署
2)当开启时，主节点会合并较⼩的TCP数据包从⽽节省带宽。默认发送时间间隔取决于Linux的内核，⼀般默认为40毫秒这种配置节省了带宽但增⼤主从之间的延迟,适⽤于主从⽹络环境复杂的场景，如跨机房部署

二)全量同步的流程:

1)从节点向主节点请求增量数据同步，带上自己的RID和offset，因为每一个从节点变成真正的从节点之前都会有自己的RID和offset；

2)master节点会进行判断从节点的Replication ID是否和主节点自己的Replication ID是否一致，如果不同，说明要进行全量同步，拒绝增量同步，然后从节点会进行记录主节点的RepID和offset，此时从节点再来的时候就会带上这两部分信息，从节点带来的RID和主节点相同，然后再来基于offset进行判断数据同步的进度；

3)master的主进程会开启一个分进程将完整的内存数据生成RDB文件，然后将这个RDB文件发送给slave节点；

4)接下来从节点会清空本地数据，会进行加载master中的RDB文件到从节点到内存中；

5)主节点的主进程会将RDB期间的命令记录在repl_backlog，并会开启一个新的进程将log中的命令发送给slave；

6)slave会不断的执行log中的命令，保持数据同步；

1)保存主节点的信息，开始配置主从同步关系以后，从节点只是保存主节点的地址信息，此时建立复制的流程还没有开始，从节点执行slave of命令保存主节点的IP地址和端口号

2)从节点内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点，会尝试和主节点建立TCP的网络连接，如果从节点无法建立连接，定时任务会一直尝试知道连接成功或者是用户停止主从复制

3)发送ping命令，连接建立成功以后，从节点通过ping命令确认主节点在应用层上面是工作良好的，如果ping命令的pong回复超时从节点TCP会断开连接，等待下次定时任务建立连接

4)权限校验:如果主节点设置了requirepass参数，则需要密码校验，从节点通过配置masterauth来验证密码，如果验证失败，那么从节点的复制将会停止

5)同步数据集:对于首次建立复制的场景，主节点会把当前所有持有的数据全部发送给从节点，这一步操作基本上是耗时最长的

6)命令持续复制:当从节点复制了主节点上面的所有数据以后，针对于之后的修改命令，主节点会持续地把命令发送给从节点，从节点执行修改命令，保证主从复制的一致性

1)redis提供了psync命令，来完成数据同步的过程，psync命令不需要手动执行，redis服务器会在建立好主从同步关系之后，自动来执行psync，从节点负责执行这个命令，从节点从主节点这里拉取数据

2)psync replicationID offset

2.1)replicationID这个ID是主节点自动生成的ID，一个主节点这一次启动和下一次启动所生成的replicationID都是不一样的，即使是同一个主节点，每一次重启生成的replicationID都是不一样的，从节点和主节点建立了复制关系，就会从主节点获取到replictionID，表示是从哪一个主节点上来获取数据，通过info replicationID来获取到当前replicationID这个命令

2.2)这个ID是主节点的复制ID，主节点重新启动，或者是从节点晋升成主节点，都会生成一个replicationID，同一个节点每一次重启，生成的replicationID也会发生变化

3)一般情况下，这个replicationID2是用不上的，有一个主节点A和一个从节点B，主节点A会生成replicationID，从节点B就会获取到A的replicationID，此时如果A和B通信过程中出现了一些网络抖动，B可能就会认为A挂了，此时B就会自己生成一个主节点，B会给自己生成一个replicationID，此时B也会记得旧的replicationID，就是replictionID2，后续网络稳定了，B还可以根据replicationID2重新回到A的怀抱，但是哨兵机制可以自动完成这个过程

4)从节点每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量

全量复制的流程:整体的数据量比较大，网络传输速度太慢

1)触发全量复制是由从节点主动触发的，此次假设从节点是首次和主节点进行复制，从节点发送psync命令给主节点，此时replictionID和offset的默认值分别是？和-1

2)主节点根据psync参数和自身数据情况进行决定响应结果:

如果主节点回复fullresync replid offset，那么从节点需要进行全量复制流程

如果主节点回复+contineu:从节点进行部分复制流程

如果主节点回复-err，说明主节点redis版本过低，不支持psync命令，从节点可以使用sync命令进行全量复制，但是本身sync不会阻塞redis server响应其他请求，但是psync不会

3)从节点就会保存主节点replicationID，保存到mater repliID里

4)主节点指定bgsave生成RDB文件进行持久化，尽量不要传输AOF，传输RDB文件比较节省空间，但是AOF文本文件体积比较大，非常占用网络带宽，传输的更慢

5)主节点发送RDB文件给从节点，从节点保存RDN文件到本地硬盘

6)主节点将从生成RDB文件到接收完成期间的写命令，会写入到一个缓冲区中，等到从节点保存完成RDB文件以后，主节点再将缓冲区中的数据补发给从节点，补发的数据仍然按照RDB的二进制格式追加到收到的RDB文件中，保证主从一致性

7)从节点清空自身原有的旧数据

8)从节点加载RDB文件得到和主节点一样的数据

9)如果从节点加载RDB完成以后，并且开启了AOF持久化功能，他会执行bgrewrite操作得到最近的AOF文件

主节点进行全量复制的时候，也是支持无硬盘模式，主节点生成的RDB数据不是直接保存在文件中了，而是直接进行网络传输了，省下了一系列读硬盘和写硬盘的操作，从节点之前也是把收到的RDB数据，写入到磁盘中，然后再次进行加载，现在也可以省略这个过程，直接可以把收到的数据进行加载了，即使引入了无硬盘模式，但是整个操作仍然是比较重量，因为本身网络传输是没有办法省的，相比于网络传输来说，读写硬盘仍然是小头；

replicationID和runID，infoserver可以查看runID，info replicationID

1)runID是每一个节点都互不相同的，表示一个redis的运行，主要是用来支撑redis实现哨兵机制的ID

2)replid则是具有主从关系的节点，是相同的

工作目录就是dir选项

 三)增量同步:

主从第一次同步是全量同步，但是如果slave重启之后进行同步，那么一定是执行增量同步，那么在slave再重启的这一段时间，主节点是一定会进行执行用户输入的命令的

1)从节点会向主节点发送Replication ID和offset，主节点判断过了Replication ID和从节点的ReplicationID是相同的，那么主节点会直接向从节点返回一个continue;

2)那么此时主节点想从节点发送数据的时候，就不用写RDB文件了，只不过是从节点在重启的时候丢失了一部分数据，这部分数据就在主节点的repl_backlog里面；

3)既然从节点向主节点发送了一个offset数据，那么主节点只需要定位到repl_backlog中的offset为止(从节点发送过来的offset值)再继续向后读取就可以了，也就是hirepl_backlog中去除掉offset之后的数据，此时从节点只需要执行这些命令就可以把剩下的数据给补上了；

4)hirepl_backlog的结构就类似于是一个环形链表，如上图所示，红色的区域是主节点的master，主节点的master表示当前主节点记录到的链表的位置在哪里，绿色的部分表示从节点做主从同步操作同步数据更新到哪里，后续从节点发生宕机，绿色到红色之间的部分就是从节点在宕机之间错过的数据，所以要进行传递的就是从slave的offset到master最新的offset之间的数据，但是slvae的offset和master的offset不要超过这个环形链表的存储上限，那么是永远可以在这个环中找到你所需要补齐的数据，永远可以做到增量同步，但是slave中的offset和master的offset之间的差异已经超过存储上限了，那么就永远无法再做增量同步了

5)此时原来的绿色部分是从节点的offset，剩下的红色部分就是master在slave宕机之后，新增的新命令，可以看到，如果这个时候从节点还不来做增量同步，那么主节点新增的数据一定会将slave区域覆盖；

6)这个时候主节点不光将绿色区域给覆盖了，还将slave尚未同步备份的数据进行了覆盖，因为slave的offset在环里面被覆盖，这时只能做全量同步，slave欠的债太多了

7)repl_backlog的大小是有上限的，写满之后会覆盖最早的数据，如果slave从节点断开时间过久，导致没有进行备份的数据被覆盖，欠的数据超过一圈了，那么是无法基于log做增量同步的，只能做全量同步

优化Redis主从集群:1 2是为了减少主从复制，3 4是为了减少全量同步

1)在master中redis.conf配置repl-diskless-sync yes开启无磁盘复制，避免全量同步时候的磁盘IO，也就是写RDB文件，当要进行写RDB文件的时候，不把它写到磁盘中，而是使用网络直接发送给从节点，适用于磁盘读写比较慢，减少磁盘读写，但是网络带宽比较快；

2)master单节点上面的内存占用不要太大，减少RDB生成导致的磁盘IO

3)适当提高back_log的大小，在发现slave宕机的时候能够尽快的实现故障恢复，避免全量同步，增大主节点offset和从节点offset的差值

4)限制一个master节点上面的slave节点数量，如果有太多的slave节点，可以采用主-从-主这样的链式结构，来减轻master的压力，因为如果有很多主节点去找从节点做全量同步，那么主节点压力非常大；

 一)简述全量同步和增量同步的区别:

全量同步:master将完整的内存数据生成RDB文件，发送RDB文件到slave，后续命令将记录在repl_backlog中，逐个发送给slave节点

增量同步:slave提交自己的offset和RID到master，master获取到repl_backlog中从offset之后的命令给从节点

二)什么时候执行全量同步？

slave节点第一次连接到master结点的时候做全量同步

slave节点断开太久，repl_backlog中的offset已经被覆盖的时候

三)什么时候执行增量同步？

slave节点断开又恢复，并且在repl_backlog中可以找到对应的offset值的时候

四)主从复制的缺点:

当主节点挂了之后，不会从从节点中选取一个节点来充当主节点，每一次主节点挂了，还需要人工来进行干预

部分复制主要是redis针对于全量复制的过高开销做出的一种优化策略，使用psync replicationID offset命令来实现，当从节点正在复制主节点的时候，如果出现网络闪退或者是命令丢失等异常情况的时候，从节点会向主节点要求补发之前的丢失的命令数据，如果主节点的复制积压缓冲区存在数据则直接发送给从节点，这样就可以保持主从节点复制的⼀致性，补发的这部分数据⼀般远远⼩于全量数据，所以开销很小；

1)从节点要从主节点这里进行全量复制，全量复制的开销是很大的，有些时候，从节点本身已经持有了主节点的绝大部分数据，这个时候就可能不太需要全量复制了，比如说出现网络抖动，主节点这边的最近修改的数据可能就无法及时同步过来，更严重的是，从节点已经无法感知主节点，进一步从节点可能会升级成主节点

2)但是网络抖动一般都是暂时的，不会一直抖动，过一会可能就恢复，此时就可以让主节点和从节点重新来建立联系，当从节点和主节点重新建连接以后，就需要进行数据同步，此时从节点和主节点才断开一小会，从节点和主节点数据大部分都是一致的

3)从节点此时执行psync命令，带有具体的replid和offset值，主节点就要根据psync的参数进行判定，看当前这次是看全量复制合适还是部分复制合适

 

1)积压缓冲区本质上就是一个内存中的简单的队列，会进行记录最近一段时间内修改的数据，总量有限，随着时间的推移，就会把之前旧的数据删除掉，其实replicationID本质上就是在描述数据的来源，如果此时replicationID不一样，只能进行全量复制了，offset在描述数据的复制的进度，offset是用来判定表示从节点之前同步数据的进度是如何，主节点就用来进行判断这个进度是否是在当前的积压缓冲区之内，如果是确实是在挤压缓冲区之内，此时直接可以进行部分数据复制，直接把最近这段时间的从节点没来得及同步的数据给复制过去即可，但是如果当前从节点落下的进度超过了挤压缓冲区的数据范围，他会记录最近一段时间修改的数据，但是总量有限，但是随着一些时间的推移，会把就的数据淘汰掉，只能进行全量复制了；

2)复制积压缓冲区是保存在主节点上面的一个固定长度的队列，默认大小是1MB，当主节点有连接的从节点的时候被创建，这个时候主节点响应写命令的时候，不但会把命令发送给从节点，还会把命令写入到积压缓冲区，本质上来说这个缓冲区就是一个先进先出的定长队列，所以能够保存最近已经复制的数据的功能，用于复制命令丢失的数据补救和部分复制， 如果当前从节点需要的数据已经超出了主节点的积压缓冲区的范围则⽆法进⾏部分复制只能全量复制了

四)实时复制:

1.1)全量复制:从节点刚连上主节点以后，进行的数据的初始化操作，都是刚一开始连上的时候操作的

1.2)增量复制:全量复制的特殊情况，优化手段，目的和全量复制一样，都是刚一开始脸上的时候操作的

1.3)实时复制:从节点已经和主节点建立好了连接了，从节点这一时刻已经和主节点数据一致了，但是之后主节点会源源不断地收到新的修改数据的请求，此是主节点上的数据就会随之改变，也能需要同时同步给从节点，从节点和主节点会建立一个TCP的长连接，主节点会把自己修改数据的请求，通过上述连接，发送给从节点，从节点再来根据这些修改请求来修改内存中的数据，主从节点之间通过⼼跳机制保证主从节点通信正常和数据⼀致性

1.4)再进行实时复制的时候，需要保证连接时刻处于可用状态，主节点默认是每隔10s给从节点发送一个ping命令，从节点收到就返回一个pong命令，默认时间是60s，主节点就认为从节点挂了，从节点这边默认每隔1s发起一个特定的请求，就会上报当前从节点同步数据的进度，就是offset；

主从复制的缺点:

1)从机多了，复制数据的延时会非常明显，主节点挂了，从节点就迷茫了，虽然可以提供读操作，但是从节点不可以直接升级成主节点，不能够直接替换原有的主节点对应的角色，此时就需要程序员或者是运维手工的来恢复主节点

2)从节点挂了，从机不会升级成主机，只能通过人工的方式来进行干预

本身从节点和主节点断开连接一共有两种情况

1.1)从节点主动和主节点断开连接:slave of no one，这个时候从节点就可以主动晋升成主节点，意味着程序员要主动修改redis的拓扑结构

1.2)如果是主节点挂了，从节点是不会晋升成主节点的，必须通过人工干预的方式来恢复主节点，这个是脱离咱们掌控的，是高可用场景下的一个典型问题