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

  • 时间:
  • 浏览:3
  • 来源:uu快3官网app_uu快3豹子赚钱

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

:1) B服务通常前会 接受请求并持久化后才返回A服务受理成功。处里服务守护程序运行运行被杀掉而意味着请求丢失。

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

模式分析:A服务同步调用B服务的接口并听候结果返回,后续的流程会依赖B服务的返回结果。你并与非 交互模式下,A服务得到的结果细分有并与非 生活情况。

业务场景:适用于非核心链路上负载较高的处里环节,你并与非 环节总是耗时较长,就让 对时效性要求不高。累似 ,用户提现时,账户系统和提现系统的交互(CASE-1);提现系统和三方系统(银行系统将会三方托管系统)的交互(CASE-2)。

:保证幂等性的土措施好多好多 ,根据具体的业务场景,总能很容易找到保证幂等性的土措施。

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

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

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

  

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

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

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

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

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

注:将会,以上场景和处里方案,很难暗含您工作中遇到的场景,欢迎交流,并一起讨论处里方案。

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

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

愿景:愿守护程序运行运行员皆因喜欢而编程

模式分析:A服务调用B服务,B服务先受理请求并落库,情况是待处里。B服务处里请求很耗时,将会要依赖就让 的服务。B服务处里就让 通知A服务将会A服务定时去查询B服务的处里结果。你并与非 交互模式下,对于CASE-1,第1步和第2步同接口同步调用模式,第3步同消息异步处里模式;对于CASE-2,离米 两次接口同步调用模式

作者:

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

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

  所谓分布式服务,好多好多 把就让 通过本地接口交互的模块,拆分成单独的应用独立部署,并通过远程接口和网络消息交互。且不管原先说严不严密,正不正确,理解就好。本文的重点也前会 你并与非 话题。简单画一张图辅助理解,如图。集中式架构,要想保证订单表和库存表的一致性,就让 有有2个本地事务(ACID)就能保证两者的强一致性。分布式架构,订单表由订单服务操作,库存表由库存服务操作。要想保证订单表和库存表的一致性,没法就需用保证订单服务对订单表的操作和库存服务对库存表的操作同事成功。就让 的有有2个本地事务就变成了有有2个分布式事务。将会服务之间通过网络交互+网络异常是常态,就会产生服务间数据不一致的情况。这就涉及有有2个分布式事务一致性的问題图片。

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