日志完整性高的跟随者(也就是最后一条日志项对应的任期编号值更大,索引号更大),拒绝投票给日志完整性低的候选人。比如节点 B 的任期编号为 3,节点 C 的任期编号是 4,节点 B 的最后一条日志项对应的任期编号为 3,而节点 C 为 2,那么当节点 C 请求节点 B 投票给自己时,节点 B 将拒绝投票。
来自:07 | Raft算法(一):如何选举领导者?
13 人划过
本质上而言,提案编号的大小代表着优先级,你可以这么理解,根据提案编号的大小,接受者保证三个承诺,具体来说:如果准备请求的提案编号,小于等于接受者已经响应的准备请求的提案编号,那么接受者将承诺不响应这个准备请求;如果接受请求中的提案的提案编号,小于接受者已经响应的准备请求的提案编号,那么接受者将承诺不通过这个提案;如果接受者之前有通过提案,那么接受者将承诺,会在准备请求的响应中,包含已经通过的最大编号的提案信息。
来自:05 | Paxos算法(一):如何在多个节点间确定某变量的值?
11 人划过
不管旧的集群配置是怎么组成的,旧配置的“大多数”和新配置的“大多数”都会有一个节点是重叠的
来自:09 | Raft算法(三):如何解决成员变更的问题?
9 人划过
异步修复:这个是最常用的方式,通过定时对账检测副本数据的一致性,并修复
来自:04 | BASE理论:CAP的碱,追求可用性
7 人划过
需要注意的是,在第一个阶段,每个参与者投票表决事务是放弃还是提交。一旦参与者投票要求提交事务,那么就不允许放弃事务。也就是说,在一个参与者投票要求提交事务之前,它必须保证能够执行提交协议中它自己那一部分,即使参与者出现故障或者中途被替换掉。 这个特性,是我们需要在代码实现时保障的。
来自:03 | ACID理论:CAP的酸,追求一致性
7 人划过
DATA 节点保存的是具体的时序数据记录,比如一条记录 CPU 负载的时序数据,“cpu_usage,host=server01,location=cn-sz user=23.0,system=57.0”。虽然这些数据不是系统运行相关的元信息,但服务会被访问频繁,水平扩展、性能、可用性等是关键,所以,我选择了 CAP 理论中的 A 和 P,采用 AP 架构。
来自:02 | CAP理论:分布式系统的PH试纸,用它来测酸碱度
6 人划过
那么,齐和燕将按照一定规则(比如取中间的指令)在排序后的所有已接收到的指令中(比如撤退、进攻)中选取一个指令,进行执行,最终执行一致的作战计划。
来自:01 | 拜占庭将军问题:有叛徒的情况下,如何才能达成共识?
6 人划过
按照顺序将提案广播到其他节点。
来自:15 | ZAB协议:如何实现操作的顺序性?
5 人划过
假设有这样一个场景,一个存储系统,访问它的写请求不多(比如 1K QPS),但访问它的读请求很多(比如 1M QPS),而且客户端查询时,对数据的一致性敏感,也就是需要实现强一致性,那么我们该如何设计这个系统呢?
来自:16 | InfluxDB企业版一致性实现剖析:他山之石,可以攻玉
4 人划过
如果一个人想真正搞懂分布式技术,开发出一个分布式系统,最先需要掌握的就是这部分知识。
来自:开篇词 | 想成为分布式高手?那就先把协议和算法烂熟于心吧
3 人划过
*精彩内容为该课程各文章中划线次数最多的内容
编辑推荐
包含这门课的学习路径
分布式工程师
8门课程 48.5w人学习
看过的人还看了