区块链笔记(三)分布式系统核心技术

目录

一、一致性问题

1、定义

2、挑战

3、一致性的要求

4、带约束的一致性

二、共识算法

1、问题与挑战

2、常见算法


区块链系统是一个典型的分布式系统,必然会存在分布式架构面临的问题与挑战,涉及一致性、共识等方面。

一、一致性问题

随着业务场景越来越复杂,计算规模越来越庞大,单点系统很难满足可拓展性和高容错两方面的需求,此时就需要多台服务器组成集群系统,但集群系统要实现一致性绝非易事。

1、定义

一致性(consistency)在分布式系统领域指的是对于多个服务节点,给定一系列操作,在约定协议的保障下,使得它们对处理结果达成“某种程度”的协同。

传统分布式系统中讨论一致性,往往是指在外部任意发起请求(如向多个节点发送不同请求)的情况下,确保系统内的大部分节点实际处理请求序列的一致,即对请求进行全局排序。

一致性关注的是系统呈现的状态,并不关注结果是否正确。

2、挑战

  • 节点完成请求的时间无法保障,处理结果可能是错误的,节点甚至可能随时发生故障
  • 为了实现可拓展性,集群系统往往采用异步设计,依靠网络消息交互,这意味着不可预测的通信延迟、丢失或错误

现代分布式系统处理一致性问题的基础思路中的核心思想,都是将可能引发不一致的并行操作进行串行化。

3、一致性的要求

  • 可终止性(termination),指一致的结果在有限时间内能完成。意味着可以保障提供服务(liveness),这是计算机系统可以被正确使用的前提。
  • 约同性(agreement),指不同的节点最终完成的决策的结果是相同的。这看似容易,实际上暗含了一些潜在信息,决策的结果相同,意味着算法要么不给出结果,要么给出的结果是已经达成共识的。真正的挑战在于算法要考虑可能出现的任意情形。其中,事件发生的先后顺序(逻辑时钟)十分重要,确定了顺序,就可以消除分歧,因此解决分布式系统领域许多问题的核心秘诀就是:把不同时空发生的多个事件进行全局唯一排序,而且这个顺序是大家认可的。然而,计算机系统的时钟误差比较大,不能够据此来进行排序,这就造成了分布式系统中达成一致顺序非常困难。
  • 合法性(validity),指决策的结果必须是某个节点提出的提案,即达成的结果必须是节点执行操作的结果。

4、带约束的一致性

实际上,越强的一致性要求往往意味着越弱的处理性能,以及越差的可拓展性。根据实际需求的不同,可以选择不同强度的一致性,包括强一致性(strong consistency)和弱一致性(weak consistency)。

强一致性主要包括:

  • 顺序一致性(sequential consistency),又叫因果一致性。所有的进程看到的全局执行顺序(total order)一致(否则数据副本不一致);并且每个进程看自身操作的顺序(local order)跟实际发生顺序一致。它实际上限制了各进程内指令的偏序关系,但不在进程间按照物理时间进行全局排序,属于实践中可行的最强保证。
  • 线性一致性(linearizability consistency),是一种更强的保证,在顺序一致性的前提下加强了进程间的操作排序,形成理想化的全局顺序,性能差。

强一致性往往比较难实现,且很多场景对于一致性的需求没有那么强。例如在一定约束下实现所谓的最终一致性(eventual consistency),即总会存在一个时刻,让系统达到一致的状态。这种在某些方面弱化的一致性都笼统的称为弱一致性。

 

二、共识算法

共识算法解决的是分布式系统中大部分节点对于某个提案(proposal)达成一致的过程,而一致性在分布式系统领域中指的是多个副本对外呈现的状态。因此,达成了某种共识并不意味着就保障了一致性。实践中,要保障系统满足不同程度的一致性,往往需要通过共识算法来达成。

提案可以指多个事件发生的顺序、某个键对应的值、主节点的选取等,其含义非常宽泛。

1、问题与挑战

达成共识需要解决两个基本问题:

  • 如何提出一个待共识的提案?
  • 如何让多个节点对该提案达成共识?

实际情况中,不同节点之间存在通信延迟,任意环节都可能存在故障,如网络通信中断、节点故障、信息伪造等。

通常,把出现故障(crash或fail-stop,即不响应)但不会伪造信息的情况称为“非拜占庭错误(non-byzantine fault)”或“故障错误(crash fault)”;伪造信息响应的情况称为“拜占庭错误(byzantine fault)”,对应节点为拜占庭节点。

当存在一定信任的前提下(如介入节点可信、节点性能稳定等),达成共识相对容易,共识性能越高;反之,在不可信的场景下,达成共识的成本较高,性能也较差。

2、常见算法

根据解决的场景是否允许拜占庭错误情况,共识算法可以分为 Crash Fault Tolerance (CFT) 和 Byzantine Fault Tolerance(BFT)两类。

对于非拜占庭错误的情况,已经存在不少经典的算法,包括 Paxos(1990 年)、Raft(2014 年)及其变种等。这类容错算法往往性能比较好,处理较快,容忍不超过一半的故障节点。

对于要能容忍拜占庭错误的情况,包括 PBFT(Practical Byzantine Fault Tolerance,1999 年)为代表的确定性系列算法、PoW(1997 年)为代表的概率算法等。确定性算法一旦达成共识就不可逆转,即共识是最终结果;而概率类算法的共识结果则是临时的,随着时间推移或某种强化,共识结果被推翻的概率越来越小,最终成为事实上结果。拜占庭类容错算法往往性能较差,容忍不超过 1/3 的故障节点。

此外,XFT(Cross Fault Tolerance,2015 年)等最近提出的改进算法可以提供类似 CFT 的处理响应速度,并能在大多数节点正常工作时提供 BFT 保障。

Algorand 算法(2017 年)基于 PBFT 进行改进,通过引入可验证随机函数解决了提案选择的问题,理论上可以在容忍拜占庭错误的前提下实现更好的性能(1000+ TPS)。

你可能感兴趣的:(区块链学习,区块链)