Distributed Transactions - Reliability Message & TCC & Best Effort Notification【Collection】

Reproduced distributed transactions

Distributed transaction solution for microservice architecture

Tags: Distributed Transactions Published on 2016-07-16 18:39:05

In the distributed system architecture, the distributed transaction problem is an unavoidable challenge. The popularity of the microservice architecture has made the problem of distributed affairs more and more prominent!

In the following, we will conduct a detailed analysis of the scenarios in which distributed transaction problems may be encountered in the major participant systems in the e-commerce shopping payment process!

images/yCGMB8jPtrsxKWf5PCQBpGCeKZKhzPBb.jpg

As shown in the figure above, it is assumed that the systems of the three participating platforms (e-commerce platform, payment platform, and bank) have been divided into distributed system architecture, and analyzed according to the process steps in the above number:

1. Create an order in the e-commerce platform: reserve inventory, pre-deduct points, lock coupons. At this time, there will be distributed transaction problems between services in the e-commerce platform, because data has to be modified across multiple internal services at this time. ;

2. Create a payment order in the payment platform (select bank card payment): query the account, query the restriction rules, create a payment order and jump to the bank if the conditions are met. At this time, there will be no distributed transaction problem, because there will be no cross-service change data;

3. Create transaction orders in the banking platform: find accounts, create transaction records, determine account balances and deduct money, add points, and notify the payment platform. At this time, there will also be distributed transaction problems (if it is a service-oriented architecture);

4. The payment platform receives the bank deduction result: changing the order status, adding money to the account, adding points to the point account, generating accounting entries, notifying the e-commerce platform, etc. At this time, there will also be distributed transaction problems;

5. The e-commerce platform receives the payment results from the payment platform: changing the order status, deducting inventory, deducting points, using coupons, increasing consumption points, etc., the calls between services within the system will also encounter distributed problems;

 

images/K4QcRFdKnbkT44AFFtzQYCAAX25FifDS.jpg

As shown in the figure above, the internal processing flow after the payment platform receives the bank deduction result:

1. The payment gateway of the payment platform verifies the result of the bank notification, and then calls the payment order service to execute the payment order processing;

2. The payment order service changes the status of the payment order according to the bank deduction result;

3. Call the fund account service to add money to the merchant account of the e-commerce platform (in the actual process, there may be various cost billing; if it is a balance payment, it may also be deducted from the user account at the same time to add money to the merchant account );

4. Call the point service to add points to the user's point account;

5. Call the accounting service to write the original transaction voucher to the accounting (financial) system to generate accounting entries;

6. Call the notification service to notify the e-commerce platform of the payment processing result;

 

images/b387t8iM6nsBkNfbztBABaCRChTWc3Bd.jpg

如上图,把支付系统中的银行扣款成功回调处理流程提取出来,对应的分布式事务问题的代码场景:

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

@Transactional(rollbackFor = Exception.class)

public void completeOrder() {

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

accountService.update();  // 调用资金账户服务给资金帐户加款

pointService.update();  // 调用积分服务给积分帐户增加积分

accountingService.insert();  // 调用会计服务向会计系统写入会计原始凭证

merchantNotifyService.notify();  // 调用商户通知服务向商户发送支付结果通知

}

本地事务控制还可行吗?

以上分布式事务问题,需要多种分布式事务解决方案来进行处理。

订单处理:本地事务

 

资金账户加款、积分账户增加积分:

TCC型事务

(或两阶段提交型事务),实时性要求比较高,数据必须可靠。

TCC每项操作需要做的事情如下:

1、Try:尝试执行业务。

  • 完成所有业务检查(一致性)
  • 预留必须业务资源(准隔离性)

2、Confirm:确认执行业务。

  • 真正执行业务
  • 不做任何业务检查
  • 只使用Try阶段预留的业务资源

3、Cancel:取消执行业务

  • 释放Try阶段预留的业务资源

       用一张图来说明TCC的机制:

 

会计记账:

异步确保型事务

基于可靠消息的最终一致性,可以异步,但数据绝对不能丢,而且一定要记账成功)

 

 


 

 

商户通知:

最大努力通知型事务

(按规律进行通知,不保证数据一定能通知成功,但会提供可查询操作接口进行核对)

 

 

 

In response to the above distributed transaction problems, the video tutorial "Distributed Transaction Solutions for Microservice Architecture" by Longguo College ( http://www.roncoo.com ) will provide detailed and complete solutions for everyone to learn and apply

 

 



 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326442499&siteId=291194637