分布式事务一致性解决方案

  • 时间:
  • 浏览:1
  • 来源:大发彩神6合_大发神彩6合官方

业务场景:消息异步处置模式与接口异步调用模式类事于,多应用于非核心链路上负载较高的处置环节中,井且服务的上游不关心下游的处置结果,下游就是时需向上游返回处置结果。类事于,在电商系统中,用户下订单支付且交易成功后,发送消息给物流系统不可能 账务系统进行后续的处置。

注:不可能 ,以上场景和处置方案,真难暗含您工作中遇到的场景,欢迎交流,并同時 讨论处置方案。

使命:为中华软件之崛起而编程

业务场景:适用于大规模、高并发的短小操作且依赖返回值的场景。类事于,交易服务和库存服务(卡券服务、红包服务等)的交互、用户登录和准入服务的交互等。

  3) B服务处置请求要做幂等。

愿景:愿应用应用程序员皆因喜欢而编程

  2) 支持事务消息里面件之RocketMQ:https://rocketmq.apache.org/docs/quick-start。

业务场景:适用于非核心链路上负载较高的处置环节,一些环节总爱耗时较长,以后对时效性要求不高。类事于,用户提现时,账户系统和提现系统的交互(CASE-1);提现系统和三方系统(银行系统不可能 三方托管系统)的交互(CASE-2)。

  所谓分布式服务,就是把以后通过本地接口交互的模块,拆分成单独的应用独立部署,并通过远程接口和网络消息交互。且不管原先说严不政治定力 ,正不正确,理解就好。本文的重点也全部就有一些话题。简单画一张图辅助理解,如图。集中式架构,要想保证订单表和库存表的一致性,以后有有两个 本地事务(ACID)就能保证两者的强一致性。分布式架构,订单表由订单服务操作,库存表由库存服务操作。要想保证订单表和库存表的一致性,越来越就时需保证订单服务对订单表的操作和库存服务对库存表的操作同事成功。以后的有有两个 本地事务就变成了有有两个 分布式事务。不可能 服务之间通过网络交互+网络异常是常态,就会产生服务间数据不一致的情況。这就涉及有有两个 分布式事务一致性的问提报告 。

:1) 查询重试后依然失败(极少),报警,人工处置不可能 准实时对账系统自动校准;

处置方案服务被调方最大努力处置方案。不可能 B服务中请求有落库,一些时需用定时任务不断重试尽最大努力将请求处置出结果。处置后,将请求情況设置成对应的结果落库。以后再通知A服务不可能 A服务异步主动查询。

模式分析:A服务调用B服务,B服务先受理请求并落库,情況是待处置。B服务处置请求很耗时,不可能 要依赖一些的服务。B服务处置以后通知A服务不可能 A服务定时去查询B服务的处置结果。一些交互模式下,对于CASE-1,第1步和第2步同接口同步调用模式,第3步同消息异步处置模式;对于CASE-2,至少两次接口同步调用模式

作者:

  2) 重试次数不宜多,甚至只重试一次;

:保证幂等性的最好的土办法一些,根据具体的业务场景,总能很容易找到保证幂等性的最好的土办法。

模式分析:A服务将B服务时需的信息通过消息里面件传递给B服务,A服务不不知道B服务的处置结果。一些交互模式下,消息生产者要确保消息发送成功;消息消费者要确保消息消费成功。

  一致性问提报告 ,“万恶之源”是数据冗余和分布并通过网络交互+网络异常是常态。

:1) B服务通常全部就有接受请求并持久化后才返回A服务受理成功。处置服务应用应用程序被杀掉而是因为请求丢失。

  

  2) 不管是第(1,2)两步还是CASE-2中的第(3,4)两步,不可能 查询重试失败,时需落库,用定时任务处置,知道成功。反正不像接口同步调用模式,A服务不时需实时的结果。

:1) 定时任务重试发送消息和消息服务器重发未ACK的消息一般全部就有时间阶梯式的(2n*时间间隔);

关于TCC,一些人认为,理解原理怪怪的要。工作中遇到吻合的场景时需根据原理自行实现,满足业务即可。

模式分析:A服务同步调用B服务的接口并等候结果返回,后续的流程会依赖B服务的返回结果。一些交互模式下,A服务得到的结果细分有三种情況。

处置方案:方案一,服务调用方查询重试方案;方案二,TCC方案。

处置方案生产者最大努力通知+消费者最大努力处置方案。