分布式系统指南

[billy.ryoko]

对于刚进入区块链领域的人来说，往往会对区块链技术感到非常困惑。理解该技术实际上相当简单的，但需要了解一些适当的背景知识。此外，大多数人其实并不需要真正了解区块链的具体内部运作方式，而只需了解一些背景知识和指南。在这篇文章中，我将简要介绍分布式系统（Distributed System），讨论各种共识协议、网络模型的类型以及其他一些相关的想法。对于想要了解这个领域的行业术语的人来说，这篇文章也可以算是一个指南，但我不会谈及太过晦涩难懂的细节内容。
01 时光倒流
分布式系统（Distributed Systems）是一个非常广泛的领域，为了便于理解，我将重点谈及该领域的共识方面。让我们把时间追溯到上世纪80年代。当时有一批非常聪明的计算机科学家正视图回答这一问题：如何才能让一组机器就某条消息（message）达成一致呢？我还是先来解释一下这个问题吧，因为这个问题似乎问得有点奇怪。假设你有一个数据库，可以用来存储一些非常重要的数据（比如银行需要存储的财务信息）。由于这些数据决不能丢失，因此你会即刻尝试在很多其他的机器上复制存储这些数据，这些机器分别是m0，m1…mn。这样一来，如果其中任何一台机器出故障了，你也不会担心找不回数据。为了搭建这个系统，我们可以采用最直观的方式，即：将其中一台机器指定为“首领（leader）”（假设由m0来担任leader这个角色），其他的机器为“追随者（followers）”。
如此一来，任何时候需要处理一笔新的客户交易时（如从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），通常一个系统中只有一个；另一类为事务参与者（cohorts），一般包含多个，在数据存储系统中可以理解为多个数据副本。
顾名思义，两阶段提交协议由两个阶段组成。在正常的执行下，这两个阶段的执行过程如下所述：

阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）

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

阶段2：提交阶段（commit phase）

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

http://m.8btc.com/fenbushi-xitongzhinan