分布式系统指南
Unitimes 2018-10-23 21:00 发布在 306
对于刚进入区块链领域的人来说,往往会对区块链技术感到非常困惑。理解该技术实际上相当简单的,但需要了解一些适当的背景知识。此外,大多数人其实并不需要真正了解区块链的具体内部运作方式, 而只需了解一些背景知识和指南 。在这篇文章中,我将简要介绍分布式系统(Distributed System),讨论各种共识协议、网络模型的类型以及其他一些相关的想法。对于想要了解这个领域的行业术语的人来说,这篇文章也可以算是一个指南,但我不会谈及太过晦涩难懂的细节内容。
01 时光倒流
如此一来,任何时候需要处理一笔新的客户交易时(如从Bob账户中扣除$10),leader机器将发出指令要求所有followers机器去执行这笔交易。这听起来很棒,可是我们会面临一个新的问题。
首先,如果leader机器m0发出指令要求m3机器从Bob的账户中扣除$10,但这条消息(message)发送失败了,并没有传递给m3,这怎么办呢?这真是很糟糕!我们无法再依靠m3机器来存储数据了, 因为现在m3机器上存储了与其他机器上不一致的数据(inconsistent data) 。要知道:不一致数据的出现就意味着,系统中有些机器中存储的数据与其他机器中存储的数据不一样,而它们本该是一样的!
02 确认消息
顾名思义, 两阶段提交协议由两个阶段组成 。在正常的执行下,这两个阶段的执行过程如下所述:
阶段1:请求阶段(commit-request phase,或称表决阶段,voting phase)
在请求阶段,协调者将通知事务参与者准备提交或取消事务,然后进入表决过程。在表决过程中,参与者将告知协调者自己的决策:同意(事务参与者本地作业执行成功)或取消(事务参与者本地作业执行故障)。
阶段2:提交阶段(commit phase)
在该阶段,协调者将基于第一个阶段的投票结果进行决策:提交或取消。当且仅当所有的参与者同意提交事务时,协调者才通知所有的参与者提交事务,否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。
如下图所示:
03 引入共识
其次,假设我们能够解决上文提到的leaders机器之间的协调问题。 可是如果一些followers机器(节点)出现故障,那该咋办呢? 要知道,这正是我们想要摆脱的问题。当有些节点出问题了,我们该怎么做呢?
如果我们静静等待这些节点重新上线,那我们可能面临一些效率问题,尤其是需要通过人为操作才能恢复某些服务器的时候。而如果我们选择忽视一些出故障的机器(节点),那我们应该忽视几台机器呢?更重要的是,假设某些机器恢复了,但它们的硬盘驱动器却因此而遭到了破坏(数据遭到损坏),这又该如何是好呢?虽然这些机器依旧会运行协议,但它们无法成功地将数据写入硬盘中。
预测种种这些问题都是很麻烦的,因此我们需要一个正在强劲的东西,能够忽视所有这些问题,只要保证一定数量的机器能够正常运行即可!就分布式系统而言,这真是太棒了。
上述这些问题(以及其他的问题)将我们带入了 第一个共识协议 Paxos 。这也让我们回到了最开始的那个问题:如何才能让一组机器就某条消息达成一致呢?由Leslie Lamport发明的Paxos是一种应对计算崩溃故障(crash fault)问题的共识协议。我不会深入讲解Paxos的运行方式,因为其中的细节实在是让人畏惧。
但是从更高的层面来看,Paxos其实是很好理解的: 只要大多数的机器(节点)接受某个提议(proposal),则这将保证系统中所有的机器都不会出现不一致的状态。 这是很神奇的,你只需要知道这点就可以了。
04 拜占庭容错
其实,这种应对机器故障的模型就是当前诸多数据中心(data centers)使用的模型。如果任何企业正在部署一个基于共识协议的分布式应用(distributed application),那该企业很有可能是在使用诸如Paxos这样的共识协议来作为应对机器故障的问题。等等, 那如果机器遭到黑客攻击了,该咋办呢? 大多数企业都认为这不会发生,且平心而论,通过结合VPN(虚拟专用网络)、防火墙和其他的安全机制可能使黑客攻击基本上不太可能发生。 但如果我们真的想要在遭受黑客攻击时保护自己,那么我们需要一个共识协议来应对系统中可能出现的(一台或多台)机器“说谎”的情况。 这就引入了拜占庭式容错(BFT)。为何叫拜占庭式呢?因为这个问题是Lamport在一个思维实验中提出的,一些拜占庭将军们面临的问题,他们被敌人的战线分开来了,但是依旧需要进行相互沟通来制定进攻/撤退计划。
05 一些行业术语
- 机器故障:当机器(节点)出现故障时,共识协议就用于解决机器可能出现的状态不一致问题。
- 拜占庭容错:机器不仅可能出现故障,还可能会“撒谎”。
- 同步(Synchronous):我们不仅需要考虑机器会出现的各种故障问题,也要考虑网络通信的类型。在通信同步模型中,我们假设的是所有运行正常的节点(机器)都将在特定的时间内发送和接收消息。比如,你可以假定每条消息需要在5秒钟/分钟/小时内发送出去。
- 异步(Asynchronous):这是同步的对立面。即便对于运行正常的节点(correct nodes)来说,消息通信延迟问题依旧可能存在。这种情况带来的结果是:你无法判定到底是节点出现故障了,还是节点没有故障,只是需要长时间才能回应。
- 部分同步(Partially Synchronous):这种模型介于同步和异步之间。意思就是,存在一个上界(upper bound),但是这个上界并非被所有节点所知。我认为这种通信模型与实际的广域网通信(即互联网)非常相似。这只是我的个人观点哈,如果不同意见,欢迎反馈!
我将只考虑一种类型的消息模型:已验证的通信(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 版权信息
文章标签: 分布式
下一篇: Visa整合Hyperledger Fabric开源区块链代码,改善可扩展许可网络金融交易
推荐资讯
评论
登录 账号发表你的看法,还没有账号?立即免费注册
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 作者访谈:分布式敏捷框架指南
- Hadoop分布式文件系统使用指南
- 开源分布式中间件 DBLE 快速入门指南
- 开源|ns4_frame分布式服务框架开发指南
- 谷歌开源项目风格指南之 Python 风格指南
- RVM 使用指南
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Building Social Web Applications
Gavin Bell / O'Reilly Media / 2009-10-1 / USD 34.99
Building a social web application that attracts and retains regular visitors, and gets them to interact, isn't easy to do. This book walks you through the tough questions you'll face if you're to crea......一起来看看 《Building Social Web Applications》 这本书的介绍吧!