面向业务流的事务控制，也不知道这个名称是否科学，根据自己在工作中遇到的实际情况定义的一个名字。
面向业务流的事务控制，主要是针对一些相对复杂的业务场景，有很多的制约条件下的事务控制。
用一个案例来描述我的想法：
例如：设想网上购物的一次交易，其付款过程至少包括以下几种操作：
一、更新客户所购商品的库存信息（可能是从本地数据库获取，也可能通过接口从别处获取）
二、客户付款（可能要和银行的支付接口交互）
三、生成订单（可能要和供货商接口交互）
四、更新用户相关信息（可能是数据库，也可能是文件系统）
正常的情况下，这些操作将顺利进行，最终交易成功，与交易相关的所有信息也成功地更新。整个事务的全过程也不可能回滚，比如在第四步发生了异常，前面几步几乎是不可能回滚，比如第二步客户付款，能直接让银行把钱直接给退回来吗？不是在这一个事务中，能够马上实现的。
因此，我们没法直接用数据库事务来确保整个业务的执行，但是数据库的很多思想我们可以借鉴和考虑。
方法还是日志。
我们准备进行一次交易的时候，首先把用户购物车信息进入日志记录。
所有的状态，都用日志进行记录，而不是简单的考虑回滚。
在整个业务流程中，单个环节的原子性必须要有。从宏观上来看，将整体流程作为一个事务，用日志作为全过程的记录。当某一个环节出现异常后，上一个环节的情况还是能够保持。
…
核心重点在与，下一个环节出现故障后，上一个环节的情况必须要保持，并且还能够支持下一个步骤的继续开展。
原文地址：http://blog.csdn.net/ffm83/article/details/43488469
