数据一致性
一致性(consistence)和共识性(consensus)不是完全一致的概念。
数据处理语义
- Exactly Once 精确一次
- At Least Once 最少一次
- At Most Once 最多一次
在处理数据时候，需要考虑在三种不同的语义会对业务产生什么影响。程序要实现不同的语言代价也是不同的，而且不同的语义对业务的影响也不一样。
数据处理过程对数据一致性的影响是强相关的。
共识性
共识性(consensus)和数据一致性(consistence)是两个很相似的概念，也经常被用混。共识指的是在一个分布式集群中，所有节点对同一个提案（proposal）能达成一致。提案生效时表示所有节点都达成一致，这个过程中也就不存在数据是否一致的问题了。
而一致性一般指的是分布式系统中一份数据的多个副本，对外表现的一致性。
一致性分类
数据一致性是分布式数据存储的一个核心问题，它可以从两个维度来看：
- 以数据为中心
客户端在收到服务端对修改数据请求的响应后，此时数据在服务端中的备份处于哪种状态？ - 以用户为中心
客户端在收到服务端对修改数据请求的响应后，立即再去读取相应的数据时，接收到的数据是什么样的？
以数据为中心
严格一致性
任何写操作都能被读到，任何读操作读取的都是最新的数据。要达到这种一致性就需要有全局时钟，即每次操作都会有一个全局时间，以全局时间来看，我们的操作就是单进程的操作。 全局时钟基本实现不了。顺序一致性
任何进程读取到的数据可以不是最新的，但是任何进程读取的数据的顺序必须和写操作的顺序是一致的。因果一致性
如果一系列写入操作按照某种逻辑发生，那么读取也应该按照这种逻辑顺序读取。即如果 w(b) 依赖于 w(a)，那么用户读取的顺序也应该是 r(a) > r(b)。如果 w(b) 与 w(a)之间没有任何依赖关系，即使在w(a)先于w(b)发生，也有可能先读取到r(a)。因果一致性需要借助于分布式逻辑时钟实现。FIFO 一致性
同一个进程中的写操作，被看到的顺序必须是一致的。不同的进程的写操作被看到的顺序可以不一致，即使相互之间有因果关系。
上面的几种一致性其实是逐步弱化的，但是实现复杂度越来越简单，程序性能也是逐步增强的。
用户为中心
单调读一致性
顺序发起三次read请求，按读取到的数据的更新时间降序排列：r3 >= r2 >= r1，即最近一次读取的数据更新时间肯定不会晚于之前数据的更新事件。单调写一致性
顺序发起三次write请求（w1, w2, w3），这三次请求的执行顺序必须要按照提交(w1 w2 w3)顺序来执行，即最近一次的写请求在执行之前必须要保正它前面的写请求都已经执行完毕。
如果不满足此一致性，可能会出现数据覆盖的问题。写后读一致性
在一次write请求之后，发起read请求，读取的肯定是这次write请求的值。
如果程序不满足的话，如果刚发了条微博，要过一会才能读取到我刚刚发的这条微博。读后写一致性
在发起一次read a请求之后，基于读取到的值a1发起了一次write a2，保证a2是基于a1的。
业务和一致性
在谈一致性的时候，是必须要结合当前业务来看的。我们需要清楚的知道哪种一致性保障满足当前业务的需求。
业务上的一致性
在业务开发时，经常谈到的一致性会经过简化。
强一致性
数据在写入后，在任意时刻都能从所有副本上读取到最新的值。线性一致性
数据在写入成功之后，再次读取到的都是最新的数据。其表现形式在系统的用户看来是强一致性的。共识算法和基于共识算法的额外工作可以实现，tidb是这样实现的。弱一致性
数据在写入后，有的副本可能已经更新，有的副本可能还没更新，不保证经过多长时间，所有的副本才会更新。最终一致性
数据在写入之后，经过一个时间窗口最终所有副本都会达到一致。时间窗口是个非常重要指标。
我认为在谈论一致性的时候，应该结合业务来看，系统对一致性的要求越高就会导致系统实现的复杂度越高。而且在谈论一致性的时候，应该也加上业务的维度。
全局一致性
即我们在保证数据项a一致性的时候，应该对任何访问系统的用户都是一样的保证。
如果不满足此一致性，可能会导致不同的用户查看同一个数据项a的时候看到的结果是不一样的。单一用户一致性
数据一致性保证只是针对单个用户来说，也就是将<用户，数据项>作为一个整体来保证一致性的。
场景
在使用mysql主从的时候，不同的技术方案，可能会导致用户在访问我们的系统时得到不同的结果。这个时候需要结合业务来看，我们的系统应该保障什么样的数据一致性。
微博更新
博客系统