Refactor: explain algo to determine apply order without SCC in mmp3

Author: drmingdrmer

_posts/2021-06-14-mmp3.md

@@ -49,7 +49,7 @@ excerpt: "小孩子才选master, 成年人只用multi-master"
 -   任一节点都可写,
 -   任一笔写入都可以严格在1个 RTT 内完成.
 
-这就是今天要介绍的 
+这就是今天要介绍的
 [200行代码实现paxos-kv](https://zhuanlan.zhihu.com/p/275710507)
 的改进版: mmp-3: multi-master-paxos 3副本实现.
 
@@ -122,11 +122,11 @@ replica-0 上的 proposer P0, 顺次完成 phase-1, phase-2 和 commit:
 
 因为 proposer 本身只是一个数据结构, 在 paxos 中, 它不需要跟 acceptor 有什么绑定关系,
 所以, 我们可以**让 proposer 运行在任何一个 replica 上**:
-把 proposer 发到另一个 replica 上运行, 
+把 proposer 发到另一个 replica 上运行,
 这样消息的传输就可以转变成 proposer 的传输.
 
 要达到 paxos 要求的 2/3的多数派,
-也只需要将 proposer 发到另外一个 replica, 
+也只需要将 proposer 发到另外一个 replica,
 因为这个 proposer 永远只有1个实例, 所以不会出现不一致(proposer 或者在R0上工作或者在在R1上工作).
 
 > 如果要将 proposer 发到 2个 replica 就会复杂一些, 例如5节点中 quorum=3, 2个不同的 proposer
@@ -241,7 +241,7 @@ message Ins {
 ![](/post-res/mmp3/digraphseensize=55dpi=100layout=-f7876b9a4c1e4ba8.jpg)
 
 > classic-paxos 中要求 prepare 阶段看到的已存在的值要使用,
-> 而 mmp3 中将所有 prepare 阶段看到的 `Deps` 的值做了并集, 
+> 而 mmp3 中将所有 prepare 阶段看到的 `Deps` 的值做了并集,
 > 实际上并没有破坏 paxos 的约束,
 > 只不过 classic-paxos 假设它的**值**是任意的, 不一定可取并集,
 > mmp3 中可以把 prepare 过程中看到的 `Deps` 的值认为是 `VBal` 为 0 的一个值,
@@ -322,7 +322,7 @@ interfering 的 instance 的冲突带来的另一个RTT开销.
 那么 `B.Deps`, 也就是 B 看到的所有其他 instance 的 id 集合, 就已经复制到了某个 quorum.
 那么 A 在运行 paxos 的时候,一定会看到 B commit 的 `B.Deps` 的值.
 
-又因为 `A.Deps` 是2个在 prepare 阶段看到的 `Deps`的值的并集, 
+又因为 `A.Deps` 是2个在 prepare 阶段看到的 `Deps`的值的并集,
 因此 `A.Deps` 一定包含全部 `B.Deps` 的instance.
 
 于是实现 apply 算法的思路就是:
@@ -349,20 +349,31 @@ interfering 的 instance 的冲突带来的另一个RTT开销.
 
 ## Lemma-2: 不需要 SCC
 
-第2个小结论:
+我们不需要遍历出所有的 Strongly-Connected-Component(SCC),
+就可以确定 Apply 的顺序.
 
-**如果 A, B不属于同一个 SCC, 即, A ∈ SCC₁ B ∉ SCC₁, 那么**:
+我们的第2个小结论是:
+
+**如果 A, B不属于同一个 SCC, 即, A ∈ SCC₁ 且 B ∉ SCC₁,
+那么一定有且只有下面其中一种情况成立**:
 
 -   **A → B ⇒ A.Deps ⊃ B.Deps**.
 -   **B → A ⇒ B.Deps ⊃ A.Deps**.
 
-因为根据 Lemma-0,
-任意2个 instance 至少有一个依赖关系,
-如果X ∈ B.Deps 且 X ∉ A.Deps,
-那么必然有 X → A, 导致 A → B → X → A 成为一个SCC.
+即, 如果 A 依赖 B, 则 A 的依赖集合一定是 B 的依赖集合的超集.
+
+简单的证明如下:
+
+以 A → B 的情况举例,
+假设有一个 X 在 B 的依赖集里但不在A的依赖集里, 即: X ∈ B.Deps 且 X ∉ A.Deps,
+那么根据 Lemma-0(任意2个 instance 至少有一个依赖关系),
+必然有 X → A, 导致 A → B → X → A 成为一个 SCC, 这跟假设矛盾.
+
+QED
 
-因此, **不论A, B是否在一个 SCC 中, 保证 Linearizability
-的条件都可以用 Deps 来确定, 
+因此, **不论 A, B 是否在一个 SCC 中, 保证 Linearizability
+的条件都可以用 Deps 来确定,
+即只需保证 Deps 的子集关系决定 Apply 的先后关系集合.
 所以我们的算法不必寻找 SCC , 只需遍历依赖关系**.
 
 ## 减小遍历数量: 只需考虑最老的 instance

_src/mmp3/2021-06-14-mmp3.md

@@ -48,7 +48,7 @@ excerpt: "小孩子才选master, 成年人只用multi-master"
 - 任一节点都可写,
 - 任一笔写入都可以严格在1个 RTT 内完成.
 
-这就是今天要介绍的 
+这就是今天要介绍的
 [200行代码实现paxos-kv][post-paxoskv]
 的改进版: mmp-3: multi-master-paxos 3副本实现.
 
@@ -145,11 +145,11 @@ sequenceDiagram
 
 因为 proposer 本身只是一个数据结构, 在 paxos 中, 它不需要跟 acceptor 有什么绑定关系,
 所以, 我们可以**让 proposer 运行在任何一个 replica 上**:
-把 proposer 发到另一个 replica 上运行, 
+把 proposer 发到另一个 replica 上运行,
 这样消息的传输就可以转变成 proposer 的传输.
 
 要达到 paxos 要求的 2/3的多数派,
-也只需要将 proposer 发到另外一个 replica, 
+也只需要将 proposer 发到另外一个 replica,
 因为这个 proposer 永远只有1个实例, 所以不会出现不一致(proposer 或者在R0上工作或者在在R1上工作).
 
 > 如果要将 proposer 发到 2个 replica 就会复杂一些, 例如5节点中 quorum=3, 2个不同的 proposer
@@ -524,7 +524,7 @@ digraph seen
 ```
 
 > classic-paxos 中要求 prepare 阶段看到的已存在的值要使用,
-> 而 mmp3 中将所有 prepare 阶段看到的 `Deps` 的值做了并集, 
+> 而 mmp3 中将所有 prepare 阶段看到的 `Deps` 的值做了并集,
 > 实际上并没有破坏 paxos 的约束,
 > 只不过 classic-paxos 假设它的**值**是任意的, 不一定可取并集,
 > mmp3 中可以把 prepare 过程中看到的 `Deps` 的值认为是 `VBal` 为 0 的一个值,
@@ -586,7 +586,7 @@ interfering 的 instance 的冲突带来的另一个RTT开销.
 > - R1 send b1 to R0, b1.Deps = [1, 1, 0]
 > - R0 commit a1
 > - R1 commit b1
-> 
+>
 > 这样 a1 ∈ b1.Deps 且 b1 ∈ a1.Deps
 
 依赖关系很直观, 这个依赖关系的图中,
@@ -603,7 +603,7 @@ interfering 的 instance 的冲突带来的另一个RTT开销.
 那么 `B.Deps`, 也就是 B 看到的所有其他 instance 的 id 集合, 就已经复制到了某个 quorum.
 那么 A 在运行 paxos 的时候,一定会看到 B commit 的 `B.Deps` 的值.
 
-又因为 `A.Deps` 是2个在 prepare 阶段看到的 `Deps`的值的并集, 
+又因为 `A.Deps` 是2个在 prepare 阶段看到的 `Deps`的值的并集,
 因此 `A.Deps` 一定包含全部 `B.Deps` 的instance.
 
 
@@ -632,19 +632,30 @@ interfering 的 instance 的冲突带来的另一个RTT开销.
 
 ## Lemma-2: 不需要 SCC
 
-第2个小结论:
+我们不需要遍历出所有的 Strongly-Connected-Component(SCC),
+就可以确定 Apply 的顺序.
+
+我们的第2个小结论是:
 
-**如果 A, B不属于同一个 SCC, 即, A ∈ SCC₁ B ∉ SCC₁, 那么**:
+**如果 A, B不属于同一个 SCC, 即, A ∈ SCC₁ 且 B ∉ SCC₁,
+那么一定有且只有下面其中一种情况成立**:
 - **A → B ⇒ A.Deps ⊃ B.Deps**.
 - **B → A ⇒ B.Deps ⊃ A.Deps**.
 
-因为根据 Lemma-0,
-任意2个 instance 至少有一个依赖关系,
-如果X ∈ B.Deps 且 X ∉ A.Deps,
-那么必然有 X → A, 导致 A → B → X → A 成为一个SCC.
+即, 如果 A 依赖 B, 则 A 的依赖集合一定是 B 的依赖集合的超集.
+
+简单的证明如下:
+
+以 A → B 的情况举例,
+假设有一个 X 在 B 的依赖集里但不在A的依赖集里, 即: X ∈ B.Deps 且 X ∉ A.Deps,
+那么根据 Lemma-0(任意2个 instance 至少有一个依赖关系),
+必然有 X → A, 导致 A → B → X → A 成为一个 SCC, 这跟假设矛盾.
+
+QED
 
-因此, **不论A, B是否在一个 SCC 中, 保证 Linearizability
-的条件都可以用 Deps 来确定, 
+因此, **不论 A, B 是否在一个 SCC 中, 保证 Linearizability
+的条件都可以用 Deps 来确定,
+即只需保证 Deps 的子集关系决定 Apply 的先后关系集合.
 所以我们的算法不必寻找 SCC , 只需遍历依赖关系**.