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

  • 时间:
  • 浏览:6
  • 来源:神彩快3_彩神快3官方

作者:

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

模式分析:A服务将B服务时需的信息通过消息上方件传递给B服务,A服务不需要知道B服务的解决结果。什儿 交互模式下,消息生产者要确保消息发送成功;消息消费者要确保消息消费成功。

注:可能,以上场景和解决方案,不能自己饱含您工作中遇到的场景,欢迎交流,并一起去讨论解决方案。

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

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

解决方案服务被调方最大努力解决方案。可能B服务中请求有落库,什么都有 能都都上能了用定时任务不断重试尽最大努力将请求解决出结果。解决后,将请求情形设置成对应的结果落库。假如再通知A服务可能A服务异步主动查询。

业务场景:适用于非核心链路上负载较高的解决环节,什儿 环节无缘无故 耗时较长,假如对时效性要求不高。类式,用户提现时,账户系统和提现系统的交互(CASE-1);提现系统和三方系统(银行系统可能三方托管系统)的交互(CASE-2)。

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

  3) B服务解决请求要做幂等。

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

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

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

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

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

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

模式分析:A服务同步调用B服务的接口并等待时间结果返回,后续的流程会依赖B服务的返回结果。什儿 交互模式下,A服务得到的结果细分有什儿 情形。

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

  

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

解决方案生产者最大努力通知+消费者最大努力解决方案。

关于TCC,许多人认为,理解原理很糙要。工作中遇到吻合的场景能都都上能了根据原理自行实现,满足业务即可。

:1) B服务通常有的是接受请求并持久化后才返回A服务受理成功。解决服务应用应用进程被杀掉而导致 请求丢失。

:保证幂等性的法律法律依据什么都有 ,根据具体的业务场景,总能很容易找到保证幂等性的法律法律依据。

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