微软首席架构师 Yaron Goland 最近发表了一篇文章，讲述了一个区块链客户端如何可以被实现为 AP 的或 CP 的，这取决于它的实现方式。具体是要可以配置在一个事务结束之后必须有多少个区块收到这个事务，才认为它可以被接受了。在事务之后接收到它的区块越多，它就越可能获得系统范围内的共识，即一致性。
一个区块链就是一套点对点的分布式数据库，没有中心节点可以决定数据正确与否。Goland 讲述到在诸如比特币之类的数字货币等场景下，这个问题尤其会造成巨大的困扰。可能用户以为他已经用真实的货币换到了比特币，可是等了一会他去查看自己的钱包时，却发现比特币不翼而飞了。
可是区块链只是一系列的不可变的数据块，而且非常可能每个节点都各自构建起一套不同的事务历史链。这样的背离叫做分枝，也是 Goland 的例子中一致性问题的根源所在。他解释了区块链是如何用一致性算法解决这个问题的，最终会有绝大多数达成一致，抛弃掉某些分枝。
“这是最终一致性的一个非常经典的例子。两个相互冲突的值被记录下来，系统在内部各节点之间进行通信，最终使用一种冲突解决协议来选出优胜者。”
Goland 指出，选择是否等待区块链最终变成一致的，这决定了客户端是 AP 的还是 CP 的。要成为 AP 的，一旦事个事务被加入到区块链中，客户端就要马上接受它。这样，就没有对其它节点的依赖，并且可以使数据可用，但这里有个风险，就是别的节点有可能会拒绝这个事务，因而这样做牺牲了一致性。如果想要成为 CP 的，客户端就应该在区块链针对某个事务达成了一致决议之后，才接受它。这样做的负面影响在于，数据的确一致了，但在有网络分区问题存在时却可能会阻碍一致性的达成，从而使数据不可用。
关于如何等待一个事务达成系统内一致性的问题，Goland做了一番详细的解释，总结起来就是：“直到至少有X 个区块同意之后，才能认为某件事发生了”。这就意味着一个事务发生之后，客户端必须等待，直到再有X 个区块也收到了，才能接受它。
Yanos 还强调，让客户端在这个方面成为可配置的，这样做并不违反 CAP 原理。因为这样的配置方法是在可用性和一致性之间做出的权衡——是不可能同时拥有这两种特性的：
“所以我们上面解释的并不是在说比特币如何能既是 AP 的又是 CP 的。我们上面只是在讲述如何通过完全不同的 CAP 权衡来构建两种完全不同的系统，方法就是除了客户端之外，让比特币的所有部分都保持相同。”
总之，Goland 证明了尽管区块链是一种点对点的模型，强一致性的需求仍然是可以被满足的。这对于比特币之类的数字货币来说尤其重要，因为这种权衡意味着用户可以信任事务的结果。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论