Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
wushizhenking
CS-Notes
提交
bc62b966
C
CS-Notes
项目概览
wushizhenking
/
CS-Notes
与 Fork 源项目一致
从无法访问的项目Fork
通知
2
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
C
CS-Notes
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
bc62b966
编写于
11月 18, 2018
作者:
L
linkwk7
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
修改分布式部分中部分描述不准确的地方,修改Paxos部分描述
上级
c2056915
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
8 addition
and
26 deletion
+8
-26
notes/分布式.md
notes/分布式.md
+8
-26
未找到文件。
notes/分布式.md
浏览文件 @
bc62b966
...
...
@@ -173,7 +173,7 @@ Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父
网络分区指分布式系统中的节点被划分为多个区域,每个区域内部可以通信,但是区域之间无法通信。
在分区容忍性条件下,分布式系统在遇到任何网络分区故障的时候,仍然需要能对外提供
一致性和可用性的
服务,除非是整个网络环境都发生了故障。
在分区容忍性条件下,分布式系统在遇到任何网络分区故障的时候,仍然需要能对外提供服务,除非是整个网络环境都发生了故障。
## 权衡
...
...
@@ -181,7 +181,7 @@ Zookeeper 提供了一种树形结构级的命名空间,/app1/p_1 节点的父
可用性和一致性往往是冲突的,很难使它们同时满足。在多个节点之间进行数据同步时,
-
为了保证一致性(CP),
就需要让所有节点下线成为不可用的状态,等待同步完成
;
-
为了保证一致性(CP),
需要牺牲部分节点的可用性(即部分节点虽仍正常工作但不会响应用户请求),但保证读出的数据一定是具有强一致性的
;
-
为了保证可用性(AP),在同步过程中允许读取所有节点的数据,但是数据可能不一致。
<div
align=
"center"
>
<img
src=
"../pics//0b587744-c0a8-46f2-8d72-e8f070d67b4b.jpg"
/>
</div><br>
...
...
@@ -226,35 +226,17 @@ ACID 要求强一致性,通常运用在传统的数据库系统上。而 BASE
## 执行过程
规定一个提议包含
两个字段:[n, v],其中 n 为序号(具有唯一性),v 为提议值
。
规定一个提议包含
一个提议序号 n,其中序号具有唯一性
。
下图演示了两个 Proposer 和三个 Acceptor 的系统中运行该算法的初始过程,每个 Proposer 都会向所有 Acceptor 发送提议请求
。
当 Acceptor 接收到一个Prepare请求,包含的提议序号为 n1 ,并且之前还未接收过Prepare请求,那么发送一个响应,设置当前接收到的提议为 n1 ,并且保证以后不会再接受序号小于 n1 的提议
。
<div
align=
"center"
>
<img
src=
"../pics//1a9977e4-2f5c-49a6-aec9-f3027c9f46a7.png"
/>
</div><br>
如果 Acceptor 接收到一个Prepare请求,其包含的提议号为 n2,如果 n2 大于其之前响应的所有的 Prepare 消息所附带的提议号,并且大于其之前响应的所有 Accept 消息所附带的提议号,则发送响应消息,并在响应消息中附带上其已经 Accept 过的提议,并保证不再接受序号小于 n2 的消息。
当
Acceptor 接收到一个提议请求,包含的提议为 [n1, v1],并且之前还未接收过提议请求,那么发送一个提议响应,设置当前接收到的提议为 [n1, v1],并且保证以后不会再接受序号小于 n1 的提议
。
当
一个 Proposer 接收到超过一半 Acceptor 的 Prepare 响应时,就可以发送 Accept 请求。Accept 请求包括 Prepare 阶段使用的提议号以及提议值,如果 Prepare阶段没有 Acceptor 回应任何已经 Accept 的值则该 Proposer 可以自己选择一个,否则使用 Prepare 阶段中所有收到的值中提议序号最高的一个
。
如下图,Acceptor X 在收到 [n=2, v=8] 的提议请求时,由于之前没有接收过提议,因此就发送一个 [no previous] 的提议响应,设置当前接收到的提议为 [n=2, v=8],并且保证以后不会再接受序号小于 2 的提议。其它的 Acceptor 类似
。
Acceptor 收到 Accept 请求后,如果该请求中的提议序号大于等于其已经 Accept 或者在 Prepare 阶段收到的提议的序号,则接受该值。否则丢弃该消息
。
<div
align=
"center"
>
<img
src=
"../pics//fb44307f-8e98-4ff7-a918-31dacfa564b4.jpg"
/>
</div><br>
如果 Acceptor 接收到一个提议请求,包含的提议为 [n2, v2],并且之前已经接收过提议 [n1, v1]。如果 n1 > n2,那么就丢弃该提议请求;否则,发送提议响应,该提议响应包含之前已经接收过的提议 [n1, v1],设置当前接收到的提议为 [n2, v2],并且保证以后不会再接受序号小于 n2 的提议。
如下图,Acceptor Z 收到 Proposer A 发来的 [n=2, v=8] 的提议请求,由于之前已经接收过 [n=4, v=5] 的提议,并且 n > 2,因此就抛弃该提议请求;Acceptor X 收到 Proposer B 发来的 [n=4, v=5] 的提议请求,因为之前接收到的提议为 [n=2, v=8],并且 2 <= 4,因此就发送 [n=2, v=8] 的提议响应,设置当前接收到的提议为 [n=4, v=5],并且保证以后不会再接受序号小于 4 的提议。Acceptor Y 类似。
<div
align=
"center"
>
<img
src=
"../pics//2bcc58ad-bf7f-485c-89b5-e7cafc211ce2.jpg"
/>
</div><br>
当一个 Proposer 接收到超过一半 Acceptor 的提议响应时,就可以发送接受请求。
Proposer A 接收到两个提议响应之后,就发送 [n=2, v=8] 接受请求。该接受请求会被所有 Acceptor 丢弃,因为此时所有 Acceptor 都保证不接受序号小于 4 的提议。
Proposer B 过后也收到了两个提议响应,因此也开始发送接受请求。需要注意的是,接受请求的 v 需要取它收到的最大 v 值,也就是 8。因此它发送 [n=4, v=8] 的接受请求。
<div
align=
"center"
>
<img
src=
"../pics//9b838aee-0996-44a5-9b0f-3d1e3e2f5100.png"
/>
</div><br>
Acceptor 接收到接受请求时,如果序号大于等于该 Acceptor 承诺的最小序号,那么就发送通知给所有的 Learner。当 Learner 发现有大多数的 Acceptor 接收了某个提议,那么该提议的提议值就被 Paxos 选择出来。
<div
align=
"center"
>
<img
src=
"../pics//bf667594-bb4b-4634-bf9b-0596a45415ba.jpg"
/>
</div><br>
Acceptor 接收到 Accept 请求时,如果序号大于等于该 Acceptor 承诺的最小序号,那么就发送通知给所有的 Learner。当 Learner 发现有大多数的 Acceptor 接收了某个提议,那么该提议的提议值就被 Paxos 选择出来。
## 约束条件
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录