强一致性：无论更新在哪个副本上，之后对操作都要能够获取最新数据。多副本数据就需要分布式事物来保证数据一致性了（这就是问什么项目里面经常提到的原因）
最终一致性：在这种约束下保证用户最终能读取到最新数据。举几个例子：
因果一致性：A、B、C三个独立进程，A修改了数据并通知了B，这时候B得到的是最新数据。因为A没通知C，所以C不是最新数据
会话一致性：用户自己提交更新，他可以在会话结束前获取更新数据，会话结束后（其他用户）可能不是最新的数据（提交后JQ修改下本地值，不能保证数据最新）
读自写一致性：和上面差不多，只是不局限在会话中了。用户更新数据后他自己获取最新数据，其他用户可能不是最新数据（一定延迟）
单调读一致性：用户读取某个数值，后续操作不会读取到比这个数据还早的版本（新的程度>=读取的值）
单调写一致性（时间轴一致性）：所有数据库的所有副本按照相同顺序执行所有更新操作（有点像Redis的AOF）
2.4.一致性实现方法 Quorum系统NRW策略（常用）Quorum是集合A，A是全集U的子集，A中任意取集合B、C，他们两者都存在交集。
NRW算法：
N：表示数据所具有的副本数。
R：表示完成读操作所需要读取的最小副本数（一次读操作所需参与的最小节点数）
W：表示完成写操作所需要写入的最小副本数（一次写操作所需要参与的最小节点数）
只需要保证R + W > N就可以保证强一致性（读取数据的节点和被同步写入的节点是有重叠的）比如：N=3，W=2，R=2（有一个节点是读+写）
扩展：
关系型数据库中，如果N=2，可以设置W=2，R=1（写耗性能一点），这时候系统需要两个节点上数据都完成更新才能确认结果并返回给用户
如果R + W <= N，这时候读写不会在一个节点上同时出现，系统只能保证最终一致性。副本达到一致性的时间依赖于系统异步更新的方式，不一致性时间=从更新节点～所有节点都异步更新完毕的耗时
R和W设置直接影响系统的性能、扩展和一致性：
如果W设置为1，那么一个副本更新完就返回给用户，然后通过异步机制更新剩余的N-W个节点
如果R设置为1，只要有一个副本被读取就可以完成读操作，R和W的值如果较小会影响一致性，较大会影响性能
当W=1，R=N==>系统对写要求高，但读操作会比较慢（N个节点里面有1个挂了，读就完成不了了）
当R=1，W=N==>系统对读操作有高要求，但写性能就低了（N个节点里面有1个挂了，写就完成不了了）
常用方法：一般设置R = W = N/2 + 1，这样性价比高，eg：N=3，W=2，R=2（3个节点==>1写,1读，1读写）
参考文章：
https://blog.csdn.net/jeffsmish/article/details/54171812 时间轴策略（常用）主要是关系型数据库的日记==>记录事物操作，方便数据恢复
还有就是并行数据存储的时候，由于数据是分散存储在不同节点的，对于同一节点来说只要关心数据更新+消息通信（数据同步）：
保证较晚发生的更新时间>较早发生的更新时间
消息接收时间 > 消息发送时刻的时间（要考虑服务器时间差的问题～时间同步服务器）
其他策略其实还有很多策略来保证，这些概念的对象逆天不是很熟~比如：向量时钟策略
推荐几篇文章：
https://www.cnblogs.com/yanghuahui/p/3767365.html https://blog.csdn.net/dellme99/article/details/16845991 https://blog.csdn.net/blakeFez/article/details/48321323