使用内存池的json

在分布式系统架构中，分布式事务问题是不可避免的挑战。微服务架构的流行，让分布式事务的问题越来越凸显出来！

下面我们就电商购物支付过程中关键参与者的系统可能出现分布式事务问题的场景进行详细分析！

如上，假设三大参与平台（电商平台、支付平台、银行）工作）有一个分布式系统架构。按照上号中的流程步骤来划分分析：

1在电商平台创建订单：预留库存、预扣积分、大额优惠券，下面这个会在每个service电商平台可能存在分布式事务问题，因为此时需要跨多个内部服务更改数据；

2.在支付平台创建支付订单（选择银行卡支付）：查询账户、查询限制规则。如果满足条件，创建付款单并跳转到银行。此时，不会出现分布式事务问题，因为数据不会被修改服务；

3.在银行平台创建交易订单：搜索账户、创建交易记录、确定余额并提取资金，并通知支付平台此时出现的问题（如果是面向服务的架构）；4.支付平台接收银行的付款。扣款结果：改变订单状态、充值到账户、添加积分、创建积分账户、创建记账分录、通知电商平台等，此时也会出现分布式交易问题；

5.电商平台接收支付平台发送的支付结果：改变订单状态、扣库存、扣积分、使用优惠券、增加消费积分等。系统内服务之间调用时也会出现分布式交易问题；

如上所示，支付平台收到银行扣款结果后内部处理流程为：

1支付网关支付平台与银行进行沟通。通知结果进行验证，然后进入支付订单服务进行支付订单处理。

2支付订单服务根据银行扣款结果改变支付订单状态。

3服务向电商平台商户账户充值（实际过程中可能会产生各种成本费用；如果是余额支付，也可以从用户账户中扣除，添加到商家帐户）。同时）；

4.调用积分服务为用户的积分账户添加积分；

5.调用会计服务将原始交易凭证写入会计）会计分录生成系统；

6．进入通知服务，通知电商平台支付处理结果

如上图，支付系统中的银行扣款已成功调用。流程提取出来，分布式事务问题对应的代码场景为：

/**支付订单处理**。/

@Transactional(rollbackFor=)

publicvoidcompleteOrder(){

();//订单服务本地更新订单状态

();//调用资金账户服务添加积分

();积分账户

();//调用记账服务将原始记账信息写入记账系统。

();商户通知服务，向商户发送支付结果通知

}

本地交易控制是否仍然可行？

上述分布式事务问题需要多种分布式事务解决方案。

订单处理：地方事务

资金账户充值、积分评分账户中添加：TCC事务（或两阶段提交事务），实时性要求比较高，数据必须可靠。

记账：异步保证事务（基于可靠消息的最终一致性，可以异步，但数据不能丢失）。，并且计费必须成功）

商户通知：BestEffort通知类型交易（按规则通知，不保证数据正确）通知成功），但提供查询操作接口进行验证）