分区容错性的权衡

确定一致性和分区容错的优先顺序的数据库通常采用主辅助设置，其中系统中的多个节点中的一个节点被选为领导者。 只有引导者核准数据写入，而所有辅助节点从引导者复制数据以处理读取。 如果主节点失去与网络的连接，或无法与系统的许多节点通信，那么剩余节点会选出新的主节点。 此选择过程在不同系统之间有所不同，并且可能是 重大问题的根源。

IBM Cloudant 通过采用主-主设置来划分可用性和分区容错的优先级，以便每个节点都可以接受对其部分数据的写入和读取。 多个节点包含数据的每个部分的副本。 每个节点都会复制其他节点的数据。 如果某个节点变得不可访问，那么在网络修复期间，其他节点可以接替该节点的工作。 这样，即使发生任意节点故障，系统也会及时返回数据，并保持 最终一致性。 在取消绝对一致性优先的权衡中，所有节点都需要一定时间才能看到相同的数据。 因此，当新数据通过系统传播时，某些响应可能包含旧数据。

改变方法

维护一个一致的数据视图不仅合乎逻辑，而且很容易理解，因为关系数据库会为您完成此工作。 期望的情况是，与数据库系统交互的基于 Web 的服务以这种方式运行。 但这种期待并不意味着他们这样做。 一致性不是给定的，改变方法需要一点点工作。

事实上，对于许多企业云服务而言，一致性不一定是基本要素。 对于使用率极高的大型系统，系统中某个部分可能会发生故障的概率也很高。 围绕可用性和最终一致性优先需求而设计的数据库更适合使应用程序保持联机状态。 应用程序数据的一致性可以在该事实之后解决。

企业中的应用程序可用性与一致性

查看流行的基于 Web 的服务显示，人们已经期望高可用性，并乐于将这种可用性与最终一致的数据进行交易，但往往没有意识到他们正在这样做。

许多应用程序会在可用性方面误导用户。 考虑 ATM: 不一致的银行数据是为什么在没有实现的情况下仍有可能透支资金的原因。 如果网络中的每个节点都必须在操作继续之前停止并记录此数字，那么在整个银行系统中呈现一致的帐户余额视图是不现实的。 更好的选择是使系统高度可用。

银行业早在 20 世纪 80 年代就已明白这一点，但许多 IT 组织现在都还在担心牺牲一致性来实现可用性。 想想看，一旦您的销售团队无法访问自己的 CRM 应用程序，会给支持人员打多少电话！ 现在，再想想他们是否会注意到一个数据库更新花费了几秒钟在整个应用程序中传播。

可用性优先于一致性，超乎您的想像。 更多的例子有：在线购物车系统、HTTP 高速缓存和 DNS。 组织必须考虑停机时间的成本，例如用户不满、生产率损失和错失商机。

从理论到实施

解决高可用性对于云应用程序至关重要。 否则，随着您的扩展，全局数据库一致性仍然是一个主要瓶颈。 高可用性应用程序需要保持与其数据的持续联系，即使这些数据不是最新的。 这就是最终一致性的概念，没什么好害怕的。 有时，在大规模的情况下，最好是提供并非完全正确的答案，而不是完全不为他们服务。

数据库系统以不同方式隐藏可用性与一致性的复杂性，但它们始终存在。 IBM Cloudant， CouchDB 和其他 NoSQL 数据库团队认为，最佳策略要求开发者在设计过程中及早解决这些复杂性。 首先处理这一困难的工作，可以减少意外情况，因为应用程序从一开始就已做好缩放准备。