跨业务事务应该如何控制？

[yzy8788]

业务场景：调用短信接口，发送成功后扣除用户账户余额0.1元

if(短信发送成功)
{
  user.money=user.money-0.1;
}

这个该如何控制事务呢？短信发送成功后，钱没扣成功咋整？

[娃都会打酱油了]

记日志，通过相应的修复程序来修正-1的行为

[不断学习的ITer]

如果你是短信公司的，可以用事务。如果不是，只能记录日志，靠监控程序了。

[以专业开发人员为伍]

这是两码事，首先记住不要很悲哀地套用数据库的事务概念就行了。数据库事务是个纯粹数据库读写磁盘数据的概念，这千万不要随便套用在业务上。 有了基本的立场，其实就迎刃而解。你在手工操作中怎么做事？你会先掏出手机发短信，然后如果发不出去，你就会换其它手机发短信，再不行，你就会再换另外一个方式......你会千方百计把这个事儿给办了——而不是退回给用户。而对于扣费方法，你会先扣费，如果失败你就会重试，重试n次的同时你还会投诉并且找人解决，实在不行你会借用更高层的关系，如果最终实在还不行（连最高法院都拿对方没办法了）你会在自己的小黑本本上记一笔帐、以后再算。 软件的设计模式也是一样的。架构师会设计一个系统，确保发短信一定可以成功，扣费也一定可以成功，成功的人永远都是一样的，它用业务流程来做事。一些幼稚的学生才会用什么单纯而“总是为了自己省事儿”的技术借口来解释为什么失败的问题。

[该对象不能为空]

短信供应商那边一定有日志的。 你这边也要有个扣款日志。 对比一下就能发现哪些是没扣款的。 然后定时处理这些异常数据。

[以专业开发人员为伍]

基本上，任何单纯说技术术语的做法，都不能解决业务设计问题。业务流程往往需要重构几十遍，除了有产品经理会帮你优化这个操作流程，还有测试人员，更主要地还有许多用户会逼着你重构流程。所以面对这种问题，就看一个人的素质有没有到那种可以随机应变地重构系统（但是不自相矛盾）的程序。没有一定的什么技术可抄。原则上，就是遵守业务的要求，最终会达到结果一致性、令人满意，而不是纠结暂时的技术。

[以专业开发人员为伍]

不是说仅仅靠随便几个日志，也不是说数据库事务概念。你可以想象一下，如果你找出任何技术的借口（比如你跟用户说“我记日记了啊？！），用户会用脚投票的。 你如果是经过10万次测试的，就往往比仅仅经过100次测试的东西，有不同的内涵。如过你不在一个皮包公司，那么你们就会对这种问题绝非这么简单地提出问题。

[以专业开发人员为伍]

更具体地说吧。比如如果我的下属跟我解释说”短信供应商那边一定有日志的“，那么我就会觉得这个项目可能没有找对人来做。实际，一个软件对程序设计师的要求是：“如果短信供应商那里发送失败，怎样确保找其它方式发送”，而不是要一个人人皆知的技术上的解释。

[jetable]

你调用的外部短信发送接口的话，是否发送成功不知道的，可能第三方会有个回调接口通知你或之后你调他的接口去查询是否发送成功了。这里我觉得没必要做事务，只要没有异常，发送给了第三方短信发送接口，正常扣款就行了。