分布式理论之数据一致性总结

总结
1、一致性的种类：事务一致性、数据一致性
2、数据一致性程度分级：强一致性、弱一致性、最终一致性
3、CAP定理：一个分布式系统，无法同时满足 强一致性、可用性、分区容错性
4、BASE理论核心思想：强一致性的CAP无法满足，可以根据业务特点实现最终一致性。
5、BASE理论：基本可用、软状态、最终一致性

一、什么是分布式数据一致性

分布式数据一致性，就是数据在多份副本中存储时，保证各个副本中的数据是一致的。一致性还分为事物一致性就是ACID那套，这里讨论的是数据一致性

1.1 数据一致性分类

多副本分布式系统，需要副本间数据保持一致，就需要进行数据同步。而且又因为网络延迟等因素，几乎没办法保证同时更新所有机器中包括备份的所有数据。就会出现数据不一致！

1.2 一致性分级

为了平衡系统性能同时保证数据的一致性，人们对数据一致性做了分级。因为对于不同的业务系统，对一致性的要求并不相同。

• 强一致性 最符合用户直觉，写入成功后所有副本立即读出最新的数据。即在某个时间点，整个系统所有节点的状态或数据是相同的。这种一致性通常通过基于分布式哈希表或其他一致性算法来实现。但是实现难度最大，且对系统性能影响很大。强一致性，也叫线性一致性。
  • 任何一次读都是最新数据。即写入是同步的
  • 系统中所有进程，看到的操作顺序和全局时钟顺序一致。A完成时间小于B那么B一定能看见A的结果。
• 顺序一致性 每次读取都能读取到最近一次写入的数据，系统间所有的数据状态变化顺序一致，但是不需要和全局时钟顺序保持一致。
• 弱一致性数据写入后，不会承诺立即可以读取到最新的数据，也不保证多久后达到一致。但是尽可能地保证某个时间级别后，数据达到一致状态。即副本之间异步同步。
• 最终一致性不保证在任意时刻节点上的同一份数据是相同的，但是随着时间推移，不同节点上的同一份数据总是在向趋同的方向变化。最终一致性也属于弱一致性的一种最终一段时间后，数据达到一致状态。最终一致性根据更新数据后各进程访问到数据的时间和方式的不同有下面这些分类。
  • 因果一致性（Casual Consistency） 如果进程A通知进程B它已经更新了一个数据，那么进程B后续访问将返回更新后的值，且一次写入保证替代前一次写入。与进程A无因果关系的进程C访问则遵循一般的最终一致性规则。
  • 读己之所写(reead-your-writes) 当进程A自己更新一个数据项后，它总是发昂问道更新过的值，绝对不会看到旧址。例如发推特总是保证先看到自己刚发的推特，其他的推特则可以有一定延迟。也称为读写一致性。
  • 会话一致性这是读己之所写模型的一个版本，他把访问存储系统的进程放在会话上下文中，如果会话因异常终止，则不保证读己之所写一致性。如果会话还在，则保证了读己之所写一致性。
  • 单调（Monotonic）读一致性如果进程已经看到过某个数据对象的某个值，那么后续任何访问都不会返回那个值之前的值
  • 单调写一致性 系统保证来自同一个进程的写操作顺序执行。要是系统这种程度的一致性都保证不了，就很难编程。
    
    
    

二、CAP定理

2.1 CAP定理(CAP theorem)

也被称为布鲁尔定理(Brewer’s theorem)，他指出了对于一个分布式系统来说，不可能同时满足 一致性、可用性、和分区容错性三点，最多只能同时实现两点，不可能三者兼顾。

选项	具体意义
一致性(Consistency)	指上面说的强一致性，所有的副本都是同一份最新的数据。
可用性(Availability)	系统中非故障节点收到的每个请求都必须有响应，在可用的系统中，客户端的每次请求都必须最终响应不允许忽略。并且应该能够在某个节点或者整个系统出现故障时，快速地恢复
分区容错性(Partition tolerance)	当某个节点或者部分节点发生故障时，系统仍然能够继续运行，并且不会出现数据丢失或者不一致的情况。这是因为在分布式系统中，节点之间需要进行频繁的通信和同步，以保证数据的一致性。如果节点之间的通信和同步不够及时或者出现延迟，就可能导致数据不一致的情况。

2.2 CAP定理的论证

为什么不能同时满足三个条件
首先假设分布式系统中存在两个分区 G1 G2,两个分区之间能正常进行数据同步。

1. 假设此时G1和G2的通信断开，此时要求满足分区容错性，G1和G2仍然继续运作。
2. 此时G1收到数据更新的请求，因为通信断开无法同步给G2
3. 如果要满足可用性，那么G1和G2都要能返回数据，此时就牺牲了数据的一致性
4. 如果要满足一致性，那么G1和G2在通信断开后，就应该阻塞等待网络回复，此时又无法满足系统可用性。
5. 上面几点说明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。也就是说分布式系统不可能同时满足三个特性。

CAP三者三选二利弊分析

三选二方案	分析
CA 一致性和可用性	非常严格的要求一致的协议，保证强一致性和可用性，但是不保证分区容错性，也就是不进行分区节点部署，或者是分区节点通信出现问题就拒接更新请求，来保证一致性。
CP 一致性和分区容错性	1. 情况1 系统关注数据一致性，舍弃可用性。少数分区节点在没有达到数据一致性之前，会变成不可用的状态，2. 情况2 满足分区容错性和一致性，如果因为节点通信故障导致故障则系统陷入等待，舍弃可用性。
AP 分区容错性和可用性	放弃数据一致性，一旦发生网络分区(通信故障)，节点间失去联系则节点只使用本地数据提供服务，这样数据一致性得不到保证，但是可以保证服务的可用性。

总结：

1. 现如今大型互联网应用主机众多，部署分散所以节点越来越多，所以分区容错性是一定要考虑的问题。所以系统只能在C和A之间取舍。
2. 对于某些系统，例如金融系统 C 则是一定要保证的，出现网络故障系统宁可停止服务。
3. 没有最好的策略，好的系统应该是根据业务场景来进行架构设计的，只有适合的才是最好的。
   
   

2.3 BASE理论

eBay 公司的工程师 Dan Pritchett 曾提出了一种分布式存储系统的设计模式——BASE 理论。

BASE理论出现 因为CAP定理中CAP不可能同时满足，而对于大型的分布式系统来说，分区容错性P于是必须的。如果系统能同时实现CAP是最好不过的了，但是这显然不太可能。于是又出现了一种新的理论——BASE理论。
BASE理论全称是 Basically Avaliable（基本可用）、Soft state(软状态)、和 Eventually consistent 最终一致性。
BASE核心思想 既然无法做到强一致性，但是每个应用都可以根据自身的业务特点，采用适当的方式来使得系统达到最终一致性。BASE 理论是对CAP中一致性和可用性权衡的结果，是基于CAP演化而来的。

1. Basically Available 基本可用 假设系统出现了不可预知的故障，但是仍能继续使用。但是对比正常的系统可能会有一些响应时间或者功能上的损失。例如原本0.5s返回响应，增加到1s返回，抢购秒杀场景下为了系统稳定性，对部分用户请求进行降级引导到降级页面。
2. Soft state 软状态 相对原子性而言,要求同一时刻多个节点副本都是一致，这是一种硬状态，软状态是指允许系统中存在着中间状态。并且认为该状态不会影响系统的可用性。即允许你系统的多个不同节点数据副本存在数据延时。
3. Eventually consistent 最终一致性 上面所说的软状态，其实就是允许系统数据不一致的状态，但是最终必须在一定期限后达到最终一致性状态。这个期限取决于网络延时、消息负载、系统数据同步方案等等因素。