1. 什么是一致性
在分布式系统中，一致性（Consistency）是指多副本（Replications）问题中的数据一致性。
分布式系统：由多个计算机（IP地址）及其上软件构件（端口）所组成，通过网络互联，通过消息进行通信和协同。
分布式系统应对并发请求的两种基本方式分别是垂直扩展（提升单机处理能力/硬件或架构优化）和水平扩展（增加服务器数量）。
分布式系统的CAP定理中的CAP分别是指：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。（最多只能同时满足其中两项）
2. 一致性的种类
- 事务一致性
- 数据一致性
本文主要讨论数据一致性（事务一致性指ACID，可以参考 ）
3. 导致一致性出现的原因
数据的分布式存储是导致出现一致性的唯一原因
4. 强一致性 与 弱一致性
4.1. 数据一致性的种类
强一致性（线性一致性）：即复制是同步的
弱一致性：即复制是异步的
4.2. 强一致性两个要求
任何一次读都能读到某个数据的最近一次写的数据。
系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。
简言之，在任意时刻，所有节点中的数据是一样的。
4.3. 弱一致性
数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。
最终一致性就属于弱一致性。
4.4. 强一致性和弱一致性举例
例如，对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性
用户更新网站头像，在某个时间点，用户向主库发送更新请求，不久之后主库就收到了请求。在某个时刻，主库又会将数据变更转发给自己的从库。最后，主库通知用户更新成功。
如果在返回“更新成功”并使新头像对其他用户可见之前，主库需要等待从库的确认，确保从库已经收到写入操作，那么复制是同步的，即强一致性。如果主库写入成功后，不等待从库的响应，直接返回“更新成功”，则复制是异步的，即弱一致性。
强一致性可以保证从库有与主库一致的数据。如果主库突然宕机，我们仍可以保证数据完整。但如果从库宕机或网络阻塞，主库就无法完成写入操作。
在实践中，我们通常使一个从库是同步的，而其他的则是异步的。如果这个同步的从库出现问题，则使另一个异步从库同步。这可以确保永远有两个节点拥有完整数据：主库和同步从库。这种配置称为半同步。
5. 顺序一致性
两个要求：
任何一次读都能读到某个数据的最近一次写的数据。
系统的所有进程的顺序一致，而且是合理的。即不需要和全局时钟下的顺序一致，错的话一起错，对的话一起对。（强一致性的要求比顺序一致性更严格）
6. 最终一致性
不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。
最终两个字用得很微妙，因为从写入主库到反映至从库之间的延迟，可能仅仅是几分之一秒，也可能是几个小时
简单说，就是在一段时间后，节点间的数据会最终达到一致状态。
6.1. 最终一致性的种类
最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：
-
因果一致性（Casual Consistency）。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问，遵守一般的最终一致性规则。
-
“读己之所写（read-your-writes）”一致性。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
-
会话（Session）一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。
-
单调（Monotonic）读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
-
单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。