淘宝海量数据库之二：一致性选择

众所周知，一致性是数据最关键的属性之一。2000年，Eric Brewer教授在ACM分布式计算年会上指出了著名的CAP理论：

Brewer, E. A. 2000. Towards robust distributed systems. In Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (July 16-19, Portland, Oregon)

即分布式系统不可能满足一致性(C: Consistency)，可用性(A: Availability)和分区容错性(P: Tolerance of network Partition)这三个需求。

<wbr></wbr>

大约两年后，Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性：

Gilbert , S., Lynch, N. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33(2)

<wbr></wbr>

几种常见的一致性类型有：

• 强一致性：系统中的某个数据被成功更新(事务成功返回)后，后续任何对该数据的读取操作都得到更新后的值。这是传统关系数据库提供的一致性模型，也是关系数据库深受人们喜爱的原因之一。
• 弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作得到的不一定是更新后的值，这种情况下通常有个“不一致性时间窗口”(inconsistency window)存在：即数据更新完成后在经过这个“不一致性时间窗口”，后续读取操作就能够得到更新后的值。
• 最终一致性：属于弱一致性的一种，即某个数据被更新后，如果该数据后续没有被再次更新，那么最终所有的读取操作都会返回更新后的值。

关于最终一致性，Werner Vogels提出了NWR模型(Eventually Consistent - Revisited, By Werner Vogels on December 23, 2008 12:15 AM,<wbr><wbr>http://www.allthingsdistributed.com/2008/12/eventually_consistent.html)：</wbr></wbr>

• N：数据复制的份数(the number of nodes that store replicas of the data)
• W：数据更新完成前需要到达的节点数(the number of replicas that need to acknowledge the receipt of the update before the update completes)
• R：为了读取正确数据需要读取的节点数(the number of replicas that are contacted when a data object is accessed through a read operation)

Werner Vogels还写到，如果W+R > N，那么读写节点有重叠，读总是能够得到最新的数据，这就是强一致性。在传统的一主一备同步复制的关系数据库中，N=2，W=2，R=1；在非同步复制模型中，W变成1，此时W+R=N，一致性也就无法保证。

<wbr></wbr>

不过，NWR模型只代表了一类情形，例如，在传统的一主一备的非同步复制的关系数据库中，尽管N=2，W=1，R=1，如果只有主库提供服务，则一致性仍然是保证的，不过主机异常时，服务的恢复不是实时的，因此CAP理论依然适用。

<wbr></wbr>

在调研中，我们发现一些项目正在或倾向于弱一致性或最终一致性，咋看这似乎表明这些工程师偏爱弱一致性或最终一致性。然而，在经过仔细沟通和深入分析后，我们发现，这些项目采用弱一致性或最终一致性，其实是在高数据量(十几亿条记录、数TB数据)和高访问量(数千TPS、数万QPS)需求压力之下的无奈选择。如果两个系统都能满足上述高数据量和高访问量需求且成本差异不是很大，那么在强一致性和若一致性(或最终一致性)两者中他们会毫不犹豫地选择前者。

<wbr></wbr>

显而易见，作为整个系统中最为基础的部件，如果数据库的数据是弱一致，那么上层应用就不得不承受这种弱一致导致的种种后果，从上层应用的角度看，这并不是十分友善的行为。由于上述原因，我们决心在我们的海量数据库中实现与传统关系数据库相同的强一致性，因为我们相信这种强一致性不仅会简化数据库的管理，减轻数据库管理的工作量，尤其重要的是，上层应用不再需要关注数据的不一致性，应用程序也会因此而简化，并且易于开发和维护。