最近在使用springboot搭建微服务架构，遇到数据一致性问题，今天就对它进行一个小结。
数据一致性是分布式系统中的一个关键需要解决的问题，虽然分布式系统带来了扩展的弹性，但是带来了数据不一致性的风险，尤其是在不同网络隔离，实现细节透明的业务子系统之间的数据不一致风险会成倍递增。如今衡量一个企业的软件架构是不是有潜力的，那必须得看架构是不是分布式的，也就是说既然分布式架构如此流行，那么数据一致性就提到了一个更高的标准了。
说道分布式架构的数据一致性困难，我们需要充CAP原理讲起。
CAP原理，它就好比分布式领域的牛顿定律。C-Consistent一致性，指前后数据不一致，userA访问数据value1但user2访问同样数据却是value2，数据就不一致了。A-Availability可用性，指用户请求就要给出回应。P-Partition
tolerance分区容错性，指大多数分布式系统都分布在多个子系统，区间通信可能失败，比如两台服务器发生了网络分区，拿着两台服务器无法通信。这三个变量相互制约，对于系统设计的场景分别采取不同的偏重策略。
举个例子吧，分布式系统中系统S1和S2,当S1系统发生写操作，要保证S2的一致性，只有锁定S2的读操作和写操作，锁定期间S2是没有可用性的。这三个变量相互制约为了提高C就会导致A、P降低或不满足，反之亦然。
当然CAP理论已经指明系统要实现完全的一致性和可用性是不可能的，当然在CAP理论基础上又发展了BASE模型和ACID模型等。这两个模型各有优势。
但是在目前比较成熟集中保证数据一致性方法，包括了强一致性、弱一致性和最终一致性。
强一致性，是当一个系统完成了数据更新操作之后，后续关联的子系统也一并完成更新操作。这种决策用户最友好，用户写了什么，就会读到什么。但是根据CAP理论，这种实现牺牲了可用性。成型的技术方案比如springboot的jat+atomikos方案，他通过两阶段提交（XA协议规定）完成数据更新，客户端必须保证按照XA协议完成编写，并且数据库必须是支持XA协议的数据库，通常客户端会将事务处理和业务处理是现在一起。这就带了另一个不足就是带来了事务处理和业务耦合性强增加了复杂度。
弱一致性，是系统不保证后续进程或者线程会访问最新的值。成型的技术方案比如利用消息队列完成数据一致性，S1系统完成数据更新，将更新操作发送到消息队列，S2系统从消息队列中获取事件完成更新操作。这个方案在大厂被广泛的使用，也是比较流行的一种方式。
最终一致性，它是弱一致性的特定形式。如，DNS是一个典型的最终一致性系统。
今天对分布式系统数据一致性做了小结，架构师们在设计的时候做到有的放矢，如何实现在成本利润的最大化。
