分布式系统的一致性原理

对于分布式系统，我们必须深刻理解和牢记一点：分布式系统的不可靠性。

“可靠性”是指系统可以无故障的持续运行，如果一个系统在运行中意外宕机或者无法正常使用，那么他就是一个不可靠的系统，即使宕机和无法使用的时间很短。我们知道，分布式系统通常是由独立的服务器通过网络松散耦合组成的，而网络本质上是一个复杂的I/O系统，而通常情况下，I/O发生故障的概率和不可靠性远远高于主机的CPU和内存，加之网络设备的引入，也增加了系统大面积瘫痪的可能性。总之，分布式系统中重要的理论和设计都是建立在“分布式系统不可靠”这一前提上的，因为系统不可靠，所以我们需要增加一些额外的复杂设计和功能，来确保由于分布式系统的不可靠导致系统不可用性的概率降到最低。“可用性”是一个计算指标，如果系统在每小时崩溃1ms，那么他的可用性就超过了5个9,；如果一个系统从来不奔溃，但是每年要停机两周，那么他是高度可靠的，但是可用性只有96%；

理解了分布式系统的可靠性原理之后，接下来需要解释一个东西–一致性原理。分布式集群的一致性是分布式系统“无法绕开的一块巨石”，很多重要的分布式系统都涉及一致性问题，而目前解决此问题的几个一致性算法也都非常的复杂。

分布式系统中一致性场景描述如下：

N个节点组成一个分布式集群，要保证所有的节点可以执行相同的命令序列，并达到一致的状态。即在每个节点都执行了相同的命令序列之后，每个节点的结果都是相同的。实际上，由于分布式系统的不可靠性，所以通常只要保证分布式集群中一半以上（N/2 + 1）的节点正常并达到一致性即可满足要求。

如下图所示，是分布式集群“一致性”算法的一个典型案例，来自Kafka。



当客户端向Kafka集群发起写Message请求时，集群的Leader首先会写一份数据到本地，同时向多个Follower发起远程写入请求，而这个过程，可能会有意外情况导致某些Follower节点发生故障无法应答（Ack）。此时，按照“一致性”算法，如果集群中有超过一半以上的节点正常应答，则表示此次操作执行成功。上图中包括Leader在内为两个节点成功，所以Leader会提交（Commit）Message数据并成功返回给客户端，否则不会提交数据，此次写入请求失败。

由于“一致性”算法所描述的场景很有代表性，而且分布式系统中几乎每个涉及数据持久化的系统都会面临这一复杂问题，加上该算法本身的复杂性与挑战性，所以它一直是分布式领域的热点研究课题之一。

在分布式集群的每个节点中，我们所探讨的一致性一般情况下指的是“最终一致性”。其实最终一致性是降低了标准的一致性，即以“数据一致性存在延迟时间”来换取数据读写的高性能。目前最终一致性基本成为越来越多的分布式系统所遵循的一个设计目标，对其场景的完整描述如下：

在分布式数据库集群中（读写分离的数据库），假设数据B被更新，则后续对数据B的读取操作得到的不一定是更新后的值，从数据B被更新到后续读取到B的最新值会有一段延时，这段延时又叫做“不一致窗口（Inconsistency Window）”，不一致窗口的最大值可以根据以下因素确定：通信延迟，系统负载、复制方案涉及的副本数量等。而最终一致性则保证不一致窗口的时间是有限的，最终所有的读取操作都会返回B的最新值。而DNS就是使用最终一致性的成功例子。

参考：架构揭秘从分布式到微服务