分布式服务的事务如何处理?比如dubbo,服务与服务之间的事务怎么处理比较好,现在有没有开源的解决方案?

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

阅读(

)

) 评论(

都不还还可不能否 设想另有有有2个最简单的分布式事务场景,对于跨银行的转账操作,该操作涉及到调用另有有有2个异地的Service服务,另有有有2个是本地提供的取款服务,另有有有2个是目标银行提供的存款服务,该另有有有2个服务这名 无请况且独立,构成另有有有2个完正的事务。对于事务的处里初步分析:

异地银行存款操作不应该长久地总出 异常而无法使用,而是 一旦发现异常亲们都不还还可不能否 很快了 了 的处里,消息上面件中异常服务自然会进行重试以保证事务的最终一致性。这名 措施假设什么的问题一定都不还还可不能否 处里,在不还还可不能否 万不得已的请况下本地的取款服务一般不进行可逆操作。

关于SOA分布式事务请况参考:http://wenku.baidu.com/view/be946bec0975f46527d3e104.html

首先是不建议采用XA两阶段提交措施去处里分布式事务,要知道要要能支持XA分布式事务,不还还可不能否 是要实现XA规范才都不还还可不能否 ,而Service这名 是无请况的,原应从前去做了等于是把Service內部的东西暴露了出去。对于分布式事务措施还是事务补偿原应BASE基于消息的最终一致性。

在上面的例子来看,原应采用事务补偿机制,基本都不还还可不能否 是做到准实时的补偿,无需有越多的影响。而原应采用基于消息的最终一致性措施,则原应整个周期比较长,不还还可不能否 较长的时间要能给得到最终的一致性。比如周六转款,客户原应下周一才得到通知转账不成功而进行了回退,不还还可不能否 就必不还还可不能否 考虑客户否是能给忍受。

进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

关于否是都不还还可不能否 补偿的什么的问题 在这里亲们谈的是多个跨系统的业务服务组合成另有有有2个分布式事务,而是 在对事务进行补偿的前一天必不还还可不能否 考虑客户不还还可不能否 的否是一定是最终一致性。客户对上面阶段总出 的不一致的承受度是如何的。

posted @

在这名 请况下以上面例子来说,首先调用取款服务,完正调用成功并返回,数据原应持久化。而是 调用异地的存款服务,原应也调用成功,则这名 无任何什么的问题。原应调用失败,则不还还可不能否 调用本地注册的逆向服务(本地存款服务),原应本地存款服务调用失败,则不还还可不能否 考虑重试,原应约定重试次数仍然不成功,则不还还可不能否 log到完正的不一致信息。也都不还还可不能否 是将本地存款服务作为消息发送到消息上面件,由消息上面件接管后续操作。

作者:何明璐

链接:http://www.zhihu.com/question/29483490/answer/98237582

来源:知乎

著作权归作者所有,转载请联系作者获得授权。

版权声明:本文内容由互联网用户自发贡献,版权归作者所有,本社区不拥有所有权,而是 承担相关法律责任。原应您发现本社区含高涉嫌抄袭的内容,欢迎发送邮件至:

基于消息的最终一致性 在这里首真难回答的是亲们不还还可不能否 时实时一致性还是最终一致性的什么的问题,原应不还还可不能否 的是最终一致性,不还还可不能否 BASE策略中的基于消息的最终一致性是比较好的处里方案。这名 方案真正实现了另有有有2个服务的真正解耦,解耦的关键而是 异步消息和消息持久化机制。

在上面措施中都不还还可不能否 看一遍不还还可不能否 手工编写絮状的代码来处里以保证事务的完正性,亲们都不还还可不能否 考虑实现另有有有2个通用的事务管理器,实现事务链和事务上下文的管理。对于事务链上的任何另有有有2个服务正向和逆向操作均在事务管理和协同器上注册,由事务管理器接管所有的事务补偿和回滚操作。

原应解耦,亲们看一遍客户得到成功返回的前一天,原应是上面这名 请况则异地卡马上就能查询账户存款增加。而第二种请况则不一定,原应这名 是这名 异步处里机制。消息上面件得到消息都在去对消息解析,而是 调用异地银行提供的存款服务进行存款,原应服务调用失败则进行重试。

其次对于前面讨论,原应真正不还还可不能否 的是实时的一致性,不还还可不能否 即使采用事务补偿机制,也无法达到实时的一致性。即很原应在另有有有2个业务服务调用上面,客户前台业务操作对持久化的数据进行了其它额外的操作。在这名 模式下,亲们不得不考虑不还还可不能否 在数据库表增加业务请况锁的什么的问题,即整个事务不还还可不能否 完正提交并成功前,第另有有有2个业务服务调用确实持久化在数据库,而是 仍然是另有有有2个上面请况,不还还可不能否 通过业务锁来标记,控制相关的业务操作和行为。而是 在这名 模式下无疑增加了整个分布式业务系统的繁杂度。

还是以上面的例子来看。对于转账操作,原有的另有有有2个服务调用变化为第一步调用本地的取款服务,第二步发送异地取款的异步消息到消息上面件。原应第二步在本地,则保证事务的完正性基本无任何什么的问题,即这名 而是 本地事务的管理机制。假如另有有有2个操作都成功即都不还还可不能否 返回客户成功。

在本地取款到异地存款另有有有2个服务调用之间,会处于另有有有2个真空期,这段时间相关现金沒有任何另有有有2个账户,而而是 在另有有有2个事务的上面请况,而是 客户越多关心这名 ,假如在约定的时间保证事务最终的一致性即可。

事务补偿机制 事务补偿即在事务链中的任何另有有有2个正向事务操作,都不还还可不能否 处于另有有有2个完正符合回滚规则的可逆事务。原应是另有有有2个完正的事务链,则不还还可不能否 事务链中的每另有有有2个业务服务或操作都在对应的可逆服务。对于Service服务这名 无请况,而是 容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理,建立跨资源的事务上下文。而是 也较难以实现真正的预提交和正式提交的分离。

关于等幂操作的什么的问题 重复调用多次产生的业务结果与调用一次产生的业务结果相同,简单点讲所有提供的业务服务,不管是正向还是逆向的业务服务,都必不还还可不能否 支持重试。原应服务调用失败这名 异常不还还可不能否 考虑到,不还还可不能否 原应服务的多次调用而原应业务数据的累计增加或减少。