Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenDocCN
blockchain_guide
提交
2974096c
B
blockchain_guide
项目概览
OpenDocCN
/
blockchain_guide
通知
0
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
B
blockchain_guide
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
2974096c
编写于
9月 03, 2016
作者:
Y
yeasy
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Updates consensus paxos content
上级
c8110582
变更
1
显示空白变更内容
内联
并排
Showing
1 changed file
with
26 addition
and
15 deletion
+26
-15
consensus/paxos.md
consensus/paxos.md
+26
-15
未找到文件。
consensus/paxos.md
浏览文件 @
2974096c
## Paxos 与 Raft
Paxos 问题是指分布式的系统中存在故障
,但不存在恶意节点(无伪造消息,但可能丢失或重复
)场景下的一致性问题。因为最早是 Leslie Lamport 用 Paxon 岛的故事模型来进行描述而命名。
Paxos 问题是指分布式的系统中存在故障
(fault),但不存在恶意(corrupt)节点(可能响应、消息丢失或重复,但无错误消息
)场景下的一致性问题。因为最早是 Leslie Lamport 用 Paxon 岛的故事模型来进行描述而命名。
### Paxos
1990 年由 Leslie Lamport 提出的
[
Paxos
](
http://research.microsoft.com/users/lamport/pubs/lamport-paxos.pdf
)
一致性算法,在工程角度实现了一种最大化保障一致性(存在极小的概率无法实现一致性)的机制。Paxos 被广泛应用在 Chubby、ZooKeeper 这样的系统中,Leslie Lamport 因此获得了 2013 年度图灵奖。
1990 年由 Leslie Lamport 提出的
[
Paxos
](
http://research.microsoft.com/users/lamport/pubs/lamport-paxos.pdf
)
一致性算法,在工程角度实现了一种最大化保障
分布式系统
一致性(存在极小的概率无法实现一致性)的机制。Paxos 被广泛应用在 Chubby、ZooKeeper 这样的系统中,Leslie Lamport 因此获得了 2013 年度图灵奖。
故事背景是古希腊 Paxon 岛上的多个法官在一个大厅内对一个议案进行表决,如何达成统一的结果。他们之间通过服务人员来传递纸条,但法官可能离开或进入大厅,服务人员可能偷懒去睡觉。
...
...
@@ -12,15 +12,15 @@ Paxos 是第一个被证明的一致性算法,其原理基于 [两阶段提交
作为现在一致性算法设计的鼻祖,以最初论文的难懂(算法本身并不复杂)出名。算法中将节点分为三种类型:
*
proposer:提出一个提案,等待大家批准为结案;
*
acceptor:负责对提案进行投票;
*
learner:被告知结案结果,并与之统一,不参与投票过程。
*
proposer:提出一个提案,等待大家批准为结案
。往往是客户端担任该角色
;
*
acceptor:负责对提案进行投票
。往往是服务端担任该角色
;
*
learner:被告知结案结果,并与之统一,不参与投票过程。
可能为客户端或服务端。
并满足三点约束要求:
*
决议(value)只有在被 proposers 提出的 proposal 才能被最终批准;
*
在一次执行实例中,只批准(chosen)一个最终决议,意味着多数接受(accept)的结果能成为决议;
*
l
earners 只
能获得被批准(chosen)的决议。
*
safety I:
决议(value)只有在被 proposers 提出的 proposal 才能被最终批准;
*
safety II:
在一次执行实例中,只批准(chosen)一个最终决议,意味着多数接受(accept)的结果能成为决议;
*
l
iveness:决议总会产生,并且 learners
能获得被批准(chosen)的决议。
基本过程包括 proposer 提出提案,先争取大多数 acceptor 的支持,超过一半支持时,则发送结案结果给所有人进行确认。一个潜在的问题是 proposer 在此过程中出现故障,可以通过超时机制来解决。极为凑巧的情况下,每次新的一轮提案的 proposer 都恰好故障,系统则永远无法达成一致(概率很小)。
...
...
@@ -28,19 +28,30 @@ Paxos 能保证在超过一半的正常节点存在时,系统能达成一致
读者可以试着自己设计一套能达成一致性的方案,会发现在满足各种约束情况下,算法自然就会那样设计。
#### 单个提案者
如果系统中限定只有某个特定节点是提案者,那么一致性肯定能达成(只有一个方案,要么达成,要么失败)。
#### 单个提案者
+多接收者
如果系统中限定只有某个特定节点是提案者,那么一致性肯定能达成(只有一个方案,要么达成,要么失败)。
提案者只要收到了来自多数接收者的投票,即可认为通过,因为系统中不存在其他的提案。
但一旦提案者故障,则系统无法工作。
#### 多个提案者
问题一下子变得复杂了
。
#### 多个提案者
+单个接收者
限定某个节点作为接收者。这种情况下,一致性也很容易达成,接收者收到多个提案,选第一个提案作为决议,拒绝掉后续的提案即可
。
一种情况是同一时间片段(如一个提案周期)内只有一个提案者。这需要设计一种机制来保障提案者的正确产生,例如按照时间、序列、或者大家猜拳(出一个数字来比较)之类。考虑到分布式系统要处理的工作量很大,这个过程要尽量高效,满足这一条件的机制非常难设计
。
缺陷也是容易发生单点故障,包括接收者故障或首个提案者节点故障
。
另一种情况是允许同一时间片段内可以出现两个提案者。那同一个节点可能收到两份提案,怎么对他们进行区分呢?很自然的,提案需要带上不同的序号。节点需要根据提案序号来判断接受哪个。比如接受其中序号较大(往往意味着是接受新提出的,因为旧提案者故障概率更大)的提案
。
以上两种情形其实类似主从模式,虽然不那么可靠,但因为原理简单而被广泛采用
。
如何为提案分配序号呢?一种可能方案是每个节点的提案数字区间彼此隔离开,互相不冲突。为了满足递增的需求可以配合用时间戳作为高位字段。
当提案者和接收者都推广到多个的情形,会出现一些挑战。
#### 多个提案者+多个接收者
既然限定单提案者或单接收者都会出现故障,那么就得允许出现多个提案者和多个接收者。问题一下子变得复杂了。
一种情况是同一时间片段(如一个提案周期)内只有一个提案者,这时可以退化到单提案者的情形。需要设计一种机制来保障提案者的正确产生,例如按照时间、序列、或者大家猜拳(出一个数字来比较)之类。考虑到分布式系统要处理的工作量很大,这个过程要尽量高效,满足这一条件的机制非常难设计。
另一种情况是允许同一时间片段内可以出现多个提案者。那同一个节点可能收到多份提案,怎么对他们进行区分呢?这个时候采用只接受第一个提案而拒绝后续提案的方法也不适用。很自然的,提案需要带上不同的序号。节点需要根据提案序号来判断接受哪个。比如接受其中序号较大(往往意味着是接受新提出的,因为旧提案者故障概率更大)的提案。
如何为提案分配序号呢?一种可能方案是每个节点的提案数字区间彼此隔离开,互相不冲突。为了满足递增的需求可以配合用时间戳作为前缀字段。
此外,提案者即便收到了多数接收者的投票,也不敢说就一定通过。因为在此过程中系统中其它提案者
#### 两阶段的提交
提案者发出提案之后,收到一些反馈。这个时候得知的一种结果是自己的提案被大多数接受了,一种结果是没被接受。没被接受的话好说,过会再试试。
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录