分布式事务的问题解决方案？

[wq7570875]

2个子项目部署在不同的web服务器上面，怎么解决这2个项目之间的事务同步呢？


举个例子；1个是订单系统。1个是付款系统。 如何保证2个不同服务器上面的项目的数据完整性呢？


对于不同的库，同一个web服务 这个就不用讲了。 急！有什么合适的解决方案。



自己的思路：

两边通过webservice方式 进行通信。如果网络正常，程序正常的话那肯定没问题。

[以专业开发人员为伍]

引用 楼主 wq7570875 的回复:

两边通过webservice方式 进行通信。如果网络正常，程序正常的话那肯定没问题。

你的这个思路这跟分布式事务有什么关系呢？看不出你的基础，找不到知识的交集，无法直接回答。

[走在冷风中_南山南]

引用 1 楼 sp1234 的回复:

[quote=引用 楼主 wq7570875 的回复:] 两边通过webservice方式 进行通信。如果网络正常，程序正常的话那肯定没问题。

你的这个思路这跟分布式事务有什么关系呢？看不出你的基础，找不到知识的交集，无法直接回答。[/quote] 伪专家。。。人家都说的很明白了，两个RPC服务，垂直分库，如何实现事务，保证数据一致性。 @楼主 看下自己的需求，是否需要强一致性？ 1、如果要求强一致性，可以参考TCC和两阶段提交的设计，不建议使用，性能不佳且方案复杂，坑比较多 2、目前分布式事务在性能和一致性上权衡，一般都会用最终一致性的方案去做（网上一搜一大堆） 简单来说就是服务A执行成功后，把服务B的执行通过消息队列，不断去补偿执行，失败重试（服务B做幂等） 最后希望能帮到你

[小龙在线]

2楼说的很好哇

[MiceRice]

引用 楼主 wq7570875 的回复:

举个例子；1个是订单系统。1个是付款系统。 如何保证2个不同服务器上面的项目的数据完整性呢？

你这个例子举的不咋地。逻辑上来说，真没觉得订单系统和付款系统会有什么复杂的分布式需求，毕竟订单和付款在业务上本来就应属于两个环节。 如果分布式事务只涉及两个主体，那么简易做法是： 1、A系统完成写表等操作，并设置“待确认标志”； 2、A系统远程调用B系统更新B系统数据； 3、A系统根据B系统所返回结果撤销1操作，或更新“待确认标志”。 但注意到上述过程不能100%保证成功！！ 问题在于：当第2步完成后，A系统发生断电，那么第三步的提交就没了，此时需要补偿机制。 即根据数据库表中的“待确认标志”到B系统中进行反查其业务流水日志（或结果信息等），根据B系统反查确认结果，修改A系统标志。 要明确的是：但凡没有事后对账或补偿机制的方案，在分布式事务保证最终一致性上，都会有问题。 迷信两阶段锁、分布式事务调停器都是不够的。

[GlyphVectory]

我们公司也是这样，单独订单系统，支付系统。朋友你想复杂了。他们本来就是单独的独立系统，订单生成成功，跳转到你的支付系统，如果失败了那么就异步调用该订单为 未付款|付款失败。

[whs_321]

"TCC是分布式事务实现的一种方式 TRYING 阶段主要是对业务系统做检测及资源预留 CONFIRMING 阶段主要是对业务系统做确认提交，TRYING阶段执行成功并开始执行CONFIRMING阶段时，默认CONFIRMING阶段是不会出错的。即：只要TRYING成功，CONFIRMING一定成功。 CANCELING 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。 而幂等性则是指业务方法调用一次与调用多次的执行返回结果是一样的。 举个支付项目的例子： 支付系统接收到会员的支付请求后，需要扣减会员账户余额、增加会员积分（暂时假设需要同步实现）增加商户账户余额 再假设：会员系统、商户系统、积分系统是独立的三个子系统，无法通过传统的事务方式进行处理。 TRYING阶段：我们需要做的就是会员资金账户的资金预留，即：冻结会员账户的金额（订单金额） CONFIRMING阶段：我们需要做的就是会员积分账户增加积分余额，商户账户增加账户余额 CANCELING阶段：该阶段需要执行的就是解冻释放我们扣减的会员余额 以上所有的操作需要满足幂等性，幂等性的实现方式可以是： 1、通过唯一键值做处理，即每次调用的时候传入唯一键值，通过唯一键值判断业务是否被操作，如果已被操作，则不再重复操作 2、通过状态机处理，给业务数据设置状态，通过业务状态判断是否需要重复执行 另外：你也可以看下这篇博客，上面是以传统电商平台支付系统为例的一套分布式事务处理实现，讲的也比较深。http://www.roncoo.com/article/detail/124243"

[乔不思]

引用 1 楼 sp1234 的回复:

[quote=引用 楼主 wq7570875 的回复:] 两边通过webservice方式 进行通信。如果网络正常，程序正常的话那肯定没问题。

你的这个思路这跟分布式事务有什么关系呢？看不出你的基础，找不到知识的交集，无法直接回答。[/quote] 人家是来问问题的，不是听你教育的，我不相信你没理解意思，干嘛非得装。。。

[乔不思]

楼主，分布式事务现在还没有一套完善的解决方案,有的可以解决数据的事务问题，但是性能很差，还不如不用，如果你想法设法想着怎么做到 数据的事务特性，还不如想着把数据的补偿机制做的好点。 消息的重发机制， 消息的确认机制 做好这个应该问题不大。

[任重道远莫忘初心]

楼主，你分布式事务怎么弄到呀？我去面试，面试官就问我来着。 在微服务情况下，服务A的一个方法调用了服务B的一个方法，这个事务怎么加。 就是说服务B的方法正常执行，服务A在调用服务B方法之后出错，如何把服务B的数据回滚。

[学无止境-逆流而上]

这种用分布式事务是不好的，在你设计表的时候，要考虑判断字段，比如付款表，付款状态200表示成功，一旦不成功，触发“回滚”，也就是逆向操作。 另外，可以做个task表，专门处理这种状态不一致的定时任务。 主要，你要有一套正向处理流程、逆向处理流程、定时处理流程（不管哪个步骤出问题都可以回滚）

[runnersun]

可以试试在数据库中加一个同步锁机制，保证分布式数据的同步性，在应用一的同步锁字段打开时，应用二的同步锁关闭，此时应用一才可以修改数据库和进行需要的事务处理，同理应用二做法。