java 分布式 技术方案_分布式系统数据一致性解决方案

1、微服务架构的数据一致性问题

以电商平台为例，当用户下单并支付后，系统需要修改订单的状态并且增加用户积分。由于系统采用的是微服务架构，分离出了支付服务、订单服务和积分服务，每个服务都有独立数据库做数据存储。当用户支付成功后，无论是修改订单状态失败还是增加积分失败，都会造成数据的不一致。

为了解决例子中的数据一致性问题，一个最直接的办法就是考虑数据的强一致性。那么如何保证数据的强一致性呢？我们从关系型数据库的 ACID 理论说起。

关系型数据库具有解决复杂事务场景的能力，关系型数据库的事务满足 ACID 的特性。

Atomicity：原子性(要么都做，要么都不做)

Consistency：一致性(数据库只有一个状态，不存在未确定状态)

Isolation：隔离性(事务之间互不干扰)

Durability： 永久性(事务一旦提交，数据库记录永久不变)

具有 ACID 特性的数据库支持数据的强一致性，保证了数据本身不会出现不一致。

然而微服务架构下，每个微服务都有自己的数据库，导致微服务架构的系统不能简单地满足 ACID，我们就需要寻找微服务架构下的数据一致性解决方案。

微服务架构的系统本身是一种分布式系统，而本文讨论的问题其实也就是分布式事务之数据一致性的问题，我们来聊聊分布式系统的 CAP 理论和 BASE 理论。

CAP 是指在一个分布式系统下， 包含三个要素：Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性)，并且三者不可得兼。

C：Consistency，一致性，所有数据变动都是同步的。

A：Availability，可用性，即在可以接受的时间范围内正确地响应用户请求。

P：Partition tolerance，分区容错性，即某节点或网络分区故障时，系统仍能够提供满足一致性和可用性的服务。

关系型数据库 单节点 保证了数据强一致性(C)和可用性(A)，但是却无法保证分区容错性(P)。

然而在分布式系统下，为了保证模块的分区容错性(P)，只能在数据强一致性(C)和可用性(A)之间做平衡。具体表现为在一定时间内，可能模块之间数据是不一致的，但是通过自动或手动补偿后能够达到最终的一致。

BASE 理论主要是解决 CAP 理论中分布式系统的可用性和一致性不可兼得的问题。BASE 理论包含以下三个要素：

BA：Basically Available，基本可用。

S：Soft State，软状态，状态可以有一段时间不同步。

E：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致。

BASE 模型与 ACID 不同，满足 CAP 理论，通过 牺牲强一致性来保证系统可用性。由于牺牲了强一致性，系统在处理请求的过程中，数据可以存在短时的不一致。

系统在处理业务时，记录每一步的临时状态。当出现异常时，根据状态判断是否继续处理请求或者退回原始状态，从而达到数据的最终一致。

例如，在上面的案例中，支付成功，订单也成功，但增加积分失败，此时，不应回滚支付和订单，而应通过一些 补偿方法 来让积分得以正确地增加。后面会讲到具体的实现方法。

在分享我们的分布式事务实践方案之前，先看看早期解决分布式事务问题的二阶段提交协议。

2、二阶段提交协议

X/Open DTP(Distributed Transaction Process)是一个分布式事务模型，此模型主要使用二阶段提交(2PC，Two-Phase-Commit)来保证分布式事务的完整