Distributed_事务_共识(主从复制共识问题)

1.共识问题

1. 共识问题的形式化描述:一个或多个节点可以提议某些值，由共识算法来决定最终值。

2. 共识算法的性质:

   1. 协商一致性(Uniform Agreement)(所有的节点接收相同的决议)；

   2. 诚实性(Integrity):所有节点不能反悔自己接收的决议即不能对提议进行二次决定；

   3. 合法性(Validity):如果决定了值v，则v一定是由某个节点所提议的。

   4. 可终止性(Termination):由所有未崩溃的节点来最终决定值。

      前三个属性提供了安全性，最后一个属性提供了容错。

      **对于不考虑拜占庭式错误的共识算法，则可终止性的前提:**出现错误的节点数应该是少于总节点数的1/2

      对于考虑拜占庭式错误的共识算法，则可终止性的前提: 出现错误的节点数应该是少于总节点数的1/3

3. 实际中的共识协议:

   实际共识协议是决定一系列的值，然后采用全序关系广播算法，相当于进行了多轮共识过程：在每轮中，节点提出他们接下来想要发送的消息，然后决定下一轮消息的全局顺序。比如区块链中的POW,POS等等

2. 主从复制中的共识协议

这里的主从复制是指存在主节点和从节点之分，但是主节点并不是固定的，是需要选举产生的。

1. 基本问题:所有的写入操作都由主节点负责**(换句话说主节点具有提案权)**，并以相同的顺序发送到从节点来保持副本更新。其中主节点选举过程则是一个共识的问题?写入操作的顺序也是一个共识问题？

2.1 Epoch和Quorum

1. 协议里定义一个世代编号(epoch number)并保证在每个世代里，主节点是唯一确定的。(每轮中的主节点都有一个世代编号的属性epoch number)

2. 进入一个新世代epoch的条件:如果发现当前的主节点失效，节点就开始一轮投票选举新的主节点。

   问题：如果一个世代里出现了两个主节点(主节点A的epoch number>主节点B的epoch number)，则具有更高的epoch number的主节点将获胜。

3. 在主节点做出任何决定之前，它必须首先检查是否存在比它更高的epoch号码，否则就会产生冲突的决定。主节点如何知道它是否已被其他节点所取代了呢？

   解决方案:

   ​ 主节点在做出任何决定之前，会将自己的提案(附加epoch number)发送到所有其他节点，等候quorum节点(通常quorum设置为多数节点即(n+1)/2个节点)响应，其他节点只有当没有发现epoch number大于接收到提案的epoch number的主节点时，对该提案进行投票。

   ​ 由于每个提案上的epoch number与提案的主节点epoch number一致，所以当主节点接收到提案上的epoch number大于自身的epoch number则认为自己被其他节点所取代。

   ​ 当其他节点收到epoch number不同的提案时，只会对epoch number较大的提案投票.

2.2 共识算法和2PC的区别(共识算法设计角度)

1. 2PC的协调者并不是依靠选举产生的。

2. 容错共识算法只需要收到多数节点的投票结果即可通过决议，而2PC则要求每个参与者都必须做出“是”才能最终通过。

   如何选举主节点?

3. 共识算法还定义了恢复过程，出现故障之后，通过该过程节点可以选举出新的主节点然后进入一致的状态。

   当主节点宕机，如何重新选举新的主节点？

   当其余节点宕机，如何恢复一致性？

2.3 共识算法的缺陷

1. 多数共识算法假定一组固定参与投票的节点集,这意味着不能动态添加或删除节点。
2. 共识系统通常依靠超时机制来检测节点失效。
3. 共识算法对网络问题特别敏感。

4.知识、真相与谎言

1.总结

​ 探讨分布式系统中的知识和真相，做出合理的假设，以及可以做出哪些保证。

2. 真相由多数决定

​ 分布式系统设计原则:节点不能根据自己的信息来判断自身的状态。由于节点可能随时会失效，可能会暂停-假死，甚至最终无法恢复，因此，**分布式系统中不能依赖于单个节点。**目前，许多分布式算法都依靠法定票数，即在节点之间进行投票。任何决策都需要来自多个节点的最小投票数，从而减少对特定节点的依赖。

3.拜占庭式容错系统

​ 如果某个系统中即使发生部分节点故障，甚至不遵从协议，或者恶意攻击、干扰网络，但仍可继续正常运行，那么我们称之为拜占庭式容错系统。

适用范围:

​ 在去中心化的点对点网络中，拜占庭容错共识协议显得尤为重要。