分布式系统与计算机网络 漫谈分布式系统

最近区块链的话题很火。有人想用它改变世界，有人想用它招摇撞骗。

.

但是我们今天只分析技术。从技术的角度看，区块链是一种与分布式系统有关的技术。它与分布式系统的各个概念之间有什么联系？今天本文就借这个机会，跟大家一起讨论一下分布式系统的核心问题和概念。最后，我们将尽量沿着逻辑上前后一贯的思路，讨论一下区块链技术。

分布式系统和一致性问题

一个由区块链技术支撑的系统，比如比特币网络或以太坊，从技术上看，是一个很庞大的分布式系统。因此，我们首先从分布式系统开始说起。

对于技术人员来说，特别是服务器开发人员，几乎每个人都经常和分布式系统打交道。当服务的规模越来越大的时候，它必然发展成一个复杂的分布式系统。很典型的，就是各种分布式，它们通常能将数据以某种方式在多个节点上存储，在高可用的基础上保证数据的一致性。

实际上，一致性问题(consensus problem)是分布式系统需要解决的一个核心问题。分布式系统一般是由多个地位相等的节点组成，各个节点之间的交互就好比几个人聚在一起讨论问题。让我们设想一个更具体的场景，比如三个人讨论中午去哪里吃饭，第一个人说附近刚开了一个火锅店，听说味道非常不错；但第二个人说，不好，吃火锅花的时间太久了，还是随便喝点粥算了；而第三个人说，那个粥店我昨天刚去过，太难喝了，还不如去吃麦当劳。结果，三个人僵持不下，始终达不成一致。

有人说，这还不好解决，投票呗。于是三个人投了一轮票，结果每个人仍然坚持自己的提议，问题还是没有解决。有人又想了个主意，干脆我们选出一个leader，这个leader说什么，我们就听他的，这样大家就不用争了。于是，大家开始投票选leader。结果很悲剧，每个人都觉得自己应该做这个leader。三个人终于发现，「选leader」这件事仍然和原来的「去哪里吃饭」这个问题在本质上是一样的，同样难以解决。

这时恐怕有些读者们心里在想，这三个人是有毛病吧......就吃个饭这么点小事，用得着争成这样吗？实际上，在分布式系统中的每个节点之间，如果没有某种严格定义的规则和协议，它们之间的交互就真的有可能像上面说的情形一样。整个系统达不成一致，就根本没法工作。

所以，就有聪明人设计出了一致性协议(consensus protocol)，像我们常见的比如Paxos、Raft、Zab之类。与前面几个人商量问题类似，如果翻译成Paxos的术语，相当于每个节点可以提出自己的提议(称为proposal，里面包含提议的具体值)，协议的最终目标就是各个节点根据一定的规则达成相同的proposal。但以谁的提议为准呢？我们容易想到的一个规则可能是这样：哪个节点先提出提议，就以谁的为准，后提出的提议无效。但是，在一个分布式系统中的情况可比几个人聚在一起讨论问题复杂多了，这里边还有网络延迟的问题，导致你很难对发生的所有事件进行全局地排序。举个简单的例子，假设节点A和B分别几乎同时地向节点X和Y发出了自己的proposal，但由于消息在网络中的延迟情况不同，最后结果是：X先收到了A的proposal，后收到了B的proposal；但是Y正好相反，它先收到了B的proposal，后收到了A的proposal。这样在X和Y分别看来，谁先谁后就难以达成一致了。

此外，如果考虑到节点宕机和消息丢失的可能性，情况还会更复杂。节点宕机可以看成是消息丢失的特例，相当于发给这个节点的消息全部丢失了。这在CAP的理论框架下，相当于发生了网络分割(network partitioning)，也就是对应CAP中的P。为什么节点宕机和消息丢失都能归结到网络分割的情况上去呢？是因为这几种情况实际上无法区分。比如，有若干个节点联系不上了，也就是说，对于其它节点来说，它们发送给这些节点的消息收不到没有回应。真正的原因，可能是网络中间不通了，也可能是那些目的节点宕机了，也可能是消息无限期地被延迟了。总之，就是系统中有些节点联系不上了，它们不能再参与决策，但也不代表它们过一段时间不能重新联系上。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-65268-1.html