单体架构中事务的使用姿势略谈

       不论是单体架构还是分布式架构，事务一定会使用到的。单体架构下，通常使用数据库自带的ACID机制加上Spring的AOP可以解决大多数场景的需求。分布式事务会比较复杂，有2PC，3PC，TCC等。本文暂不涉及分布式事务，考虑以后另写文章，讨论分布式事务。

 

       事务本身是用来保证一次请求或者操作的一致性，完整性的。因此不得不讨论一下一次请求或者一次操作。一次请求可以理解为后台一个controller方法的调用，单体架构下MVC模式使用较多。通常会分为三层，controller用于接收终端的请求，并将数据向serivce层进行传递，需要进行存储的调用下层的dao（mapper）层或者cache层。

        那么事务究竟放在哪一层比较合适呢？是controller还是service？或者dao？

从个人的工作经历来看，把事务放在dao层的做法不是说没有，只是比较少。通常情况下，一个dao的方法用于完成一个数据库操作，删除，修改或者新增。数据库默认一条DDL就是一次事务，通过数据库ACID机制就可以保证。

        其次，事务比较常见的是加在controller层，至于原因嘛？有的开发工程师认为既然一次请求就是一次事务，把事务加在controller似乎看起来也是没毛病的。当然，这只是似乎而已。

        咋一听起来，有一丝道理。仔细寻思，一次请求只是说终端对后台调用一次，并不意味着这一次调用仅仅只发生一次逻辑调用。比如一次简单的下订单请求，首先会查询数据库有无库存，然后修改对应商品的库存数量，同时增加一条订单信息，往MQ中投递一条通知短信，等等。不仅仅是调用多个dao层，而且可能会有MQ的相关操作。一次请求不等于一次逻辑调用。而多次逻辑调用意味着多张数据库表的数据会得到更新。假如其中某一个dao层或者cache层发生异常，这一次调用应该是失败，并且由数据库保证回滚的。第二个理由是，controller由于是跟web容器绑定在一起的，由容器决定每一次请求是否开启线程进行响应，而且线程的容量也跟容器息息相关。所以尽可能保证线程高效，而事务会开启另外一个单独的线程，线程调度之间如果出现异常，那么事务可能会失控。第三个理由是，controller可能只针对restfull接口，如果对于常规RPC接口，直接开放service的，那么事务会直接不生效导致业务不满足。

       通常情况下，一般的研发团队都会把事务拦截放在service来进行出来，而service中的每一个方法由spring aop进行事务保证。只要在一个事务环境中，一定能保证ACID，service层的方法中要把一次方法的调用放在一起，可以是直接调用dao层，也可以是调用service层。不管是从将来的可扩展性（即使直接将service暴露给rpc接口，事务依然生效），还是单一职责（一次操作由一个方法进行保障）。推荐将事务操作都放在service层进行统一处理。

        对于一些小项目，对于controller和service没有特别明显的区别，甚至有的模块可以直接把service的逻辑实现直接放在controller中，这也不是什么大问题，在项目初期，使用人数不多，业务够简单，逻辑清晰的情况下，这也无伤大雅，如果随着项目的复杂度上升，业务逻辑加大，建议还是把事务的控制从controller层移到servcie。

       小调查，各位朋友所在的开发项目组，对于事务是放在哪一层呢？可以留言交流。