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

       不论是单体架构还是分布式架构,事务一定会使用到的。单体架构下,通常使用数据库自带的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。

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

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页