分布式系统指南

栏目: 后端 · 发布时间: 6年前

分布式系统指南

Unitimes 2018-10-23 21:00 发布在 306

对于刚进入区块链领域的人来说,往往会对区块链技术感到非常困惑。理解该技术实际上相当简单的,但需要了解一些适当的背景知识。此外,大多数人其实并不需要真正了解区块链的具体内部运作方式, 而只需了解一些背景知识和指南 。在这篇文章中,我将简要介绍分布式系统(Distributed System),讨论各种共识协议、网络模型的类型以及其他一些相关的想法。对于想要了解这个领域的行业术语的人来说,这篇文章也可以算是一个指南,但我不会谈及太过晦涩难懂的细节内容。

01 时光倒流

分布式系统(Distributed Systems)是一个非常广泛的领域,为了便于理解,我将重点谈及该领域的共识方面。让我们把时间追溯到上世纪80年代。当时有一批非常聪明的计算机科学家正视图回答这一问题: 如何才能让一组机器就某条消息(message)达成一致呢? 我还是先来解释一下这个问题吧,因为这个问题似乎问得有点奇怪。假设你有一个数据库,可以用来存储一些非常重要的数据(比如银行需要存储的财务信息)。由于这些数据决不能丢失,因此你会即刻尝试在很多其他的机器上复制存储这些数据,这些机器分别是m0,m1...mn。这样一来,如果其中任何一台机器出故障了,你也不会担心找不回数据。为了搭建这个系统,我们可以采用最直观的方式,即: 将其中一台机器指定为“首领(leader)

如此一来,任何时候需要处理一笔新的客户交易时(如从Bob账户中扣除$10),leader机器将发出指令要求所有followers机器去执行这笔交易。这听起来很棒,可是我们会面临一个新的问题。

首先,如果leader机器m0发出指令要求m3机器从Bob的账户中扣除$10,但这条消息(message)发送失败了,并没有传递给m3,这怎么办呢?这真是很糟糕!我们无法再依靠m3机器来存储数据了, 因为现在m3机器上存储了与其他机器上不一致的数据(inconsistent data) 。要知道:不一致数据的出现就意味着,系统中有些机器中存储的数据与其他机器中存储的数据不一样,而它们本该是一样的!

02 确认消息

上述问题的一个基本解决方案是, 确保m3机器已经收到消息 。这就会涉及到了一个原子提交协议,即二阶段提交(2PC,Two-Phase-Commit)。之所以称之为原子提交协议,是因为这其中的理念是,如果需要提交事务(transaction),要么提交给系统中的所有机器,要么不提交给任何一台机器(...是的,我知道,这讲不太通)。想象一下: 机器m0并不会盲目地从客户端接收消息并将消息传递给其他机器,m0还会确保其他复制机在接收到消息之后会向m0确认自己已收到了该条消息 。这很有道理,但是如果其中的某机器(假设是m6)出故障了,而其他的机器已经从Bob的账户中扣除了$10,这该怎么办呢?别担心, 回滚(rollback)就可以了 !在两阶段提交协议中,系统一般包含两类机器(或节点): 一类为协调者 (coordinator),通常一个系统中只有一个; 另一类为事务参与者

顾名思义, 两阶段提交协议由两个阶段组成 。在正常的执行下,这两个阶段的执行过程如下所述:

阶段1:请求阶段(commit-request phase,或称表决阶段,voting phase)

在请求阶段,协调者将通知事务参与者准备提交或取消事务,然后进入表决过程。在表决过程中,参与者将告知协调者自己的决策:同意(事务参与者本地作业执行成功)或取消(事务参与者本地作业执行故障)。

阶段2:提交阶段(commit phase)

在该阶段,协调者将基于第一个阶段的投票结果进行决策:提交或取消。当且仅当所有的参与者同意提交事务时,协调者才通知所有的参与者提交事务,否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

如下图所示:

分布式系统指南

03 引入共识

精明的读者可能已经注意到我们构建的 2PC / 3PC存在一些漏洞 ,比如, 如果leader机器出现故障,则涉及到需要进行更换leader。 但除此之外,还有一些更为紧迫的缺陷。(备注:3PC即三阶段提交(Three-phase commit),它是为解决两阶段提交协议的缺点而设计的,详情请参考:http://www.hollischuang.com/archives/681首先,如果我们在系统中 引入了另一个leader机器 (假设是m1),会发生什么呢?我们需要这么做,以应对m0可能出现故障。但是, 这会导致协调问题的出现

其次,假设我们能够解决上文提到的leaders机器之间的协调问题。 可是如果一些followers机器(节点)出现故障,那该咋办呢? 要知道,这正是我们想要摆脱的问题。当有些节点出问题了,我们该怎么做呢?

如果我们静静等待这些节点重新上线,那我们可能面临一些效率问题,尤其是需要通过人为操作才能恢复某些服务器的时候。而如果我们选择忽视一些出故障的机器(节点),那我们应该忽视几台机器呢?更重要的是,假设某些机器恢复了,但它们的硬盘驱动器却因此而遭到了破坏(数据遭到损坏),这又该如何是好呢?虽然这些机器依旧会运行协议,但它们无法成功地将数据写入硬盘中。

预测种种这些问题都是很麻烦的,因此我们需要一个正在强劲的东西,能够忽视所有这些问题,只要保证一定数量的机器能够正常运行即可!就分布式系统而言,这真是太棒了。

上述这些问题(以及其他的问题)将我们带入了 第一个共识协议 Paxos 。这也让我们回到了最开始的那个问题:如何才能让一组机器就某条消息达成一致呢?由Leslie Lamport发明的Paxos是一种应对计算崩溃故障(crash fault)问题的共识协议。我不会深入讲解Paxos的运行方式,因为其中的细节实在是让人畏惧。

但是从更高的层面来看,Paxos其实是很好理解的: 只要大多数的机器(节点)接受某个提议(proposal),则这将保证系统中所有的机器都不会出现不一致的状态。 这是很神奇的,你只需要知道这点就可以了。

04 拜占庭容错

其实,这种应对机器故障的模型就是当前诸多数据中心(data centers)使用的模型。如果任何企业正在部署一个基于共识协议的分布式应用(distributed application),那该企业很有可能是在使用诸如Paxos这样的共识协议来作为应对机器故障的问题。等等, 那如果机器遭到黑客攻击了,该咋办呢? 大多数企业都认为这不会发生,且平心而论,通过结合VPN(虚拟专用网络)、防火墙和其他的安全机制可能使黑客攻击基本上不太可能发生。 但如果我们真的想要在遭受黑客攻击时保护自己,那么我们需要一个共识协议来应对系统中可能出现的(一台或多台)机器“说谎”的情况。 这就引入了拜占庭式容错(BFT)。为何叫拜占庭式呢?因为这个问题是Lamport在一个思维实验中提出的,一些拜占庭将军们面临的问题,他们被敌人的战线分开来了,但是依旧需要进行相互沟通来制定进攻/撤退计划。

05 一些行业术语

读到这,你也许会问“好吧,难道了解分布式系统只需要知道系统可能出现的机器(节点)故障问题(crash-fault)和拜占庭容错(BFT)就足够了吗?”差不多就是这样的。你真的没必要自找麻烦地去理解那些形式多样的各种共识协议,但你应该了解其中的一些基本分类: 1. Failure models 失效模型  
  • 机器故障:当机器(节点)出现故障时,共识协议就用于解决机器可能出现的状态不一致问题。
  • 拜占庭容错:机器不仅可能出现故障,还可能会“撒谎”。  
2. Network models 网络模型:  
  • 同步(Synchronous):我们不仅需要考虑机器会出现的各种故障问题,也要考虑网络通信的类型。在通信同步模型中,我们假设的是所有运行正常的节点(机器)都将在特定的时间内发送和接收消息。比如,你可以假定每条消息需要在5秒钟/分钟/小时内发送出去。
  • 异步(Asynchronous):这是同步的对立面。即便对于运行正常的节点(correct nodes)来说,消息通信延迟问题依旧可能存在。这种情况带来的结果是:你无法判定到底是节点出现故障了,还是节点没有故障,只是需要长时间才能回应。
  • 部分同步(Partially Synchronous):这种模型介于同步和异步之间。意思就是,存在一个上界(upper bound),但是这个上界并非被所有节点所知。我认为这种通信模型与实际的广域网通信(即互联网)非常相似。这只是我的个人观点哈,如果不同意见,欢迎反馈!
3. Message models 消息模型:

我将只考虑一种类型的消息模型:已验证的通信(authenticated communication),即各节点将对消息进行签名,任何人都可以验证来自某个其他节点的消息是真实可信的。

4. Guarantee models 保证模型:

这个命名有点奇怪,但我觉得这可以更好地描述该情况。

  • 非概率性(Non-probabilistic):如果某个共识协议是非概率性的,就意味着该协议可以保证安全性(没有概率分布),只要一定数量的节点运行正常即可。
  • 概率性(Probabilistic):如果某个共识协议是概率性的,那我们将自动引出一个概率分布(probability distribution)。通常来说,这种模型只能在1-ϵ的概率之间保证安全性,其中ϵ是系统设计人员选择的某个值。比如,一个概率性协议可能只保证99%的安全,即便一定数量的节点运行正常。记住这一点,这很重要!

06 区块链...或者,我真的不在乎你是谁

好的,我们先来回顾一下。 共识协议实质上就是一些算法,这些算法允许我们在很多可能不信任的机器上部署一个数据库

然而, 假如我想公开地部署一个数据库,使任何人都可以加入并向系统提出交易(propose transactions)。 此时会出现一个很大的问题: 如果我允许任何人都可以进入我的系统,我将无法区分谁是谁 。我不知道是谁正在参与进来。从根本来说,在过去,没有身份信息的共识是不可能实现的,但中本聪出现之后就不一样了。

比特币网络解决了这个问题。中本聪的绝妙观点在于, 我们可以使用另一种机制来代替投票机制,即工作量证明机制(PoW) 。比特币是首个实现不需要设想参与到网络中的到底是谁的共识协议。由于不需要确认身份,这使得可以很好地在一个无需许可的情况下部署比特币网络。

在比特币网络中,任何人都无需通过其他节点的允许便可加入该网络。在比特币网络中,节点不需要投票,而是提交附有砝码的值(propose values),该砝码就是工作量证明(PoW),用于解决一个加密难题(cryptographic puzzle)。所有的proposals都是联系在一起的,由这些proposals组成的最重的链(而非最长的链)构成了一个“正确的”历史记录。这就是比特币。

最后一点:比特币适合上文中所提到的哪一种模型?比特币使用的是拜占庭容错模型,该网络的通信是同步的,消息由密钥持有者进行验证,且保证模型是概率性的,就是说这条链是可以随时通过分叉进行复原的。换句话说,你可以接受“现在Bob的账户中只剩$10”,而你出错的几率很小。

这就是分布式系统的基本内容。在此基础上,你可以进入区块链世界了。

【文章版权归原作者所有,其内容与观点不代表Unitimes立 场。编译文章仅为传播更有价值的信息】

发文时比特币价格: ¥44322.41 版权信息

作者:Kevin Sekniqi

编译:Hulin

原文链接:https://sekniqi.com/blog/a-distributed-systems-primer-for-non-experts.html

版权声明: 分布式系统指南 分布式系统指南 分布式系统指南 作者保留权利。文章为作者独立观点,不代表巴比特立场。

文章标签: 分布式

下一篇: Visa整合Hyperledger Fabric开源区块链代码,改善可扩展许可网络金融交易

评论

登录 账号发表你的看法,还没有账号?立即免费注册


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Twitter Power

Twitter Power

Joel Comm / Wiley / 2009-02-17 / USD 24.95

"Arguably, one of the best tomes...Twitter Power is jam-packed with clever ways to start and dominate a marketplace." (Brandopia.typepad.com, March 23rd 2009) “For months I......一起来看看 《Twitter Power》 这本书的介绍吧!

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试