亚博代理 分布式交易最终一致性的通用解决方案

日期:2021-04-01 05:11:03 浏览量: 67

当前的应用程序系统pg电子 ,无论是企业级应用程序还是Internet应用程序,最终的数据一致性都是每个应用程序系统都必须面对的问题。随着分布式的逐渐普及,数据一致性变得更加困难,但同时也非常困难。很难找到一个万能的解决方案,并且不能通过引入特定的中间件或特定的开源框架来解决。它更多地取决于业务场景,并根据场景提供解决方案。基于作者近几年的理解,我总结了几点。在对更多的应用程序系统进行编码时澳洲幸运20官网 ,他们会更加注意数据的一致性,从而使系统更加健壮。

一、基本理论

当前,有关事务的几种主要理论包括:ACID事务特征,CAP分布式理论和BASE。 ACID反映在数据库事务中,而CAP和BASE是分布式事务的理论。诸如订单管理(例如仓库管理)之类的业务系统相结合可以从这些理论中学习以解决问题。

1、 ACID功能

2、 CAP功能

3、 BASE功能

二、最终一致性的常用做法

分布式事务最终一致性

1、单个数据库事务

如果应用程序系统是单个数据库,则这是一个很好的保证。使用数据库的事务特征来满足事务的一致性。这时,一致性就是强一致性。对于Java应用程序系统华体会app官方下载 ,很少会通过事务的开始,提交和回滚直接对其进行硬编码,并且大多数都由spring事务模板或声明性事务来保证;

2、多数据库事务

mysql 存储过程 事务提交事务_分布式事务最终一致性_随机变量一致可积性

对于多数据库事务,可以根据两阶段提交协议由spring 3. 0 + Atomikos + JTA支持;

3、基于事务性消息队列的最终一致性

借助消息队列,在处理业务逻辑的地方发送消息。成功处理业务逻辑后,提交消息以确保成功发送消息。然后,将发送消息队列进行处理。如果成功,它将结束。如果不成功,请重试银河体育app ,直到成功为止亚博直播 ,但仅适用于业务逻辑中第一阶段成功而第二阶段必须成功的场景。对应于上图中的C进程。

4、基于消息队列和定时补偿机制的最终一致性

前面部分和上面基于事务性消息的队列之间的区别在于,第二阶段中的重试不再是消息中间件本身的重试逻辑,而是一个单独的补偿任务机制。实际上,在大多数逻辑中,第二阶段失败的可能性相对较小,因此独立补偿任务列表可以更清晰,直到当前有多少个任务失败为止,也可以更加清晰。对应于上图中的E程序。

5、异步回调机制的介绍

A应用程序调用B。在同步调用的返回结果中,B将成功返回给A。通常,它在此时结束。实际上,在9 9. 99%的情况下可以,但是为了确保100%,在系统设计中至少要记住100%。这时,系统B将回叫A并告诉A您调用了我的逻辑,这确实成功了。实际上,此逻辑与TCP协议中的三向握手非常相似。上图中的B程序。

6、类似于双重检查机制的确认机制

这是上图中的异步回调过程。 A同步调用B,B成功返回。此呼叫已结束,但为了使A确保经过一段时间后,此时间可能是几秒钟,或者每天可以定期进行处理,然后再次呼叫B以检查上一次呼叫是否成功。例如,A调用B来更新订单状态。这次成功了。几秒钟的延迟后,A询问B以确认状态是否就是他所期望的。上图中的D进程。

三、分布式事务的缺点

随机变量一致可积性_mysql 存储过程 事务提交事务_分布式事务最终一致性

1、两阶段提交协议的缺点

两阶段提交涉及多个节点之间的网络通信。如果通信时间太长,则事务的相对时间将太长,并且锁定资源的时间将很长。在高度并发的服务中,它将存在严重的性能瓶颈

2、消息队列

在高并发环境中,我们通常使用消息队列来避免执行分布式事务。

使用消息队列时,我们需要保存可靠的凭据(分布式事务消息)分布式事务最终一致性分布式事务最终一致性,有以下几种方法:

以支付宝和余额宝为例。

支付宝完成扣款后,将记录消息数据并将消息数据和业务数据存储在同一数据库实例中。

Begin Transaction
  update A set amount=amount-1000 where uid=100;
  insert into message(uid,amount,status) values (1,1000,1)
End Transaction
Commit;

及时将已完成支付宝扣除的消息发送给余额宝。余额宝完成处理后,将返回成功消息。支付宝收到消息后,将删除消息表中的相应消息记录以完成此扣除。 p>

分布式事务最终一致性

传统方式是,我已完成,我会向您发送一条消息。一致性解决方案意味着我将首先向您发送消息,然后与您确认我已完成。这是带有事务的改进的消息中间件。

请参阅: