数据一致性

           由于CAP原理，所以在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

         当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

         所以我们下面谈谈数据一致性的模型。

         数据一致性通常指关联数据之间的逻辑关系是否正确和完整。而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。如果使用者遵循这种约定，则可以得到系统所承诺的访问结果。

         常用的一致性模型有：

• 强一致性：系统中的某个数据被成功更新(事务成功返回)后，后续任何对该数据的读取操作都得到更新后的值。这是传统关系数据库提供的一致性模型。

• 弱一致性：系统中的某个数据被更新后，后续对该数据的读取操作得到的不一定是更新后的值，这种情况下通常有个“不一致性时间窗口”(inconsistency window)存在：即数据更新完成后在经过这个“不一致性时间窗口”，后续读取操作就能够得到更新后的值。

• 最终一致性：属于弱一致性的一种，即某个数据被更新后，如果该数据后续没有被再次更新，那么最终所有的读取操作都会返回更新后的值。

         最终一致性的集中变体：

• 因果一致性：如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。

• “读己之所写（read-your-writes）”一致性：这是一个重要的模型。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。

• 会话（Session）一致性：这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。

• 单调（Monotonic）读一致性：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。

• 单调写一致性：系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

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

• N：数据复制的份数(the number of nodes that store replicas of the data)

• W：数据更新完成前需要到达的节点数(the number of replicas that need to acknowledge the receipt of theupdate before the update completes)

• R：为了读取正确数据需要读取的节点数(the number of replicas that are contacted when a data object isaccessed through a read operation)

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

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

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

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

参考：一致性选择，分布式原理——ACID vs BASE vs CAP，分布式原理——一致性&持久性