分布式系统指南
来源: www.8btc.com
本文转载自：https://www.8btc.com/article/295762，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有。
分布式系统指南
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 版权信息
作者：Kevin Sekniqi
编译：Hulin
原文链接：https://sekniqi.com/blog/a-distributed-systems-primer-for-non-experts.html
版权声明：
作者保留权利。文章为作者独立观点，不代表巴比特立场。
文章标签： 分布式
下一篇： Visa整合Hyperledger Fabric开源区块链代码，改善可扩展许可网络金融交易
推荐资讯
评论
登录 账号发表你的看法，还没有账号？立即免费注册
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
关注我们，获取更多IT资讯^_^
为你推荐:
相关软件推荐:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
