中企动力云邮箱,网站功能优化,id导入不了wordpress,彩妆网站建设策划书Redis 主从复制 redis 主从复制配置 redis 主从复制启动 redis 主从复制断开 redis 主从复制主从复制构特点主从复制的拓扑结构一主一从⼀主多从树状主从 主从复制原理数据同步psync 运行流程全量复制流程部分复制流程实时复制 关于从节点何时晋升成主节点总结 redis 主从复制 … Redis 主从复制 redis 主从复制配置 redis 主从复制启动 redis 主从复制断开 redis 主从复制主从复制构特点主从复制的拓扑结构一主一从⼀主多从树状主从 主从复制原理数据同步psync 运行流程全量复制流程部分复制流程实时复制 关于从节点何时晋升成主节点总结 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-onlyyes 配置为只读模式。由于复制只能从主节点到从节点对于从节点的任何修改主节点都⽆法感知修改从节点会造成主从数据不⼀致。所以建议线上不要修改从节点的只读模式。 传输延迟 主从节点⼀般部署在不同机器上复制时的⽹络延迟就成为需要考虑的问题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 主节点端口的形式即可。
主从复制的缺点:
从机多了, 复制数据的延时⾮常明显。主机挂了, 从机不会升级成主机. 只能通过人工干预的方式恢复。
