也谈组合交易

       组合交易是把积分、红包、余额、银行卡、白条等等组合起来共同完成一笔订单的支付，而且这些功能往往来自于不同的系统，是一种天然的强分布式事务场景。

        针对强一致性分布式事务，可能大多数人首先想到的都是XA，TCC，以及阿里开源的Seata，可能也有人认为MQ也是最终一致性的选择，但不适合用在这种3s内完成交易的场景，还些人把转账场景认为是刚性事务的必然，是分布式事务必然的用武之地。但，有没有可能，转账根本没有涉及分布式事务呢？

        首先，有个基本的认知，跨系统的绝对强一致是不存在的，就如同缓存一致性方案这个扯淡的问题，追求跨系统绝对的强一致，必然是在主系统发起对下游系统的调用后，若下游系统未反馈结果，就去主动查询，这样想在3s内完成交易，真的太难了，当然土豪除外。

       其次，组合交易场景的核心诉求是：1、要在3s内完成交易。2、要么全部成功，要么全部失败。除此之外，再无其它。

       因此，为了保障绝对的刚性事务，且短时间内完成交易，最好的方法是使用同一套系统记账，利用数据库的事务来搞定。交易系统依据设定好的规则，先去各下游系统查询可支付的金额，若查询失败或者各渠道余额加起来后，仍不足支付金额，就直接终止交易。若确认有足够的支付金额，就调记账系统记账，记账成功后，再发送交易成功通知给下游系统，让下游系统做后续处理。