为何分布式事务喜欢用消息队列实现, 直接rpc或者http不行吗？

Question

为何分布式事务喜欢用消息队列实现？直接rpc或者http不行吗？消息队列方式发起方不知道被动方处理结果，还要被动方通知，rpc/http方式实时知道处理结果，省去被动方通知
如果不是为了高并发削峰，直接rpc或者http是不是更好？

rpc/http分布式事务思想

  {
    transaction.start();
    doSomeWriteInDB();
    insert(OperationMessage, Status.PENDING);
    transaction.commit();
    try{
      boolean isSuccess = doRemoteRPCCall();
    } catch(Exception e) {
      return;
    }
    if(isSuccess)update(OperationMessage, Status.FINISHED);
  }

然后开定时任务查询PENDING的OperationMessage，重新执行doRemoteRPCCall();

Answer 1

解耦。

现在有 Service A / Service B，三者构成某分布式事务。

如果用 rpc，A / B 彼此是不是得知道对方（哪怕用注册中心不也有个调用过程）？用消息队列的话，彼此压根不需要知道对方，只需要跟消息队列打交道就可以了。

你硬要用 rpc 也行，那这时候又多俩 Service C / Service D 出来呢？你回过头还得去改 A / B 的代码吗？都你自己写的你说你费点儿劲，那也行；如果是两个不同 Team 在干活呢？人家凭啥加班帮你改，自己的任务不做了吗？

Answer 2

• mq的作用就是解耦、异步、削峰，实现分布式事务的最终一致性，是柔性事务。
• 不考虑并发，直接rpc或http就需要考虑分布式事务如何保证，当然也有对应的分布式事务框架可以补。

两种实现没有优劣之分，针对不同场景使用不同的方式，只不过mq在高并发中比较常见。

Answer 3

不是通知的方式更适合这种场景吗？你那边好了通知我，我继续干我的。

Answer 4

没有最好的技术，只有合适的技术。专业的中间件干专业的事情

Answer 5

消息队列的方案不能真正的达到一致性，是在一致性要求不高的场合下用的。而rpc方案（TCC方案）则可以达到严格的一致性，但代码量比较大。绝大部分场合不需要那么严格的一致性。