问题描述
RT，
解决方案
解决方案二：
财付通这个是异步的通知，不存在事务的问题吧
解决方案三：
就比如我们这边财付通那边充值成功了，我们这边保存数据时候失败了，怎么办。。。。
解决方案四：
引用2楼yu929927571的回复:
就比如我们这边财付通那边充值成功了，我们这边保存数据时候失败了，怎么办。。。。
你们保存数据失败是你们自己的事情，难道还要财付通退钱么，照这么搞法你们老板肯定要把你们都炒鱿鱼，哪有把收进来的钱退出去的道理？失败了就重试，财付通要求收到你们成功处理的通知，不然会一直给你们发通知发好像是48个小时
解决方案五：
失败了他应该会有信息反馈的。
解决方案六：
财付通应该有重发机制；你们系统也可以做集群；
解决方案七：
引用2楼yu929927571的回复:
就比如我们这边财付通那边充值成功了，我们这边保存数据时候失败了，怎么办。。。。
这没扯到分布式事物吧一般那种接口都会有自动重发机制你仔细看看对方给你的文档需要你们回一个明确的答复他们才停止发送
解决方案八：
引用3楼ygycomon的回复:
Quote: 引用2楼yu929927571的回复:
就比如我们这边财付通那边充值成功了，我们这边保存数据时候失败了，怎么办。。。。你们保存数据失败是你们自己的事情，难道还要财付通退钱么，照这么搞法你们老板肯定要把你们都炒鱿鱼，哪有把收进来的钱退出去的道理？失败了就重试，财付通要求收到你们成功处理的通知，不然会一直给你们发通知发好像是48个小时
对，就是要他们那边回滚，因为我们这边没有保存，虽然可以人工补单，。（你确定你是在回答我这个问题？？）
解决方案九：
引用6楼djy18178的回复:
Quote: 引用2楼yu929927571的回复:
就比如我们这边财付通那边充值成功了，我们这边保存数据时候失败了，怎么办。。。。这没扯到分布式事物吧一般那种接口都会有自动重发机制你仔细看看对方给你的文档需要你们回一个明确的答复他们才停止发送
我知道这个机制，这是我遇到的一个面试题，
解决方案十：
按照你们说想的就是这个根本不会涉及分布式事物？我想也是，毕竟代码在人家那边，我们只是调用人家的接口。或许我们这边最多做一个自动对账平台，人工补单，。但是我想问的程序里面难道就没有更好的方式来处理这种问题？？
解决方案十一：
不明白你说的问题是什么，这个流程很完整，你认为哪个环节可能会出现数据不一致的情况所以要扯上事务？
解决方案十二：
引用10楼ygycomon的回复:
不明白你说的问题是什么，这个流程很完整，你认为哪个环节可能会出现数据不一致的情况所以要扯上事务？
很简单的一个问题啊，就是他们那边充值成功，我们这边保存失败，这就是我们这边掉单了。我们在程序中应该如何更好的防止这样的掉单情况。。
解决方案十三：
如果简单的数据库操作都出问题这种情况和任何其他项目的异常一样记日志发邮件即可属于非预期异常
解决方案十四：
平台的公共接口肯定不会因为极少数的需求而作变动如果只是面试题，全是假设的话可以那边接口和数据库保存放在同一个实物中，接口没收到你们成功的返回信息就回滚可实际中肯定是调用接口的去改变，而不是平台接口改变，因为那边成功，你们这边失败，明显就是你们这边出了问题
解决方案十五：
引用11楼yu929927571的回复:
Quote: 引用10楼ygycomon的回复:
不明白你说的问题是什么，这个流程很完整，你认为哪个环节可能会出现数据不一致的情况所以要扯上事务？很简单的一个问题啊，就是他们那边充值成功，我们这边保存失败，这就是我们这边掉单了。我们在程序中应该如何更好的防止这样的掉单情况。。
事务是指一个连续操作，要么同时成功要么同时失败，没有中间状态，你这里分明只有你保存交易结果这一个动作，和事务有什么关系？难道在你自己的系统里你都不能保证一个保存动作一定成功？异常了自己重试不行么，退一万步说，就算你的数据库挂了，他们还会重复通知，通知48个小时，这样都不能保证你保存成功？