wordpress 亚马逊插件,杭州seo薪资水平,企业网站建设与推广方案实例,推广计划有几种状态我们在生产中使用 Redis#xff0c;如果只部署一个 Redis 实例#xff0c;当该实例宕机#xff0c;到恢复之前都不可用#xff1b;虽说 Redis 一般都用来做缓存#xff0c;但不可用给业务系统带来的影响也是不小的#xff0c;流量大时甚至会导致整个服务宕机。所以 Redis…我们在生产中使用 Redis如果只部署一个 Redis 实例当该实例宕机到恢复之前都不可用虽说 Redis 一般都用来做缓存但不可用给业务系统带来的影响也是不小的流量大时甚至会导致整个服务宕机。所以 Redis 的高可用也非常重要Redis 的高可用简单来说就是增加冗余副本将一份数据保存在多个实例上即使有一个实例宕机其他服务仍然可以对外提供服务不影响业务使用。一. Redis 主从同步Redis 提供了主从模式一主多从来提高 Redis 的可用性主从库之间采用的是读写分离读操作主从库都能接收写操作主库能接收执行完后同步给从库主从同步原理首次全量同步主从第一次同步会经历三个步骤1主从库建立连接二者连接完成后开始同步。2首次同步需要全量数据主库会 fork 出一个子进程来生成 RDB 快照接着将 RDB 文件发送给从库不会阻塞主线程从库收到后清空旧数据最后加载 RDB 文件完成全量数据同步。3在主库生成 RDB 后接收的命令会暂存到一块内存区域replication buffer当从库加载完 RDB 快照后再将这块暂存的数据发送给从库执行最终完成首次主从同步。为什么要单独维护全量同步阶段的增量数据呢单独维护是为了保证命令执行的顺序性这批增量数据需要等到 RDB 文件加载完后再发送给从库否则会因为先后顺序不同导致主从不一致。当完成首次同步后主从之间维护一个长连接后续写命令通过这个长连接进行同步。长连接因为网络问题断开了期间的写命令会丢吗当发生网络分区导致长连接断开主库也会将写命令暂存到一块环形的内存区域等待连接恢复后将暂存的写命令发送给从库保证主从一致。做主从复制的作用是数据冗余主从复制实现了数据的热备份高可用当主节点出现问题时可以由从节点提供服务实现快速的故障恢复负载均衡在主从的模式下配合读写分离可以大大提供 Redis 整体的吞吐量。二. Redis 故障转移主从模式能做到数据备份也能支持读写分离但一旦主节点宕机需要人工介入切换主节点。Redis 提供了哨兵机制保证 Master 出现故障时自动进行主从切换也就是故障转移。哨兵机制哨兵节点的作用分为三点监控选主通知一般哨兵会集群部署原因是为了保证哨兵的高可用和防止下线误判下线误判在下面分析。哨兵实现故障转移原理1. 哨兵监控Sentinel 节点会监控 matser、slave 及其他 Sentinel 节点的状态。这个是通过 Redis 自身的 pub/sub 机制实现的。Redis 的哨兵一共有三个定时监控任务来完成节点的发现与监控。监控主从拓扑信息每隔 10 s每个 Sentinel 节点会向主从库发送 info 命令来获取最新的拓扑结构Sentinel 集群节点之间交换信息每隔 2 s每个 Sentinel 节点会向 _sentinel_:hello 频道上发送自身的信息以及对主节点的判断信息。这样Sentinel 节点之间就可以交换信息。节点状态监控每隔 1 s每个 Sentinel 节点会向 master、slave 及其他 Sentinel 节点发送 ping 命令做心跳检测服务端回复 pong 代表节点正常来判断这些节点是否可达。2. 主观下线Sentinel 每隔 1 s 会对数据节点发送 ping 命令做心跳检测当节点超过 down-after-milliseconds 没有进行回复Sentinel 会对该节点做失败判定这个行为被称作主观下线。主观下线顾名思义是主观的可能会误判假设主观下线后就进行主从切换实际主库并没有发生故障后续的选主和通知操作会带来额外的开销。发生误判的场景网络拥塞、节点发生短暂网络分区或是节点压力较大响应超时。3. 客观下线为了防止下线误判只有当大多数的哨兵节点认为 master 下线才算真正下线这个行为叫做客观下线。客观下线过程1 当某个 Sentinel 节点发生判断主库“主观下线”后会给其他哨兵实例发送 is-master-down-by-addr 命令其他哨兵节点会根据自己和主库的连接情况做出 Y赞同或 N反对的响应。2 当哨兵获取到了“客观下线”所需的赞成票数后就可以标记主库为“客观下线”这个所需要的票数由 quorum 配置项决定例如现在有 5 个哨兵quorum 为 2当两个哨兵判断主服务器下线后则触发故障转移。4.Sentinel Leader 选举当发生了客观下线后哨兵节点集群就会选出一个 Leader 来进行实际的故障转移操作。Redis 使用 Raft 算法来实现哨兵领导者的选举大致过程如下1哨兵节点设置主服务器为“客观下线”后向其他哨兵节点发送命令表明希望自己来执行主从切换其他哨兵节点会进行投票。2当哨兵节点拿到半数以上的赞成票且票数大于等于哨兵配置文件中的 quorum 值就会成为 Leader。Leader 选举的投票逻辑很简单在这一轮投票中如果没有投过票就回复同意如果投过票就回复拒绝。3如果此过程没有选出 Leader 则会等待故障超时间的 2 倍时长然后进入下一轮选举。什么情况会选不出 Leader哨兵集群能够成功投票很大程度上取决于正常的网络传输。如果网络压力大或短暂阻塞就可能导致没有哨兵节点拿到半数以上的票。而网络问题一般都会持续一小段时间所以在没有选出 Leader 后会等待一段时间再进入下一轮。5. 故障转移选出哨兵的 Leader 后就会进行故障转移也就是从 slave 中选出一个新 master 替换故障 master主要有以下判断标准1跟 master 断开链接的时长如果一个 slave 和 master 的断开链接时长已经超过 down-after-milliseconds 的 10 倍那哨兵就会认为该 slave 不适合被选为 master。2slave 的优先级配置slave priority 参数越小优先级越高。3主从复制进度当 优先级 相同时哪个 slave 和 master 的数据越接近优先级越高。4run id如果 优先级配置 和 主从复制进度 都相同则哪个 slave 的 run id 越小优先级越高。选出 master 后对它执行 slaveof no one 命令让其成为主节点并对剩余 slave 节点发送命令让他们成为新 master 的从节点最后和其他哨兵节点交换信息完成故障转移。主从切换过程中是否能对外正常提供读写服务如果采用读写分离还是可以正常处理读请求但是对于写请求服务端就无法处理了。如果需要应对写请求业务系统中可以将写缓存的操作改成异步或放到队列处理。脑裂问题如果碰巧客观下线也误判会发生什么会发生脑裂。脑裂就是在主从集群中同时有两个主节点他们都能接收写请求。而不同的客户端会往不同的主节点上写数据甚至导致数据丢失。Redis 的脑裂一般发生在主从切换时原主库假故障的场景下当主库因为一些原因无法处理哨兵节点的心跳检测时就会被判定为“客观下线”接着就会进行主从切换但在主从切换完成之前原主库又恢复服务就又会处理写请求当主从切换完成后通知客户端之前就会有两个主节点即发生脑裂。Redis 的脑裂可能会造成数据丢失根本原因是 Redis 内部没有通过共识算法来维护多个数据节点的强一致性因为强一致性的成本太大而 Redis 主打性能所以 Redis 放弃 C一致性 而选择 A可用性。
