分布式一致性问题分析

    在我们日常的开发经验中，相信很多开发人员都碰到过这样的问题：假设客户端C1将系统中的一个值K由V1更新为V2，但客户端C2无法立即读取到K的最新值，需要一段时间之后才能读到。这个例子就是常见的数据库之间的复制的延时问题。

      分布式系统对于数据的复制要求一般都来自一下两个原因。

• 为了增加系统的可用性，以防止单点故障引起的系统不可用。
• 提高系统的整体性能，通过负载均衡技术，能够让分布在不同地方的数据副本都能够为用户提供服务。

      数据复制在可用性和性能方面给分布式系统带来的巨大好处是不言而喻的，然而数据复制所带来的一致性挑战，也是每一个系统研发人员不得不面对的。

      所谓的分布式一致性问题，是指在分布式环境中引入数据复制机制后，不同数据节点间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致情况。简单的讲，数据一致性就是指对一个副本数据进行更新时，必须确保也能更新其他的副本，否则不同副本之间的数据将不在一致。

      那么怎么来解决这个问题呢？一种观点就是：既然是由于延时引起的问题，那我可以将写入的动作阻塞，知道数据复制完成后，才完成写入操作。没错，这似乎能解决问题，而且有一些系统的构架也确实直接使用了这个思路。但这个思路在解决一致性问题的同时，又带来了新的问题：写入的性能。如果你的应用场景有非常多的写入，那么使用这个思路之后，后续的写请求都将会阻塞在前一个请求的写操作上，导致系统整体性能急剧下降。

      总的来说，我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，产生了下面的要说的一致性级别。

• 强一致性。这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的就是说什么，用户体验好，但实现起来往往对系统的性能影响较大。
• 弱一致性。这种一致性级别约束了系统在写入成功后，不承若里可以读到写入的值，也不具体承诺多久之后数据能够达到一致，但会尽可能保证到某个时间级别后，数据能够达到一致状态。
• 最终一致性。最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常重要的一种一致性模型，也是业界待大型分布式系统的数据一致性上比较推崇的模型。

      后续会深入介绍分布式一致性问题的工业解决方案--Zookeeper。