强一致性 单调一致性 最终一致性 zookeeper一致性

我们都了解分布式CAP原则，其中的C就是一致性。有关一致性，实践中又可以分为：强一致性、单调一致性、最终一致性。

CAP中的C默认就是指：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。

1、强一致性（Strong Consistency）

在任何时刻所有的用户或者进程查询到的都是最近一次成功更新的数据。强一致性是程度最高一致性要求，也是最难实现的。关系型数据库更新操作就是这个案例。

2， 单调一致性（Monotonic Consistency）

单调一致性会从读写两个角度有各自的定义。

单调读一致性

如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回该值之前的值。（“If a process has seen a particular value for the object any subsequent accesses will never return any previous values”）

单调写一致性

系统保证来自同一个进程的写操作顺序执行。（Write operations that must precede other writes are executed before those other writes.）

3、最终一致性（Eventual Consistency）

和强一致性相对，在某一时刻用户或者进程查询到的数据可能都不同，但是最终成功更新的数据都会被所有用户或者进程查询到。当前主流的nosql数据库都是采用这种一致性策略。

额外内容：

zookeeper的一致性

我们以官方文档为准：（2019-11-17摘录的）

ZooKeeper is a high performance, scalable service. Both reads and write operations are designed to be fast, though reads are faster than writes. The reason for this is that in the case of reads, ZooKeeper can serve older data, which in turn is due to ZooKeeper's consistency guarantees:

Sequential Consistency : Updates from a client will be applied in the order that they were sent.

Atomicity : Updates either succeed or fail -- there are no partial results.

Single System Image : A client will see the same view of the service regardless of the server that it connects to.

Reliability : Once an update has been applied, it will persist from that time forward until a client overwrites the update. This guarantee has two corollaries:

If a client gets a successful return code, the update will have been applied. On some failures (communication errors, timeouts, etc) the client will not know if the update has applied or not. We take steps to minimize the failures, but the guarantee is only present with successful return codes. (This is called the monotonicity condition in Paxos.)
Any updates that are seen by the client, through a read request or successful update, will never be rolled back when recovering from server failures.
Timeliness : The clients view of the system is guaranteed to be up-to-date within a certain time bound (on the order of tens of seconds). Either system changes will be seen by a client within this bound, or the client will detect a service outage.

Using these consistency guarantees it is easy to build higher level functions such as leader election, barriers, queues, and read/write revocable locks solely at the ZooKeeper client (no additions needed to ZooKeeper). See Recipes and Solutions for more details.

简单总结：zk提供的是单调一致性，最终一致性，不是强一致性。 zk的文档清楚强调了ZooKeeper does not guarantee that at every instance in time, two different clients will have identical views of ZooKeeper data.

原文链接：https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#ch_zkGuarantees

mongoDB的一致性

原文链接：https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/

mongodb提供单调写一致性。
Monotonic Writes
MongoDB provides monotonic write guarantees, by default, for standalone mongod instances and replica set.

For monotonic writes and sharded clusters, see Causal Consistency.
Write operations that must precede other writes are executed before those other writes.

后记：我们实际开发业务分布式系统，必须在强一致性和最终一致性中间进行tradeoff。 根据业务要求，进行取舍。强一致性会增加延时（所有实例和副本进行数据同步）和降低可用性（只要有节点无法完成同步数据， 可用性就有问题）。
现在很多软件直接提供可配置的一致性，用户可以根据业务要求进行配置。 例如微软的cosmos-db。

参考：
1， https://hellokangning.github.io/en/post/consistency-in-distributed-system/
2，https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels
3， https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/