学做网站论坛插件,网站建设的经费预算,山西龙采网站建设合同,公众号外链网站怎么做文章目录 1 :peach:环境配置:peach:1.1 :apple:三种配置方式:apple:1.2 :apple:验证:apple:1.3 :apple:断开复制和切主:apple:1.4 :apple:安全性:apple:1.5 :apple:只读:apple:1.6 :apple:传输延迟:apple: 2 :peach:拓扑结构:peach:2.1 :apple:⼀主⼀从结构:apple:2.2 :apple:⼀… 文章目录 1 :peach:环境配置:peach:1.1 :apple:三种配置方式:apple:1.2 :apple:验证:apple:1.3 :apple:断开复制和切主:apple:1.4 :apple:安全性:apple:1.5 :apple:只读:apple:1.6 :apple:传输延迟:apple: 2 :peach:拓扑结构:peach:2.1 :apple:⼀主⼀从结构:apple:2.2 :apple:⼀主多从结构:apple:2.3 :apple:树形主从结构:apple: 3 :peach:原理:peach:3.1 :apple:复制过程:apple:3.2 :apple:数据同步 psync:apple:3.2.1 :lemon:replicationid/replid:lemon:3.2.2 :lemon:offset (偏移量):lemon: 3.3 :apple:psync 运行流程:apple:3.4 :apple:全量复制:apple:3.5 :apple:部分复制:apple:3.6 :apple:实时复制:apple: 1 环境配置
1.1 三种配置方式
参与复制的 Redis 实例划分为主节点master和从节点slave。每个从结点只能有⼀个主节点⽽⼀个主节点可以同时具有多个从结点。复制的数据流是单向的只能由主节点到从节点。配置复制的⽅式有以下三种
在配置⽂件中加⼊ slaveof {masterHost} {masterPort} 随 Redis 启动⽣效。在 redis-server 启动命令时加⼊ --slaveof {masterHost} {masterPort} ⽣效。直接使⽤ redis 命令slaveof {masterHost} {masterPort} ⽣效。
接下来我们便使用配置文件的方式来演示(因为使用此方法可以不用每次重启时都加选项): 首先我们将etc/redis.conf文件中的数据拷贝到用户自定义的目录下 然后设置daemonize和portdaemonize设置为yes,port设置为我们自定义的端口号 在最后一行加上slaveof {masterHost} {masterPort}
另外一个也是同理。 接下来默认启动的 redis (也就是端口号为6379)作为主 Redis重新通过命令⾏启动⼀个 Redis 实例作为从Redis
redis-server /root/redis-slave/slave1.conf
redis-server /root/redis-slave/slave2.conf当启动成功后我们使用ps命令进行查看
会发现此时就多了端口号为8848和8849的从redis。
1.2 验证
我们可以来简单的验证下 当我们从从节点获取数据时我们发现可以成功但是不能够在从节点上修改数据以及删除数据。这个其实也很好理解因为Redis的主从结构就是主节点只负责写数据从节点负责读取数据。 此时可以通过 info replication 命令查看复制相关状态: 我们现在主节点上使用该命令 至于其他的参数后面我们都会详细的解释。 在slave1节点使用该命令 slaveof 命令不但可以建⽴复制还可以在从节点执⾏ slaveof no one 来断开与主节点复制关系。
1.3 断开复制和切主
断开复制主要流程
1断开与主节点复制关系。2从节点晋升为主节点。
从节点断开复制后并不会抛弃原有数据只是⽆法再获取主节点上的数据变化。 通过 slaveof 命令还可以实现切主操作将当前从节点的数据源切换到另⼀个主节点。执⾏slaveof {newMasterIp} {newMasterPort} 命令即可。
切主操作主要流程
1断开与旧主节点复制关系。2与新主节点建⽴复制关系。3删除从节点当前所有数据。4从新主节点进⾏复制操作。
1.4 安全性
对于数据⽐较重要的节点主节点会通过设置 requirepass 参数进⾏密码验证这时所有的客⼾端访问必须使⽤ auth 命令实⾏校验。从节点与主节点的复制连接是通过⼀个特殊标识的客⼾端来完成因此需要配置从节点的masterauth 参数与主节点密码保持⼀致这样从节点才可以正确地连接到主节点并发起复制流程。
1.5 只读
默认情况下从节点使⽤ slave-read-onlyyes 配置为只读模式。由于复制只能从主节点到从节点对于从节点的任何修改主节点都⽆法感知修改从节点会造成主从数据不⼀致。所以建议线上不要修改从节点的只读模式。
1.6 传输延迟
主从节点⼀般部署在不同机器上复制时的⽹络延迟就成为需要考虑的问题Redis 为我们提供了 repl-disable-tcp-nodelay 参数⽤于控制是否关闭 TCP_NODELAY默认为 no即开启 tcpnodelay 功能说明如下
当关闭时主节点产⽣的命令数据⽆论⼤⼩都会及时地发送给从节点这样主从之间延迟会变小但增加了网络带宽的消耗。适⽤于主从之间的⽹络环境良好的场景如同机房部署。当开启时主节点会合并较⼩的 TCP 数据包从⽽节省带宽。默认发送时间间隔取决于 Linux 的内核⼀般默认为 40 毫秒。这种配置节省了带宽但增大主从之间的延迟。适⽤于主从⽹络环境复杂的场景如跨机房部署。 2 拓扑结构
Redis 的复制拓扑结构可以⽀持单层或多层复制关系根据拓扑复杂性可以分为以下三种⼀主⼀从、⼀主多从、树状主从结构。
2.1 ⼀主⼀从结构
⼀主⼀从结构是最简单的复制拓扑结构⽤于主节点出现宕机时从节点提供故障转移⽀持当应⽤写命令并发量较⾼且需要持久化时可以只在从节点上开启 AOF这样既可以保证数据安全性同时也避免了持久化对主节点的性能⼲扰。但需要注意的是当主节点关闭持久化功能时如果主节点宕机要避免⾃动重启操作。 2.2 ⼀主多从结构
⼀主多从结构星形结构使得应⽤端可以利⽤多个从节点实现读写分离。对于读⽐重较⼤的场景可以把读命令负载均衡到不同的从节点上来分担压⼒。同时⼀些耗时的读命令可以指定⼀台专⻔的从节点执⾏避免破坏整体的稳定性。对于写并发量较⾼的场景多个从节点会导致主节点写命令的多次发送从⽽加重主节点的负载。 2.3 树形主从结构
树形主从结构分层结构使得从节点不但可以复制主节点数据同时可以作为其他从节点的主节点继续向下层复制。通过引⼊复制中间层可以有效降低系统按负载和需要传送给从节点的数据量。数据写⼊节点 A 之后会同步给 B 和 C 节点B 节点进⼀步把数据同步给 D 和 E 节点。当主节点需要挂载等多个从节点时为了避免对主节点的性能⼲扰可以采⽤这种拓扑结构。 3 原理
3.1 复制过程
如图所⽰下⾯详细介绍建⽴复制的完整流程。从图中可以看出复制过程⼤致分为 6 个过程 1保存主节点master的信息。 开始配置主从同步关系之后从节点只保存主节点的地址信息此时建⽴复制流程还没有开始在从节点 8848 执⾏ info replication 可以看到如下信息 从统计信息可以看出主节点的 ip 和 port 被保存下来主节点的连接状态master_link_status是上线状态。
2从节点slave内部通过每秒运⾏的定时任务维护复制相关逻辑当定时任务发现存在新的主节点后会尝试与主节点建⽴基于 TCP 的⽹络连接。如果从节点⽆法建⽴连接定时任务会⽆限重试直到连接成功或者⽤⼾停⽌主从复制。 3发送 ping 命令。连接建⽴成功之后从节点通过 ping 命令确认主节点在应⽤层上是⼯作良好的。如果 ping 命令的结果 pong 回复超时从节点会断开 TCP 连接等待定时任务下次重新建⽴连接。 4权限验证。如果主节点设置了 requirepass 参数则需要密码验证从节点通过配置 masterauth 参数来设置密码。如果验证失败则从节点的复制将会停⽌。 5同步数据集。对于⾸次建⽴复制的场景主节点会把当前持有的所有数据全部发送给从节点这步操作基本是耗时最⻓的所以⼜划分称两种情况全量同步和部分同步。 6命令持续复制。当从节点复制了主节点的所有数据之后针对之后的修改命令主节点会持续的把命令发送给从节点从节点执⾏修改命令保证主从数据的⼀致性。
3.2 数据同步 psync
Redis 使⽤ psync 命令完成主从数据同步同步过程分为全量复制和部分复制。
全量复制⼀般⽤于初次复制场景Redis 早期⽀持的复制功能只有全量复制它会把主节点全部数据⼀次性发送给从节点当数据量较⼤时会对主从节点和⽹络造成很⼤的开销。部分复制⽤于处理在主从复制中因⽹络闪断等原因造成的数据丢失场景当从节点再次连上主节点后如果条件允许主节点会补发数据给从节点。因为补发的数据远⼩于全量数据可以有效避免全量复制的过⾼开销。
PSYNC 的语法格式:
PSYNC replicationid offset如果 replicationid 设为 ? 并且 offset 设为 -1 此时就是在尝试进⾏全量复制。如果 replicationid offset 设为了具体的数值, 则是尝试进⾏部分复制。 3.2.1 replicationid/replid
主节点的复制 id主节点重新启动或者从节点晋级成主节点, 都会⽣成⼀个 replicationid。(同⼀个节点, 每次重启⽣成的 replicationid 也会变化)。 从节点在和主节点建⽴连接之后, 就会获取到主节点的 replicationid. 通过 info replication 即可看到 replicationid:
关于 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 ⾃成⼀派, 继续处理后续的数据。
3.2.2 offset (偏移量)
参与复制的主从节点都会维护⾃⾝复制偏移量。主节点master在处理完写⼊命令后会把命令的字节⻓度做累加记录统计信息在 info replication 中的 master_repl_offset 指标中:
从节点slave每秒钟上报⾃⾝的复制偏移量给主节点因此主节点也会保存从节点的复制偏移量统计指标如下 从节点在接受到主节点发送的命令后也会累加记录⾃⾝的偏移量。统计信息在 info replication 中slave_repl_offset 指标中 通过对⽐主从节点的复制偏移量可以判断主从节点数据是否⼀致。
replid offset 共同标识了⼀个 “数据集”如果两个节点, 他们的 replid 和 offset 都相同, 则这两个节点上持有的数据, 就⼀定相同。
3.3 psync 运行流程 1从节点发送 psync 命令给主节点replid 和 offset 的默认值分别是 ? 和 -1. 2主节点根据 psync 参数和⾃⾝数据情况决定响应结果
如果回复 FULLRESYNC replid offset则从节点需要进⾏全量复制流程。如果回复 CONTINEU从节点进⾏部分复制流程。如果回复 -ERR说明 Redis 主节点版本过低不⽀持 psync 命令。从节点可以使⽤ sync 命令进⾏全量复制。 psync ⼀般不需要⼿动执⾏. Redis 会在主从复制模式下⾃动调⽤执⾏。sync 会阻塞 redis server 处理其他请求. psync 则不会。 3.4 全量复制
全量复制是 Redis 最早⽀持的复制⽅式也是主从第⼀次建⽴复制时必须经历的阶段。全量复制的运⾏流程如图所⽰: 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 ⽂件。
通过分析全量复制的所有流程我们会发现全量复制是⼀件⾼成本的操作主节点 bgsave 的时间RDB 在⽹络传输的时间从节点清空旧数据的时间从节点加载 RDB 的时间等。所以⼀般应该尽可能避免对已经有⼤量数据集的 Redis 进⾏全量复制。
补充 有磁盘复制 vs ⽆磁盘复制(diskless) 默认情况下, 进⾏全量复制需要主节点⽣成 RDB ⽂件到主节点的磁盘中, 再把磁盘上的RDB⽂件通过发送给从节点。 Redis 从 2.8.18 版本开始⽀持⽆磁盘复制. 主节点在执⾏ RDB ⽣成流程时, 不会⽣成 RDB⽂件到磁盘中了, ⽽是直接把⽣成的 RDB 数据通过⽹络发送给从节点. 这样就节省了⼀系列的写硬盘和读硬盘的操作开销。 3.5 部分复制
部分复制主要是 Redis 针对全量复制的过⾼开销做出的⼀种优化措施使⽤ psync replicationId offset 命令实现。当从节点正在复制主节点时如果出现⽹络闪断或者命令丢失等异常情况时从节点会向主节点要求补发丢失的命令数据如果主节点的复制积压缓冲区存在数据则直接发送给从节点这样就可以保持主从节点复制的⼀致性。补发的这部分数据⼀般远远⼩于全量数据所以开销很⼩。 1当主从节点之间出现⽹络中断时如果超过 repl-timeout 时间主节点会认为从节点故障并终端复制连接。 2主从连接中断期间主节点依然响应命令但这些复制命令都因⽹络中断⽆法及时发送给从节点所以暂时将这些命令滞留在复制积压缓冲区中。 3当主从节点⽹络恢复后从节点再次连上主节点。 4从节点将之前保存的 replicationId 和 复制偏移量作为 psync 的参数发送给主节点请求进⾏部分复制。 5主节点接到 psync 请求后进⾏必要的验证。随后根据 offset 去复制积压缓冲区查找合适的数据并响应CONTINUE 给从节点。 6主节点将需要从节点同步的数据发送给从节点最终完成⼀致性。
复制积压缓冲区 复制积压缓冲区是保存在主节点上的⼀个固定⻓度的队列默认⼤⼩为 1MB当主节点有连接的从节点slave时被创建这时主节点master响应写命令时不但会把命令发送给从节点还会写⼊复制积压缓冲区。
由于缓冲区本质上是先进先出的定⻓队列所以能实现保存最近已复制数据的功能⽤于部分复制和复制命令丢失的数据补救。复制缓冲区相关统计信息可以通过主节点的 info replication 中
127.0.0.1:6379 info replication
# Replication
role:master
...
repl_backlog_active:1 // 开启复制缓冲区
repl_backlog_size:1048576 // 缓冲区最⼤⻓度
repl_backlog_first_byte_offset:7479 // 起始偏移量计算当前缓冲区可⽤范围
repl_backlog_histlen:1048576 // 已保存数据的有效⻓度根据统计指标可算出复制积压缓冲区内的可⽤偏移量范围[repl_backlog_first_byte_offset,repl_backlog_first_byte_offset repl_backlog_histlen]。
如果当前从节点需要的数据, 已经超出了主节点的积压缓冲区的范围, 则⽆法进⾏部分复制, 只能全量复制了。
3.6 实时复制
主从节点在建⽴复制连接后主节点会把⾃⼰收到的修改操作 , 通过 tcp ⻓连接的⽅式, 源源不断的传输给从节点。 从节点就会根据这些请求来同时修改⾃⾝的数据. 从⽽保持和主节点数据的⼀致性。
另外, 这样的⻓连接, 需要通过心跳包的⽅式来维护连接状态。(这⾥的⼼跳是指应⽤层⾃⼰实现的⼼跳,⽽不是 TCP⾃带的⼼跳)
1主从节点彼此都有⼼跳检测机制各⾃模拟成对⽅的客⼾端进⾏通信。 2主节点默认每隔 10 秒对从节点发送 ping 命令判断从节点的存活性和连接状态。 3从节点默认每隔 1 秒向主节点发送 replconf ack {offset} 命令给主节点上报⾃⾝当前的复制偏移量。
如果主节点发现从节点通信延迟超过 repl-timeout 配置的值默认 60 秒则判定从节点下线断开复制客⼾端连接。从节点恢复连接后⼼跳机制继续进⾏。
