通俗的给你讲什么是线性一致性读！
你知道的越多，不知道的就越多，业余的像一棵小草！
你来，我们一起精进！你不来，我和你的竞争对手一起精进！
编辑：业余草
推荐：https://www.xttblog.com/?p=5165
通俗的给你讲什么是线性一致性读！
一致性是分布式系统的一大难题，几乎所有架构师和资深程序员都会面临如何平衡它。刚好最近又有粉丝在群里问我一致性问题，当时我简单阐述了一些，本文稍微整理了一下，分享出来，大家共勉！
什么时一致性
一致性是指数据处于一种语义上的有意义且正确的状态。一致性是对数据可见性的约束。
说白了就是让数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。
一致性分类
一致性的分类有很多种。比如：强一致性和弱一致性。
强一致性
强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点 A 中获取到 key1 的值与在节点 B 中获取到 key1 的值应该都是一样的。
弱一致性
弱一致性包含很多种不同的实现，分布式系统中广泛实现的是最终一致性。
最终一致性
所谓最终一致性，是弱一致性的一种特例，保证用户最终能够读取到某操作对系统特定数据的更新。但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。
对于最终一致性最好的例子就是 DNS 系统，由于 DNS 多级缓存的实现，所以修改 DNS 记录后不会在全球所有 DNS 服务节点生效，需要等待 DNS 服务器缓存过期后向源服务器更新新的记录才能实现。
除了强弱一致性，一致性还可以分为：数据一致性和事务一致性。
另外还有，读写一致性、单调读、因果一致性等。这些我后面抽出时间都会来一一写，今天我还是主要说线性一致性读。
线性一致性读
线性一致读是在分布式系统中实现 Java volatile 语义，当客户端向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。实现线性一致读常规手段是走 Raft 协议，将读请求同样按照 Log 处理，通过日志复制和状态机执行获取读结果返回给客户端。
举个简单的例子。在 t1 的时刻我们写入了一个值，那么在 t1 之后，我们一定能读到这个值，不可能读到 t1 之前的旧值(Java 中的 volatile 关键字，即线性一致读就是在分布式系统中实现 Java volatile 语义)。
简而言之是需要在分布式环境中实现 Java volatile 语义效果，即当 Client 向集群发起写操作的请求并且获得成功响应之后，该写操作的结果要对所有后来的读请求可见。和 volatile 的区别在于 volatile 是实现线程之间的可见，而线性一致读针对的是分布式系统之间的可见性。
如上图 Client A、B、C、D 均符合线性一致读，其中 D 看起来是 Stale Read，其实并不是，D 请求横跨 3 个阶段，而 Read 可能发生在任意时刻，所以读到 1 或 2 都行。
实现线性一致读最常规的办法是走 Raft 协议，针对该协议可以查看我之前的文章，比如：。
基本的想法是让一个系统看起来好像只有一个数据副本，而且所有的操作都是原子性的(线性一致寄存器的行为就好像只有单个数据副本一样，且每个操作似乎都是在某个时间点以原子性的方式生效的)。
一旦新的值被写入或读取，所有后续的读都会看到写入的值，直到它被再次覆盖。尤其要注意，如果 B 的读取严格发生于 A 的读取之后（他们读取的值正在被 C 写入），那么只要 A已经读取到 C 写入的新值，B 就必须返回 C 写入的新值，即使 C 的写入仍在进行中。
线性一致的系统惊人的少。例如，现代多核 CPU 上的内存甚至都不是线性一致的: 如果一个 CPU 核上运行的线程写入某个内存地址，而另一个 CPU 核上运行的线程不久之后读取相同的地址，并没有保证一定能读到第一个线程写入的值（除非使用了内存屏障（memorybarrier)或围栏（fence)。
在线性一致的数据在存储中是不存在并发操作的：必须有且仅有一条时间线，所有的操作都在这条时间线上，构成一个全序关系。可能有几个请求在等待处理，但是数据存储确保了每个请求都是在唯一时间线上的某个时间点自动处理的，不存在任何并发。对比之下，因果关系只是偏序关系。如果两个操作都没有在彼此之前发生，那么这两个操作是并发的，如果两个事件是因果相关的（一个发生在另一个事件之前），则它们之间是有序的，但如果它们是并发的，则它们之间的顺序是无法比较的。这意味着因果关系定义了一个偏序，而不是一个全序。
以上，希望能够对大家有所帮助！
最后，推荐几篇相关文章！
一致性协议算法-2PC、3PC、Paxos、Raft、ZAB、NWR超详细解析