wordpress 改网站介绍,阿里云 网站根目录,冯耀宗seo教程,网络营销方式单一CAP
C: 一致性
强调数据的正确性#xff0c;每次读操作#xff0c;要么读到最新#xff0c;要么读失败
A:可用性
不发生错误#xff0c;也不能出现过长的等待时间.
P:分区容错性
在网络环境不可靠的背景下#xff0c;整个系统仍然是正常运作的两种流派
#xff08;1每次读操作要么读到最新要么读失败
A:可用性
不发生错误也不能出现过长的等待时间.
P:分区容错性
在网络环境不可靠的背景下整个系统仍然是正常运作的两种流派
1CP强调系统数据的正确性但由于建立保证不同节点间保证数据严格一致的机制可能会牺牲系统的可用性.
2AP强调系统的可用性那就必须在数据一致性上做出妥协退让.常见c的问题
1.4 C 的问题
1即时一致性问题服务端采用了异步完成数据同步任务的机制那么客户端的读请求就可能在 follower 同步到 set x 3 这一项任务之前就打到 follower此时会取到 x 的老数据或者 x 不存在的响应。
2顺序一致性问题因为网络延迟数据同步指令的先后顺序造成了不一致为了解决上面c的问题
可能利用一些ACK机制包装统一收到从节点的响应才将数据同步变成了串行化的机制一个从节点的延迟或者无服务可能会影响整个系统的服务分布式一致性共识算法
分布式一致性共识算法指的是在分布式系统中使得所有节点对同一份数据的认知能够达成共识的算法.
多数派原则
多数派指的是一个群体的数量达到总数的一半以上.多数派原则指的是系统的决断无需全员参与,多数派达成的共识即可视为整个系统的答复.以集群存在 5 个节点为例多数派则需要集齐 3 个及 3 个以上节点至多可以允许 2 个节点存在开小差背离主流的情况. 同理倘若集群 6 个节点则多数派需要集齐 4 个及 4 个以上节点因此同样至多允许 2 个节点开小差. 综上这是奉行多数派原则的集群通常将节点个数设置为奇数的原因之一.多数派原则是提高分布式系统可用性 A 的关键一主多从
raft 算法下系统中的节点分为领导者 leader 和跟随者 follower 两类角色.读写分离
读操作可以由集群的任意节点提供服务写操作统一需要由 leader 收口处理并向 follower 同步. 倘若 follower 率先收到了来自客户端的写请求也需要转发给 leader 进行处理.如果是原始的raft论文《In Search of an Understandable Consensus Algorithm (Extended Version)》读写请求都是发送给leader。状态机与预写日志
状态机 state machine是节点实际存储数据的容器,写请求的最后一步是将结果写入状态机而读请求也需要从状态机中获取数据进行响应.预写日志 wal 在 raft 算法中写请求会先组织成预写日志的形式添加到日志数组中当一个日志写请求达到集群多数派的认可后才能够被提交将变更应用到状态机当中.预写日志由一个数组承载为一段时间内的多笔写请求提供了一个缓存区同时每笔预写日志是一笔写请求的抽象通过其记录的明细使得我们可以对写请求的内容进行比较. 这样的机制之下我们只要保证预写日志数组中被准许应用到状态机的部分每笔预写日志的内容都完全相同这样就能解决写请求乱序的问题从而达成数据的最终一致性.两阶段提交
从单机层面一笔写请求会分为添加到预写日志和应用到状态机两个步骤这是对两阶段提交的一种体现在整个系统层面
1leader 接收到来自客户端的一笔写请求2leader 将写请求添加到本地的预写日志中并向集群中其他节点广播同步这笔写请求. 这个过程可以称之为“提议”proposal3集群中各节点接收到同步请求后会一套检验机制判断是否能执行同步添加到预写日志校验机制这里不细述留待 4.1 小节细说4倘若集群总计半数以上的节点包括 leader 自身都将这笔请求添加预写日志并给予了 leader 肯定的答复ack那么 leader 此时会“提交”这个请求并给予客户端写请求已成功处理的响应5其他节点在随后的时段中会通过与 leader 的交互心跳或其他同步数据的请求感知到这个“提交”动作最终也在预写日志中提交这笔请求6被提交的预写日志具备了被应用到状态机的资格. 但应用的时机取决于实现方式倘若只追求最终一致性可以选择异步应用倘若追求立即一致性则会要求 leader 先应用到状态机才能给予客户端 ack.
领导者选举
leader的存活
1leader 需要定期向 follower 发送心跳证明存活. 与之对应的follower 会建立一个心跳检测定时器当超过指定时长未收到 leader 的心跳则认为 leader 已死会切换成候选人candidate发起竞选尝试补位成为新的 leader.
2follower 成为 candidate 后,会广播向所有节点拉票当投赞同票的节点数包括candidate 本身达到多数派的时候该 candidate 会胜任成为新的 leader.任期与日志索引 二元组
1term标志了这则日志是哪个任期的 leader 在位时同步写入的2index标志了这则日志在预写日志数组的位置.raft 算法下节点的角色流转
1.角色切换
1leader - follower倘若 leader 发现当前系统中出现了更大的任期则会进行“禅让”主动退位成 follower.leader如何探测到更大任期
I 向 follower 提交日志同步请求时,从 follower 的响应参数中获得;
II 收到了来自新任 leader 的心跳或者同步日志请求III 收到了任期更大的 candidate 的拉票请求.2follower - candidateleader 需要定期向 follower 发送心跳告知自己仍健在的消息.倘若 follower 超过一定时长没收到 leader 心跳时会将状态切换为 candidate 在当前任期的基础上加 1 作为竞选任期发起竞选尝试补位.
3candidate - followerI 多数派投了反对票(忽略不投票)II 竞选期间收到了任期大于等于自身竞选任期的 leader 传来的请求.4candidate - leadercandidate 竞选时倘若多数派投了赞同票则切换为 leader.5candidate - candidatecandidate 的竞选流程有一个时间阈值. 倘若超时仍未形成有效结论多数派赞同或拒绝则会 维 持 candidate 身份将竞选任期加1发起新一轮竞选.
1.2 领导者
领导者是写请求的统一入口在接收到来自客户端的写请求时会开启“两阶段提交”
leader 还需要周期性地向集群中所有节点发送自己的心跳告知自己的健康状况
1让 follower 重置心跳检测定时器避免其切换成 candidate 发起竞选2在心跳请求中携带上 leader 最新已提交日志的标识 idterm index推动 follower 更新日志提交进度.
心跳请求是单向传输而非双向通信. 因此follower 无需对 leader 的心跳请求进行回复.1.3 跟随者
follower 的职责包括如下几项1负责同步 leader 传来的写请求此时也有一个参与民主反馈的过程倘若同步成功会给予 leader 正向反馈当 leader 的同步请求收到半数以上的认可时会提交日志2通过接收 leader 心跳的方式获取到携带的 commitIndex 信息及时完成已被多数派认可的预写日志的提交以推进其写入状态机的进度. 这一项相当于做到了数据的备份也被读请求最终一致性提供了保证;3负责为参与竞选 candidate 的投票决定赞同与否的判断机制见 5.3 小节4通过心跳检测定时器时时关注 leader 的健康状态当超时未收到心跳时会切换为 candidate 发起竞选.1.4 候选人
candidate 是一个临时态成为 candidate 意味着此时正处于成与败的分叉路口candidate 有关的核心流程如下1倘若 follower 切为 candidate会将当前任期加1作为竞选任期2会将自身的一票投给自己3广播向所有节点拉票4倘若拉票请求超时前得到多数派认可则上位为 leader5倘若拉票请求超时前遭到多数派拒绝则老实退回 follower6倘若拉票请求超时前收到了任期大于等于自身竞选任期的 leader 的请求则老实退回 follower7倘若拉票请求超时则竞选任期加 1发起新一轮竞选拉票请求.参考 小徐先生万字长文解析raft算法原理
