分布式概念：分布式事务（通过分布式消息来确保事务最终一致性）

分布式事务，就是在分布式系统中运行的事务，由多个本地事务组合而成。
例子：
对于网上购物的每一笔订单来说，电商平台一般都会有两个核心步骤：一是订单业务采取下订单操作，二是库存业务采取减库存操作。
通常，这两个业务会运行在不同的机器上，甚至是运行在不同区域的机器上。
针对同一笔订单，当且仅当订单操作和减库存操作一致时，才能保证交易的正确性。也就是说一笔订单，只有这两个操作都完成，才能算做处理成功，否则处理失败。

事务的特征 ACID特征：
原子性（Atomicity）：全部执行成功和全部不执行。
一致性（Consistency）：是指事务操作前和操作后，数据的完整性保持一致或满足完整性约束。如转账，A-200, B+200.
隔离性（Isolation）:指当系统内有多个事务并发执行时，多个事务不会相互干扰.
持久性（Durability):指一个事务完成了，那么它对数据库所做的更新就被永久保存下来了.

Base理论
基本可用（Basically Available）：分布式系统出现故障的时候，允许损失一部分功能的可用性。
柔性状态（Soft State）：在柔性事务中，允许系统存在中间状态，且这个中间状态不会影响系统整体可用性。
最终一致性（Eventual Consistency）：事务在操作过程中可能会由于同步延迟等问题导致不一致，但最终状态下，数据都是一致的。

该理论的一个关键点就是采用最终一致性代替强一致性。

实现分布式事务有以下 3 种基本方法
基于 XA 协议的二阶段提交协议方法；
核心思想：
系统中的事务管理器作为协调者，负责各个本地资源的提交和回滚，资源管理器是分布式事务的参与者；通过投票阶段和提交阶段，协调事务的操作，保持数据的一致性。
缺点：同步阻塞、单点故障、数据不一致、性能低。

三阶段提交协议方法；

缺点：
2PC 和 3PC 这两种方法，有两个共同的缺点，一是都需要锁定资源，降低系统性能；二是，没有解决数据不一致的问题。因此，便有了通过分布式消息来确保事务最终一致性的方案。

基于消息的最终一致性方法

引入了一个消息中间件（Message Queue，MQ），用于在多个应用之间进行消息传递。
核心思想：将事务通过消息或日志方式来异步执行，消息或日志可以保存到本地文件、数据库或消息队列中，再通过业务规则进行失败重试。
特点：最终一致性  异步执行  无同步阻塞问题   无单点故障问题  性能高  
缺点：算法复杂度高

以网上购物为例。假设用户 A 在某电商平台下了一个订单，需要支付 50 元，发现自己的账户余额共 150 元，就使用余额支付，支付成功之后，订单状态修改为支付成功，然后通知仓库发货。
在该事件中，涉及到了订单系统、支付系统、仓库系统，这三个系统是相互独立的应用，通过远程服务进行调用。

用户 A 通过终端手机首先在订单系统上操作流程如下：

1.订单系统把订单消息发给消息中间件，消息状态标记为“待确认”。
2.消息中间件收到消息后，进行消息持久化操作，即在消息存储系统中新增一条状态为“待发送”的消息。
3.消息中间件返回消息持久化结果（成功 / 失败），订单系统根据返回结果判断如何进行业务操作。失败，放弃订单，结束（必要时向上层返回失败结果）；成功，则创建订单。
4.订单操作完成后，把操作结果（成功 / 失败）发送给消息中间件。
5.消息中间件收到业务操作结果后，根据结果进行处理：失败，删除消息存储中的消息，结束；成功，则更新消息存储中的消息状态为“待发送（可发送）”，并执行消息投递。
6.如果消息状态为“可发送”，则 MQ 会将消息发送给支付系统，表示已经创建好订单，需要对订单进行支付。
7.支付系统也按照上述方式进行订单支付操作。订单系统支付完成后，会将支付消息返回给消息中间件，中间件将消息传送给订单系统。订单系统再调用库存系统，进行出货操作。