数据一致性
数据一致性 包括缓存和数据库间的一致性，数据库间或者异构数据库间等；
强/弱一致性
强一致性==线性一致性；
定义为：一个client读到最新的值后。其他任何client都不可以读到更旧的值；满足：
- 有一个整体上的顺序；
- 实时匹配，即第一个操作必须在第二个操作前完成；
- 读操作必须返回最后一次写入的结果；
比如raft，写请求时，leader需要确认大多数并提交后才返回响应，而对于读请求，如果返回请求节点自身的最新结果，则不满足线性一致性，场景：leader满足大多数后提交写请求，此时客户端请求的follower节点，还没有同步这个最新提交的日志条目时，就会返回旧数据；当然，让读请求也满足线性一致性的一种简单的做法就是将读请求也写入日志，即保证当日志条目被提交时，说明被请求的节点一定为大多数中的一员（逻辑上，请求最后是leader处理），此时的数据一定是最新的；
etcd默认满足线性一致性，即读请求也需要大多数节点确认；
如果写请求时，leader写入成功后直接返回，follower异步更新复制，即为弱一致性；
顺序一致性：个人感觉不算是强一致性，它仅保证各节点分别的按照时间排序的一致性，但相互之间不一定是一致的，通俗来说，顺序一致性可以有多条顺序相同的时间线，但线性一致性在此基础上只有一条顺序相同的时间线，有确定的开始和终止时间，而顺序一致性仅需要满足顺序相同即可；
半同步：一个follower和leader同步后就返回响应给客户端，其他follower异步更新复制，保证同时有两个节点有最新数据；
最终一致性：从节点异步同步数据，客户端请求从节点时可能读取到过期数据，但从节点始终会完成同步；
延时双删
主从架构中，一般程序改完数据库就删缓存的话，数据库主从同步还没有完成，换句话说可能有客户端请求从库拿到旧数据并更新到缓存中，这样就造成了数据不一致；
延时双删就是等待主从同步，理想情况下延时后主从同步完成，再删一次缓存，后面的就是一致的数据了，实际上延时时间不好确定；主要没办法确定主从同步的准确完成时间（使用mysql的SHOW SLAVE STATUS，获取主从延迟，一定程度上判断同步是否完成）；
但个人感觉这个做法有点怪，，，感觉像是临时解决方案，不太推荐使用？
缓存一致性和分布式事务一致性有什么不一样？
1、出问题时，前者的影响小于后者，缓存有过期时间纠正，后者如果想纠正就很麻烦，涉及源库是谁等问题；
2、后者在概念上可以包括前者；
注：后面补充了一些数据一致性的文章，就不冗余更新在本文了，我会补上部分的链接；