Redis 主从复制
- [redis 主从复制](#redis 主从复制)
redis 主从复制
单点问题：如果某个服务器程序，只有一个节点(之高一个物理服务器，来部署这个服务器程序)。其中有以下两个缺陷：
- 可用性问题：如果这个机器挂了，意味着服务就中断了~~
- 性能/支持的并发量也是比较有限
在分布式系统中为了解决单点问题，通常会把数据复制多个副本部署到其他服务器，满⾜故障恢复和负载均衡等需求。Redis 也是如此，它为我们提供了复制的功能，实现了相同数据的多个Redis副本。复制功能是⾼可⽤ Redis 的基础，哨兵和集群都是在复制的基础上构建的。
在分布式系统中，希望使用多个服务器来部署 redis，存在以下几种 redis 的部署方式~~
- 主从模式
- 主从 + 哨兵模式
- 集群模式
配置 redis 主从复制
配置 redis 主从复制，首先要启动多个 redis 服务器~~
正常来说，每个 redis 服务器程序，应该在一个单独的机器上，这样才算的上分布式，但目前手中只有一台云服务器，此时也可以在一个云服务器主机上运行多个 redis-server，但要保证多个 redis-server的端口是要不同的，默认是6379。
指定 redis-server 端口的方法有下面两种：
1.可以在启动程序的时候，通过命令行选项 ( --port )来指定端口号。
2.在配置文件中设置端口号。
下面我想弄1个主节点两个从节点，主节点就用之前默认的配置文件，子节点配置文件要在主配置文件上修改才能使用，首先先拷贝出2份配置文件 /etc/redis/redis.conf，修改这两份配置文件给从节点使用。
- 分别修改拷贝出来的两份配置文件中的端口号，让两个从节点与父结点的端口号，三个端口都不一样，不然会bind error。如果是不同主机这个不用设置。
- 在将下面这个选项设为 yes，这个选项的意思是让redis-server以后台方式运行。
- 给每个从节点从节点创建所属的工作目录，并且修改从节点的配置文件，设定成新的目录为工作目录。
将下面这行dir设置为你给从节点创建的工作目录即可。如果是不同主机可以不用设置。
启动 redis 主从复制
修改完后就可以启动从节点的 redis-server。
此时并没有构成主从复制，而是各自为政，要想成为主从复制，还需要进行配置。
要想配置成主从复制，就需要使用 slaveof。配置的方式有以下三种：
-
在配置⽂件中加⼊ slaveof {masterHost} {masterPort} 随 Redis 启动⽣效。永久生效。
-
在 redis-server 启动命令时加⼊ --slaveof {masterHost} {masterPort} ⽣效。
-
直接使⽤ redis 命令：slaveof {masterHost} {masterPort} ⽣效。
配置好后，启动三个redis-server。
例如上面动图所示：
在主节点中可以写入，此时从节点slave1 与 slave2能够读取到主节点的数据。但是在从节点 slave2 想修改key时会报错，不允许从节点写入，具体如下图所示：
其中可以通过 info replication 命令查看相关状态
- 主节点
- 子节点
断开 redis 主从复制
slaveof 命令不但可以建⽴主从复制，还可以在从节点执⾏ slaveof no one 来断开与主节点主从复制关系。
例如在 6380 节点上执⾏ slaveof no one 来断开，不过此处的修改是临时性的，要想永久就将配置文件中配置主从复制的语句删除即可。
从节点主动断开主从复制主要流程：
- 断开与主节点复制关系。
- 从节点晋升为主节点。 从节点断开主从复制后并不会抛弃原有数据，只是⽆法再获取主节点上的数据变化。
主从复制构特点
-
安全性
对于数据⽐较重要的节点，主节点会通过设置 requirepass 参数进⾏密码验证，这时所有的客户端访问必须使⽤ auth 命令实⾏校验。从节点与主节点的复制连接是通过⼀个特殊标识的客户端来完成，因此需要配置从节点的masterauth 参数与主节点密码保持⼀致，这样从节点才可以正确地连接到主节点并发起复制流程。
-
只读
默认情况下，从节点使⽤ slave-read-only=yes 配置为只读模式。由于复制只能从主节点到从节点，对于从节点的任何修改主节点都⽆法感知，修改从节点会造成主从数据不⼀致。所以建议线上不要修改从节点的只读模式。
-
传输延迟
主从节点⼀般部署在不同机器上，复制时的⽹络延迟就成为需要考虑的问题，Redis 为我们提供了 repl-disable-tcp-nodelay 参数⽤于控制是否关闭 TCP_NODELAY，默认为 no，即开启 tcpnodelay 功能，说明如下：
-
关闭时，主节点产⽣的命令数据⽆论大小都会及时地发送给从节点，这样主从之间延迟会变小，但增加了⽹络带宽的消耗。适⽤于主从之间的⽹络环境良好的场景，如同机房部署。
-
当开启时，主节点会合并较小的 TCP 数据包从⽽节省带宽。默认发送时间间隔取决于 Linux 的内核，⼀般默认为 40 毫秒。这种配置节省了带宽但增⼤主从之间的延迟。适⽤于主从⽹络环境复杂的场景，如跨机房部署。
-
主从复制的拓扑结构
拓扑结构可以分为以下三种：⼀主⼀从、⼀主多从、树状主从结构。
一主一从
⼀主⼀从结构是最简单的复制拓扑结构，⽤于主节点出现宕机时从节点提供故障转移⽀持，如图所示。当应⽤写命令并发量较⾼且需要持久化时，可以只在从节点上开启 AOF，这样既可以保证数据安全性同时也避免了持久化对主节点的性能⼲扰。但需要注意的是，当主节点关闭持久化功能时，如果主节点宕机要避免⾃动重启操作。
这是因为一旦主节点宕机，如果重启，此时主节点没有生成 AOF 文件，就会丢失数据，进一步的主从同步，会把从节点的数据也删了。
针对此种问题的解决办法是当主节点宕机后，将从节点生成的AOF文件给到主节点，在启动。
⼀主多从
⼀主多从结构（星形结构）使得应⽤端可以利⽤多个从节点实现读写分离，如图所示。对于读比较重大的场景，可以把读命令负载均衡到不同的从节点上来分担压⼒。同时⼀些耗时的读命令可以指定⼀台专⻔的从节点执⾏，避免破坏整体的稳定性。对于写并发量较⾼的场景，多个从节点会导致主节点写命令的多次发送从⽽加重主节点的负载。
树状主从
树形主从结构（分层结构）使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。通过引⼊复制中间层，可以有效降低住复制负载和需要传送给从节点的数据量，如图所示。数据写⼊节点 A 之后会同步给 B 和 C 节点，B 节点进⼀步把数据同步给 D 和 E 节 点。当主节点需要挂载等多个从节点时为了避免对主节点的性能⼲扰，可以采⽤这种拓扑结构。
缺陷：一旦数据进行修改了，同步的延迟是比刚才一主多从要长的。
主从复制原理
主从节点建⽴复制流程图
数据同步
psync 语法格式 psync replicationid offset
-
如果 replicationid 设置为 ？并且offset 设为 -1，此时就是在尝试进行全量复制
-
如果 replicationid offset 设为了具体的数值，则是尝试进行部分复制
Redis 使⽤ psync 命令完成主从数据同步，同步过程分为：全量复制和部分复制。
-
全量复制：⼀般⽤于初次复制场景，Redis 早期⽀持的复制功能只有全量复制，它会把主节点全部数据⼀次性发送给从节点，当数据量较⼤时，会对主从节点和⽹络造成很⼤的开销。
-
部分复制：⽤于处理在主从复制中因⽹络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发数据给从节点。因为补发的数据远⼩于全量数据，可以有效避免全量复制的过⾼开销。
-
replicationid / replid (复制id) -> 通过 info replication
replid主要用于主从复制。主节点的复制id，主节点重写启动，或者从节点晋级成主节点，都会生成一个replicationid （同一个节点，每次重启，生成的 replicationid 也会变化）。从节点在和主节点建立连接之后，就会获取到主节点的 replicationid。
- runid-> 通过info server查看
runid 主要是用在支撑实现 redis 哨兵这个功能的。
- offset 偏移量
主节点和从节点上都会维护偏移量(整数)。
主节点的偏移量是根据主节点收到的修改操作命令，并计算每个修改命令都要占据几个字节，将每个命令的字节数进行累加。所以从节点的偏移量就描述了现在从节点这里数据同步到哪里了。
-
关于 master_replid 和 master_replid2
每个节点需要记录两组 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 ⾃成⼀派, 继续处理后续的数据.
psync 运行流程
- 从节点发送 psync 命令给主节点，runId 和 offset 的默认值分别是 ? 和 -1。
- 主节点根据 psync 参数和⾃⾝数据情况决定响应结果：
-
如果回复 +FULLRESYNC runId offset，则从节点需要进⾏全量复制流程。
-
如果回复 +CONTINEU，从节点进⾏部分复制流程。
-
如果回复 -ERR，说明 Redis 主节点版本过低，不⽀持 psync 命令。从节点可以使⽤ sync 命令进⾏全量复制。
sync 会阻塞 redis server 处理其他请求，而psync则不会
-
全量复制流程
1）从节点发送 psync 命令给主节点进⾏数据同步，由于是第⼀次进⾏复制，从节点没有主节点的运⾏ ID 和复制偏移量，所以发送 psync ? -1。
2）主节点根据命令，解析出要进⾏全量复制，回复 +FULLRESYNC 响应。
3）从节点接收主节点的运⾏信息进⾏保存。
4）主节点执⾏ bgsave 进⾏ RDB ⽂件的持久化。
5）主节点发送 RDB ⽂件给从节点，从节点保存 RDB 数据到本地硬盘。
6）主节点将从⽣成 RDB 到接收完成期间执⾏的写命令，写⼊缓冲区中，等从节点保存完 RDB ⽂件后，主节点再将缓冲区内的数据补发给从节点，补发的数据仍然按照 rdb 的⼆进制格式追加写⼊到收到的 rdb ⽂件中. 保持主从⼀致性。
7）从节点清空⾃⾝原有旧数据。
8）从节点加载 RDB ⽂件得到与主节点⼀致的数据。
9）如果从节点加载 RDB 完成之后，并且开启了 AOF 持久化功能，它会进⾏ bgrewrite 操作，得到最近的 AOF ⽂件。
有磁盘复制 vs ⽆磁盘复制(diskless)
默认情况下, 进⾏全量复制需要主节点⽣成 RDB ⽂件到主节点的磁盘中, 再把磁盘上的 RDB ⽂件通过发送给从节点.
Redis 从 2.8.18 版本开始⽀持⽆磁盘复制. 主节点在执⾏ RDB ⽣成流程时, 不会⽣成 RDB ⽂件到磁盘中了, ⽽是直接把⽣成的 RDB 数据通过⽹络发送给从节点. 这样就节省了⼀系列的写和读硬盘的操作开销。同时无磁盘复制高了网络负担。
部分复制流程
1）当主从节点之间出现⽹络中断时，如果超过 repl-timeout 时间，主节点会认为从节点故障并终端复制连接。
2）主从连接中断期间主节点依然响应命令，但这些复制命令都因⽹络中断⽆法及时发送给从节点，所 以暂这些命令滞留在复制积压缓冲区中。
3）当节点⽹络恢复后，从节点再次连上主节点。
4）从节点前保存的 replicationId 和 复制偏移量作为 psync 的参数发送给主节点，请求进⾏部分 复制。
5）主节点接到sync 请求后，进⾏必要的验证。随后根据 offset 去复制积压缓冲区查找合适的数据，并响应 +CONTUE 给从节点。
6）主节点将需要从节点的数据发送给从节点，最终完成⼀致性。
实时复制
实时复制：从节点已经和主节点同步好了数据(即从节点这一时刻已经和主节点数据一致了)，但是之后，树结点这边会收到新得修改数据的请求，此时主节点上的数据就会随之改变，同时也就需要能够同步给从节点。
从节点和主节点之间会建立TCP的长连接，然后主节点把自己收到的修改数据的请求，通过上述连接，发送给从节点，从节点再根据这些修改请求，修改内存中的数据。
关于从节点何时晋升成主节点
- 从节点主动和主节点断开连接
如使用命令来让从节点断开连接：slaveof no one，这个时候从节点就能够晋升主节点。 - 当主节点挂了宕机了
这个时候从节点不会晋升成主节点，必须通过人工干预恢复主节点，即重启主节点或者是让从节点成为主节点。
总结
主从复制解决的问题:
- 单点问题.
- 单个 redis 节点, 可⽤性不⾼。
- 单个 redis 节点, 性能有限。
- 主从复制的特点:
- Redis 通过复制功能实现主节点的多个副本。
- 主节点⽤来写, 从节点⽤来读. 这样做可以降低主节点的访问压⼒。
- 复制⽀持多种拓扑结构，可以在适当的场景选择合适的拓扑结构。
- 复制分为全量复制, 部分复制和实时复制。
- 主从节点之间通过⼼跳机制保证主从节点通信正常和数据⼀致性。
- 主从复制配置的过程:
- 主节点配置不需要改动。
- 从节点在配置⽂件中加⼊ slaveof 主节点ip 主节点端口的形式即可。
- 主从复制的缺点:
- 从机多了, 复制数据的延时⾮常明显。
- 主机挂了, 从机不会升级成主机. 只能通过人工干预的方式恢复。