开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第19天，点击查看活动详情
[论文阅读]一致性现代分布式数据库系统设计中的权衡因素（二）
CAP中的C，让所有操作看起来在必须存在一个总的顺序，也就是先行一致性。本文大纲是：
根据CAP，系统必须在高可用性和一致性之间做出选择。DDBS（分布式数据库)网络分区是必须的，而对于某些高可用极其重要的系统中，别无选择，必须牺牲一致性？
这个观点是错误的，CAP允许在没有分区的情况下，系统可以提供完整的ACID（原子性、一致性、隔离性和持久性）保证以及高可用性。那么一定有什么导致了大量现有系统做出了牺牲一致性的选择（但不是CAP）。
在一致性、可用性和延迟之间存在着一个基本的权衡，为了实现最高级别的可用性，DDBS必须在广域网上复制数据。也即是说，为了可用性，必须得复制数据，一旦我们有复制的行为，就产生了一致性vs延迟的权衡了。 。本文取材于耶鲁大学Abadi的一些博客和文章:www.cs.umd.edu/~abadi/pape…
CAP是为Failures准备的
CAP基本上指出，在构建DDBS时，设计者可以从三个理想的属性中选择两个：一致性（C）、可用性（A）和分区容忍性（P）。因此，只有CA系统（一致性和高可用性，但不耐分区）、CP系统（一致性和耐分区，但不高可用）和AP系统（高可用和耐分区，但不一致性）是可能的。
许多现代DDBS--包括SimpleDB/Dynamo、Cassandra、Voldemort、Sherpa/PNUTS和Riak--都没有默认情况下保证一致性，正如CAP所定义的那样。(尽管这些系统中的一些一致性在最初的版本发布后变得可以调整，但这里的重点是它们最初的设计)。在他们对CAP的证明中，Seth Gilbert和Nancy Lynch7使用了原子/可线性化一致性的定义。"所有的操作必须存在一个总的顺序，使每个操作看起来好像是在一个瞬间完成的。这相当于要求分布式共享内存的请求像在单个节点上执行一样，一次对操作作出反应"。
鉴于早期的DDBS研究集中在一致性系统上，我们很自然地认为CAP对现代系统架构师产生了重大影响，在该定理被证明后的一段时间内，他们建立了越来越多的系统实施减少一致性模型。这个假设背后的理由是，因为任何DDBS必须容忍网络分区，根据CAP，系统必须在高可用性和一致性之间做出选择。对于高可用性极其重要的任务关键型应用来说，它别无选择，只能牺牲一致性。
如果认为在没有任何分区的情况下降低一致性的DDBS是由于基于CAP的决策而这样做，那是错误的。
然而，这种逻辑是有缺陷的，与CAP的实际内容不一致。不仅仅是分区容忍度需要在一致性和可用性之间进行权衡；相反，它是下列因素的组合
• 分区容忍度和
• 网络分区本身的存在。
该定理简单地指出，网络分区导致系统不得不在降低可用性或一致性之间做出决定。网络分区的概率在很大程度上取决于系统实现的各种细节。它是分布在广域网（WAN）上，还是只是一个本地集群？硬件的质量如何？有什么程序可以确保对网络配置参数的改变是谨慎进行的？冗余的程度如何？尽管如此，总的来说，网络分区还是有些少见的，而且往往比DDBS中其他严重类型的故障事件发生的频率低。
由于CAP在基线情况下没有施加任何系统限制，所以认为在没有任何分区的情况下降低一致性的DDBS是由于基于CAP的决策而这样做是错误的。事实上，CAP允许在没有分区的情况下，系统可以提供完整的ACID（原子性、一致性、隔离性和持久性）保证以及高可用性。因此，该定理并不能完全证明减少一致性（通常还有其他几个ACID保证）的DDBS的默认构架是合理的。
一致性/延迟的权衡
要理解现代DDBS的设计，重要的是要认识到这些系统建立的背景。亚马逊最初设计Dynamo是为了向其电子商务平台的核心服务提供数据（例如，购物车）。Facebook构建了Cassandra来支持其收件箱搜索功能。LinkedIn创建了Voldemort来处理来自其网站上各种写密集型功能的在线更新。雅虎建立了PNUTS来存储用户数据，这些数据可以在每个网页视图中被读取或写入，为雅虎的购物页面存储列表数据，并存储数据来为其社交网络应用服务。与亚马逊激励Riak的用例相似。
在每一种情况下，系统通常为即时构建的网页提供数据，并运送给活跃的网站用户，并接收在线更新。研究表明，延迟是在线互动中的一个关键因素：小到100毫秒的增加都会极大地降低客户继续互动或在未来返回的概率。
不幸的是，在一致性、可用性和延迟之间存在着一个基本的权衡。(注意，可用性和延迟可以说是一回事：一个不可用的系统基本上提供了极高的延迟。在本讨论中，我认为延迟大于典型请求超时的系统，如几秒钟，是不可用的，而延迟小于请求超时，但仍然接近数百毫秒，是 "高延迟"。然而，我最终会放弃这种区分，并允许低延迟的要求包含这两种情况。因此，正如本节标题所暗示的那样，权衡的结果实际上只是一致性和延迟之间的问题。）
即使在没有网络分区的情况下，这种权衡也是存在的，因此与CAP描述的权衡完全不同。然而，它是上述系统设计中的一个关键因素。(单机故障是否被当作特殊类型的网络分区，与本讨论无关)。
这种权衡的原因是，高可用性要求意味着系统必须复制数据。如果系统运行的时间足够长，系统中至少有一个组件最终会失效。当这个故障发生时，该组件控制的所有数据将变得不可用，除非系统在故障发生前复制了另一个版本的数据。因此，故障的可能性，即使没有故障本身，也意味着在正常的系统运行中，可用性要求需要一定程度的数据复制。(注意这个权衡和 CAP 权衡之间的重要区别：虽然故障的发生会导致 CAP 权衡，但故障的可能性本身会导致这个权衡）。为了实现最高级别的可用性，DDBS必须在广域网上复制数据，以防止整个数据中心的故障，例如，由于飓风、恐怖袭击，或像2011年4月著名的亚马逊EC2云中断，一个单一的网络配置错误。上面提到的五个降低一致性的系统是为极高的可用性和通常用于在广域网上进行复制。
