我全都要？不可能的：分布式系统的CAP原理

这是从链开始的第034篇推送

央视在大批虚拟货币的同时，工信部则继续对区块链技术表示关注并支持。这种矛盾应该会继续保持。BCH硬分叉抛弃了17%的节点，不过对于主流货币影响不大。

BTC（1h线）：昨天其实已经分析过最后一次到8700区间的新高。那么昨天下午确实新高，之后调整也是意料之中。当下必须注意，这里8300是不允许跌破的，否则还要再跌一轮，而只要2小时内不新低，8300区间就可以直接构成买点。

ETH（1h线）：最终走势其实和BTC差不多，不同的是目前ETH不建议随便操作了，这里正常来说还会再度新低。即使不新低也无法看新高。

EOS（1h线）：EOS其实昨天有说过，关注14区间的压力。那么这里的震荡必须注意了，图中的通道下轨是不可以跌破的。否则基本上本轮的最高点就确定了，可以逢高减仓。

XRP：实际是跟随主流币种跌回启动点，由于XRP走势偏弱，不建议继续操作了。

LTC：其实昨天提示过140区间压力较大，那么今天果然跌回，这里必须注意130区间的支撑。

区块链如果在时尚界可能会被称为“带货女王”，由它带火的技术概念丝毫不逊色于身材最惹火的维密天使。

分布式系统就是这样一个例子。读者姥爷可能已经通过各类数字货币产生了某种直观印象，即分布式账本是区块链技术的重要组分。事实上正是如此，分布式系统是区块链绕不开的话题，在一些技术范很强的区块链项目白皮书里也有对于该项目分布式系统的描述。

分布式系统很复杂，但让小链从CAP说起。毫不夸张的说，CAP定理是分布式系统设计中最基础，也是最为关键的理论。它指出，分布式数据存储不可能同时满足以下三个条件。

•一致性（Consistency）：不遵从最新消息的节点将被闭嘴（返回错误）；

•可用性（Availability）：每个节点都能表达自己收到的消息的权利，但不保证最新；

•分区容忍（Partition tolerance）：允许消息送到一半掉了或者延误，从而导致因为是否收到消息而分成两个阵营，并且都在运行（互相吵架）。

这样整件事情就明朗很多。考虑一个不满足P的系统，也就是这个系统不允许出现网络故障，那么从这个系统读取信息时，当然每个节点都会返回一致的最新信息。这就同时满足了C和A两个条件。这种系统听起来非常理想，但实际上是非常脆弱的，容不起任何错误的打击。

如果想拥有一个坚强一点的系统，使这个系统在出现故障时也能跌跌撞撞地运行下去，我们就必须在一致性C和可用性A中做出抉择。这也非常容易理解。

如果部分节点一直顺畅地接收到最新信息，而部分节点由于网络问题等因素导致没有接收到最新信息，那么在读取这些问题节点的信息时，只能返回两种结果：如果想保持一致性，则返回ERROR，虽然损失了可用性，但是保持了所有非错误返回的一致；如果想保持可用性，则返回当前信息，虽然与最新信息并不一致，但是能保证每个节点都可用。

这三种不同的抉择反映了不同系统的偏好差异。大型互联网应用必须保证分区容忍和可用性，而两个用户打开的页面不完全一样是可以忍受的成本，所以选择AP。这样的系统不能达成一致性，需要给出数据冲突，给出数据冲突就需要维护数据版本。Dynamo就是这样的系统。

我们在几周前和读者们共同探究过兰波大神提出的Paxos算法，这种算法选择的是一致性和分区容忍。这种系统只有部分可用性，没有更新的节点只能返回错误。例如对于银行这种需要确保一致性的场景，很可能会选择CP模型，这样用户不会在两台ATM机上看到不同的余额，但是可能会遇到一台ATM机不能使用的情况。这就是牺牲可用性来确保一致性。

相比前两种情况，CA模型更为理想化。Paxos模型出现之前，有过一个“两阶段提交”模型（2PC）。这种系统不能容忍网络错误或节点错误，一旦出现这样的问题，整个系统就会拒绝写请求，因为它并不能判断对面节点的状态。因此唯一安全的做法就是把自己变成只读。

虽然CAP定理如此重要，但仍然有一些人会对此理解出现偏差。作为分布式系统的重要理论基础，读者姥爷应当对此更加重视。在此基础上，小链将带领遨游更丰富的分布式系统世界。

行情/道法自然 文/小众胡吹