分布式领域CAP理论告诉我们，任何一个分布式系统都无法同时满足Consistency(一致性),Availability(可用性), Partition tolerance(分区容错性) 这三个基本需求。最多只能满足其中两项。 但是，一个分布式系统无论在CAP三者之间如何权衡，都无法彻底放弃一致性(Consistency)，如果真的放弃一致性，那么就说明这个系统中的数据根本不可信，数据也就没有意义，那么这个系统也就没有任何价值可言。所以，无论如何，分布式系统的一致性问题都需要重点关注。

对于一个分布式系统不可能放弃一致性，那么为什么有的架构师还说在某些场景中可以牺牲一致性呢？通常这里说的放弃一致性指的是放弃数据的强一致性。

数据一致性问题的来源

在分布式系统中，由于采用多机器进行分布式部署的方式提供服务，必然存在着数据的复制需求。主要来源于以下两个原因：

1、可用性：将数据复制到分布式部署的多台机器中，可以消除单点故障。防止系统由于某些机器宕机导致的不可用。

2、性能：通过负载均衡技术，能够让分布在不同地方的数据副本全都对外提供服务。有效提高系统性能。

因此，在引入复制机制后，不同的数据节点之间很容易由于网络延时等原因产生数据不一致的情况。

一个系统如果想保证数据一致性很有可能影响其性能，因为并发的写请求需要在前一个写请求结束之后才能进行。因此，如何能既保证数据一致性，又保证系统的性能，是每一个分布式系统都需要重点考虑和权衡的。

数据一致性模型

1、强一致性

当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。但是这种实现对性能影响较大。

2、弱一致性

系统并不保证后续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。但会尽可能保证在某个时间级别(比如秒级别)之后，可以让数据达到一致性状态。

3、最终一致性

弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟、系统负载和复制副本的个数影响。DNS是一个典型的最终一致性系统。

4、最终一致性模型的变种

• 因果一致性：如果A进程在更新之后向B进程通知更新的完成，那么B的访问操作将会返回更新的值。如果没有因果关系的C进程将会遵循最终一致性的规则。 
• 读己所写一致性：因果一致性的特定形式。一个进程总可以读到自己更新的数据。 
• 会话一致性：读己所写一致性的特定形式。进程在访问存储系统同一个会话内，系统保证该进程读己之所写。 
• 单调读一致性：如果一个进程已经读取到一个特定值，那么该进程不会读取到该值以前的任何值。 
• 单调写一致性：系统保证对同一个进程的写操作串行化。