创建网站 英文,帝国程序和WordPress,做网站需要知道的问题,网站开发实战答案redis中为了实现高可用#xff08;High Availability#xff0c;简称HA#xff09;#xff0c;采用了如下两个方式#xff1a;主从复制数据。采用哨兵监控数据节点的运行情况#xff0c;一旦主节点出现问题由从节点顶上继续进行服务。主从复制redis中主从节点复制数据有全…redis中为了实现高可用High Availability简称HA采用了如下两个方式主从复制数据。采用哨兵监控数据节点的运行情况一旦主节点出现问题由从节点顶上继续进行服务。主从复制redis中主从节点复制数据有全量复制和部分复制之分。旧版本全量复制功能的实现全量复制使用snyc命令来实现其流程是从服务器向主服务器发送sync命令。主服务器在收到sync命令之后调用bgsave命令生成最新的rdb文件将这个文件同步给从服务器这样从服务器载入这个rdb文件之后状态就会和主服务器执行bgsave命令时候的一致。主服务器将保存在命令缓冲区中的写命令同步给从服务器从服务器执行这些命令这样从服务器的状态就跟主服务器当前状态一致了。旧版本全量复制功能其最大的问题是从服务器断线重连时即便在从服务器上已经有一部分数据了也需要进行全量复制这样做的效率很低于是新版本的redis在这部分做了改进。新版本全量复制功能的实现新版本redis使用psync命令来代替sync命令该命令既可以实现完整全同步也可以实现部分同步。复制偏移量执行复制的双方主从服务器分别会维护一个复制偏移量主服务器每次向从服务器同步了N字节数据之后将修改自己的复制偏移量N。从服务器每次从主服务器同步了N字节数据之后将修改自己的复制偏移量N。复制积压缓冲区主服务器内部维护了一个固定长度的先进先出队列做为复制积压缓冲区其默认大小为1MB。在主服务器进行命令传播时不仅会将写命令同步到从服务器还会将写命令写入复制积压缓冲区。服务器运行ID每个redis服务器都有其运行ID运行ID由服务器在启动时自动生成主服务器会将自己的运行ID发送给从服务器而从服务器会将主服务器的运行ID保存起来。从服务器redis断线重连之后进行同步时就是根据运行ID来判断同步的进度如果从服务器上面保存的主服务器运行ID与当前主服务器运行ID一致则认为这一次断线重连连接的是之前复制的主服务器主服务器可以继续尝试部分同步操作。否则如果前后两次主服务器运行ID不相同则认为是完成全同步流程。psync命令流程有了前面的准备下面开始分析psync命令的流程如果从服务器之前没有复制过任何主服务器或者之前执行过slaveof no one命令那么从服务器就会向主服务器发送psync ? -1命令请求主服务器进行数据的全量同步。否则如果前面从服务器已经同步过部分数据那么从服务器向主服务器发送psync runid offset命令其中runid是上一次主服务器的运行idoffset是当前从服务器的复制偏移量。前面两种情况主服务器收到psync命令之后会出现以下三种可能主服务器返回fullresync runid offset回复表示主服务器要求与从服务器进行完整的数据全量同步操作。其中runid是当前主服务器运行id而offset是当前主服务器的复制偏移量。如果主服务器应答continue那么表示主服务器与从服务器进行部分数据同步操作将从服务器缺失的数据同步过来即可。如果主服务器应答-err那么表示主服务器版本低于2.8识别不了psync命令此时从服务器将向主服务器发送sync命令执行完整的全量数据同步。哨兵机制redis使用哨兵机制来实现高可用(HA)其大概工作原理是redis使用一组哨兵sentinel节点来监控主从redis服务的可用性。一旦发现redis主节点失效将选举出一个哨兵节点作为领导者leader。哨兵领导者再从剩余的从redis节点中选出一个redis节点作为新的主redis节点对外服务。以上将redis节点分为两类哨兵节点sentinel负责监控节点的运行情况。数据节点即正常服务客户端请求的redis节点有主从之分。以上是大体的流程这个流程需要解决以下几个问题如何对redis数据节点进行监控如何确定一个redis数据节点失效如何选择出一个哨兵领导者节点哨兵节点选择新的主redis节点的依据是什么以下来逐个回答这些问题。三个监控任务哨兵节点通过三个定时监控任务监控redis数据节点的服务可用性。info命令每隔10秒每个哨兵节点都会向主、从redis数据节点发送info命令获取新的拓扑结构信息。redis拓扑结构信息包括了本节点角色主或从。主从节点的地址、端口信息。这样哨兵节点就能从info命令中自动获取到从节点信息因此那些后续才加入的从节点信息不需要显式配置就能自动感知。向__sentinel__:hello频道同步信息每隔2秒每个哨兵节点将会向redis数据节点的__sentinel__:hello频道同步自身得到的主节点信息以及当前哨兵节点的信息由于其他哨兵节点也订阅了这个频道因此实际上这个操作可以交换哨兵节点之间关于主节点以及哨兵节点的信息。这一操作实际上完成了两件事情 * 发现新的哨兵节点如果有新的哨兵节点加入此时保存下来这个新哨兵节点的信息后续与该哨兵节点建立连接。 * 交换主节点的状态信息作为后续客观判断主节点下线的依据。向数据节点做心跳探测每隔1秒每个哨兵节点向主、从数据节点以及其他sentinel节点发送ping命令做心跳探测这个心跳探测是后续主观判断数据节点下线的依据。主观下线和客观下线主观下线上面三个监控任务中的第三个探测心跳任务如果在配置的down-after-milliseconds之后没有收到有效回复那么就认为该数据节点“主观下线sdown”。为什么称为“主观下线”因为在一个分布式系统中有多个机器在一起联动工作网络可能出现各种状况仅凭一个节点的判断还不足以认为一个数据节点下线了这就需要后面的“客观下线”。客观下线当一个哨兵节点认为主节点主观下线时该哨兵节点需要通过”sentinel is-master-down-by addr”命令向其他哨兵节点咨询该主节点是否下线了如果有超过半数的哨兵节点都回答了下线此时认为主节点“客观下线”。选举哨兵领导者当主节点客观下线时需要选举出一个哨兵节点做为哨兵领导者以完成后续选出新的主节点的工作。这个选举的大体思路是每个哨兵节点通过向其他哨兵节点发送”sentinel is-master-down-by addr”命令来申请成为哨兵领导者。而每个哨兵节点在收到一个”sentinel is-master-down-by addr”命令时只允许给第一个节点投票其他节点的该命令都会被拒绝。如果一个哨兵节点收到了半数以上的同意票则成为哨兵领导者。如果前面三步在一定时间内都没有选出一个哨兵领导者将重新开始下一次选举。可以看到这个选举领导者的流程很像raft中选举leader的流程。选出新的主节点在剩下的redis从节点中按照以下顺序来选择新的主节点过滤掉“不健康”的数据节点比如主观下线、断线的从节点、五秒内没有回复过哨兵节点ping命令的节点、与主节点失联的从节点。选择slave-priority从节点优先级最高的从节点如果存在则返回不存在则继续后面的流程。选择复制偏移量最大的从节点这意味着这个从节点上面的数据最完整如果存在则返回不存在则继续后面的流程。到了这里所有剩余从节点的状态都是一样的选择runid最小的从节点。提升新的主节点选择了新的主节点之后还需要最后的流程让该节点成为新的主节点哨兵领导者向上一步选出的从节点发出“slaveof no one”命令让该节点成为主节点。哨兵领导者向剩余的从节点发送命令让它们成为新主节点的从节点。哨兵节点集合会将原来的主节点更新为从节点当其恢复之后命令它去复制新的主节点的数据。欢迎移步搜索关注公众号互联网架构师之路(hlw_architector)获取最新架构材料。
