相信很多小伙伴都已经配置好了主从复制，只是对工作流程没有深入了解以及redis主从复制学习的常见问题。卡卡这次用了两天时间，把redis主从复制的所有知识点都梳理了一遍。本文实现所需环境centos7.0redis4.01、什么是Redis主从复制？主从复制是指现在有两台redis服务器，将一台redis的数据同步到另一台redis数据库。前者称为主节点（master），后者称为从节点（slave）。数据只能在一个方向上从主机同步到从机。但是在实际过程中，不可能只有两台redis服务器进行主从复制，也就是说每台redis服务器都可以称为主节点（master）。在下图的例子中，我们的slave3既是master的slave节点，也是slave的master节点。先了解这样一个概念，继续看下文更详细的解释。二、为什么需要Redis主从复制？假设我们现在有一个redis服务器，是单机状态。这种情况首先会出现的问题就是服务器宕机，直接导致数据丢失。如果项目涉及￥，那么后果可想而知。第二种情况是内存问题。当只有一台服务器时，内存肯定会达到峰值。服务器不可能无限升级。所以针对以上两个问题，我们多准备了几台服务器，配置主从复制。在多个服务器上保存数据。并保证各个服务器的数据是同步的。即使一台服务器宕机，也不会影响用户的使用。Redis可以持续的同时实现高可用和数据的冗余备份。这次会议应该有很多问题。如何连接主从？如何同步数据？如果主服务器宕机了怎么办？别着急，一点一点解决你的问题。3、Redis主从复制的作用上面我们说了为什么要用redis主从复制，那么主从复制的作用就是说明为什么要用。我们继续用这张图讲第一点是数据冗余，实现数据的热备份，这是持久化之外的另一种方式。第二点是针对单机故障的问题。当主节点即master出现问题时，可以由从节点即slave提供服务，实现故障快速恢复，即服务冗余。第三点是读写分离。主服务器主要用于写入，从服务器主要用于读取数据，可以提高服务器的负载能力。同时可以根据需求的变化增加从节点的数量。第四点是负载均衡。读写分离，主节点提供写服务，从节点提供读服务，分担服务器负载。尤其是在写少读多的情况下，通过多个从节点分担读负载，可以大大提高服务器的性能。增加redis服务器的并发和负载。第五点是高可用的基石。主从复制是哨兵和集群实现的基础。因此，可以说主从复制是高可用的基石。4、配置Redis主从复制说了这么多，我们先来简单配置一个主从复制案例，再说说实现原理。redis存放路径为：usr/local/redis日志和配置文件存放在：usr/local/redis/data首先我们先配置两个配置文件，分别是redis6379.conf和redis6380.conf修改配置文件，主要修改端口。为了方便查看，日志文件和持久文件的名称都用各自的端口来标识。然后分别开启两个redis服务，一个端口为6379，一个端口为6380。执行命令redis-serverredis6380.conf，然后使用redis-cli-p6380连接，因为redis默认端口是6379，所以我们再启动一个redis服务器直接使用redis-serverredis6379.conf然后直接使用redis-cli直接连接即可。此时我们已经成功配置了两个redis服务，一个是6380的，一个是6379的，这里只是为了演示。在实际工作中，需要在两台不同的服务器上进行配置。1、开始使用客户端命令行首先要有一个概念，就是在配置主从复制的时候，所有的操作都是在从节点上进行的，也就是slave。然后我们在slave节点上执行一个命令为slaveof127.0.0.16379，也就是说执行完我们就连接上了。我们先测试一下是否实现了主从复制。在master服务器上执行两次setkaka123和setmaster127.0.0.1，就可以在slave6380端口上成功获取到，也就是说我们的主从复制已经配置好了。但这并不是生产环境的结束。后期会进一步优化主从复制，直到实现高可用。2.使用配置文件启用它。在使用配置文件启动主从复制之前！需要在客户端命令行断开之前的连接，在宿主机上执行slaveofnoone断开主从复制。在哪里可以查看从节点是否已经与主节点断开连接？在master节点客户端输入命令行info查看这张图片。在打印的信息中可以看到有slave0的信息。该图是从节点执行slaveofnoone后主节点打印的信息，表示从节点已经与主节点断开连接。根据配置文件启动redis服务后，从节点重启后redis-serverredis6380.conf可以直接在主节点上查看到从节点的连接信息。测试数据，主节点写的东西，从节点还是会自动同步的。3、在启动redis服务器的时候启动这种配置方式也很简单。启动redis服务器时，直接启动主从复制，执行命令：redis-server--slaveofhostport。4、查看主从复制启动后的日志信息。这是主节点的日志信息。这是从节点的信息，包括连接主节点和保存RDB快照的信息。五、主从复制的工作原理1.主从复制的三个阶段主从复制的完整工作流程分为以下三个阶段。每个部分都有自己的内部工作流程，所以我们将讨论这三个过程。连接建立过程：这个过程就是slave连接到master的过程数据同步过程：master同步数据到slave的过程命令传播过程：重复数据同步s-serif；字体大小：15px；text-align:center;">2.第一阶段：连接建立过程上图是一个完整的主从复制建立连接的工作流程。接下来用简短的词来描述上面的工作流程。设置master的地址和端口,保存master的信息并建立socket连接（这个连接干什么下面会讲）不断发送ping命令进行认证发送slave端口信息在建立连接的过程中，slave节点会保存从节点的地址和端口3、第二阶段：数据同步阶段流程本图详细描述了从节点第一次连接到主节点时的数据同步过程.从节点第一次连接到主节点时，会先进行全量复制。这个完整的副本是不可避免的。执行全量拷贝后，主节点会将拷贝积压缓冲区中的数据发送出去，然后从节点执行bgrewriteaof恢复数据，这也是部分拷贝。这个阶段提到了三个新点，全量复制、部分复制和复制缓冲区积压。这些要点将在下面的常见问题解答中详细说明。4.第三阶段：命令传播阶段。当主库修改，主从服务器数据不一致时，会同步主从数据，使其一致。这个过程称为命令传播。主机将接收到的数据更改命令发送给从机，从机收到命令后执行该命令，从而使主从数据保持一致。commandpropagationphase部分replication在commandpropagation阶段断开，或者网络抖动导致连接丢失。此时主节点master会继续向replbackbuffer（replicationbufferbacklog）写入数据，从节点会继续尝试连接主机（connecttomaster），当从节点发送自己的runid和replicationoffset时到master节点，执行pysnc命令进行同步，如果master判断偏移量在复制缓冲区范围内，则返回continue命令。并将复制缓冲区中的数据发送给从节点。从节点接收数据，执行bgrewriteaof恢复数据6.详细介绍主从复制原理（全量复制+部分复制）。这个过程是主从复制最完整的过程讲解。那么我们就简单介绍一下流程的每一步吧。从节点发送命令psync？1psyncrunidoffset找到对应的runid来请求数据。但是在这里你可以考虑一下。从节点第一次连接时，根本不知道主节点的runid和offset。那么第一次发送的命令是psync？1表示我想要master节点的所有数据。master节点开始执行bgsave生成RDB文件，记录当前replicationoffset偏移量。这时主节点会通过socket通过+FULLRESYNCrunidoffset命令将自己的runid和offset发送给从节点。从节点收到+FULLRESYNC，保存主节点的runid和offset，然后清除所有当前数据，通过socket接收RDB文件，开始恢复RDB数据。全量复制后，从节点已经获取到主节点的runid和offset，开始发送命令psyncrunidoffset主节点收到命令，判断runid是否匹配，判断offset是否在复制中缓冲。如果主节点判断runid和offset其中之一不满足，则返回步骤2，继续进行全量复制。这里runid不匹配的唯一原因是重启从节点后问题就会解决。如果偏移量（offset）不匹配，复制积压缓冲区就会溢出。如果runid或offset检查通过，并且slave节点的offset与master节点的offset相同，则忽略。如果runid或offset校验通过，从节点的offset与offset不同，则发送+CONTINUEoffset（此offset为主节点），将数据从从节点offset发送到主节点offset中通过套接字复制缓冲区。slave节点收到+CONTINUE并保存master的offset后，通过socket收到信息后，执行bgrewriteaof恢复数据。1-4是全量复制，5-8是主节点第3步下的部分复制。主节点在主从复制期间一直在接收客户端的数据，主节点的偏移量一直在变化。只要有变化，就会发给各个slave。这个发送过程称为心跳机制7.在心跳机制的命令传播阶段，始终需要主节点和从节点之间进行信息交换，心跳机制用于维护，以保持主节点和从节点在线连接。Master心跳命令：默认每10秒ping一次，由参数repl-ping-slave-period决定。主要要做的就是判断从节点是否在线。可以使用inforeplication查看slave节点租用后的连接时间间隔，lag0或1为正常状态。从机心跳任务命令：replconfack{offset}每秒执行一次。主要要做的就是将自己的replicationoffset发送给master节点，从master节点获取最新的datachangecommand，再做一件事判断master节点是否在线。心跳阶段注意事项为了保证数据的稳定性，当从节点数量挂掉或者延迟过高时，主节点会失效。所有信息同步都会被拒绝。这里有两个参数可以配置调整：min-slaves-to-write2min-slaves-max-lag8这两个参数表示slave节点数只有2个，或者slave节点延迟大于8时秒后，master节点将强制关闭master功能，停止数据同步。那么主节点如何知道从节点的数量和延迟时间呢？在心跳机制中，slave会每秒发送一次命令perlconfack。该命令可以携带偏移量，也可以携带延迟时间和从节点数量。八、部分复制的三个核心要素1.服务器的运行id(runid)我们先来看看runid是什么，执行info命令就可以看到。在上面我们还可以看到启动日志信息。Redis在启动的时候会自动生成一个随机的id（这里需要注意的是每次启动的id都不一样），它由40个随机的十六进制字符串组成，用来唯一标识一个redis节点。第一次启动主从复制时，master会把自己的runid发给slave，slave会保存master的id。我们可以使用info命令查看，当断线重连时，slave会把这个id发送给master。如果slave保存的master的runid和master当前的runid相同，master会尝试使用partialreplication（这个block能否复制成功还有一个因素就是offset）。如果slave保存的runid和master当前的runid不同，则直接进行fullcopy。2.Replicationbacklogbufferreplicationbufferbacklog是一个先进先出的队列，用户存放master采集数据的命令记录。复制缓冲区默认存储空间为1M。可以在配置文件中修改repl-backlog-size1mb来控制缓冲区大小。这个比例可以根据自己的服务器内存修改。卡卡在这里保留了大约30%的股份。复制缓冲区中到底存储了什么？在执行命令setnamekaka的时候，我们可以查看持久化文件可以看到copybacklogbuffer是存储的持久化数据的aof，以字节分隔，每个wordsection都有自己的offset。这个偏移量也是拷贝偏移量（offset），那么为什么说copybufferbacklog可能会导致fullcopy呢？在命令传播阶段，主节点将收集到的数据存储在复制缓冲区中，然后发送给从节点。这就是问题所在。当主节点上的数据量在瞬间非常大，超过复制缓冲区的内存时，部分数据将被挤出，导致主节点和从节点之间的数据不一致。执行完整复制。如果buffersize设置不合理，可能会造成死循环，从节点一直会全量复制，清除数据，再全量复制。3、复制偏移量（offset）主节点的复制偏移量就是向从节点发送一次记录，从节点接收一次记录。用于同步信息，比较主节点和从节点之间的差异，以及在从节点断开时恢复数据使用。该值也是复制缓冲区积压的偏移量。九。主从复制常见问题1.主节点重启问题（内部优化）主节点重启时，runid的值会发生变化，会导致所有从节点进行全量复制。这个问题我们不用想，只知道系统是怎么优化的。主从复制建立后，主节点会创建一个master-replid变量。生成的策略与runid相同，长度为41位，runid长度为40位，然后发送给从节点。当master节点执行shutdownsave命令时，一个RDB持久化会将runid和offset保存到RDB文件中。您可以使用命令redis-check-rdb查看这些信息。master节点重启后加载rdb文件，将文件中的repl-id和repl-offset加载到内存中。即使所有的从节点都被认为是之前的主节点。2.从节点网络中断偏移量超过限制，导致全量复制。由于网络环境不佳，导致从节点网络中断。replicationbacklogbuffer的内存太小，导致数据溢出，slave节点的offset越界，导致fullreplication。它可能会导致重复完全复制。解决方法：修改replicationbacklogbuffer的大小：repl-backlog-size设置建议：测试主节点连接从节点的时间，获取主节点平均每秒产生的命令总量write_size_per_secondreplicationbufferspacesetting=2*master-slaveConnectiontime*master节点每秒产生的数据总量3.网络频繁中断是因为master节点CPU占用率高或者slave节点连接频繁。这种情况的结果是主节点的各种资源被严重占用，包括但不限于缓存、宽带、连接等，为什么主节点的资源会被严重占用？在心跳机制中，从节点会每隔一秒向主节点发送一个命令replconfack命令。从节点执行慢查询，占用大量cpu。主节点每秒调用一次复制定时函数replicationCron，然后从节点长时间没有响应。解决方法：设置从节点超时释放设置参数：repl-timeout该参数默认为60秒。60秒后，释放奴隶。4、数据不一致问题由于网络因素，多个从节点的数据会不一致。这个因素无法避免。针对这个问题给出了两种解决方案：第一种需要数据高度一致，配置一个redis服务器，一台服务器读写。这种方法仅限于少量数据，需要数据高度一致。第二个监控主从节点的偏移量。如果从节点延迟过大，则暂时屏蔽客户端访问从节点。将参数设置为slave-serve-stale-datayes|no。一旦设置了这个参数，它只能响应少数命令，比如infoslaveof。5、slave节点故障问题是直接在客户端维护一个可用节点列表。当从节点出现故障时，会切换到其他节点上工作。这个问题稍后会在集群中讨论。十、总结本文主要讲解什么是主从复制，主从复制工作的三个主要阶段，工作流和部分复制的三个核心。命令传播阶段的心跳机制。最后解释一下主从复制的常见问题。作者：原来是卡卡链接：https://juejin.im/post/5ed5ccb66fb9a047df7ca9a4来源：掘金
