浩的博客

浅谈企业软件架构(5)


 

第五章 并发和事务

 

并发和事务是企业开发中常遇到的棘手问题,尤其对于新人来说有的时候他们是一个难以琢磨的名词,但是企业开发中总会跟它们打交道,它们如影随形总会在某个时候成为开发者梦魔。本章我们通过一些简单的例子来说明并发和事务的一些基本概念。

5.1 常见的并发情况

如果我们在多线程或多进程中操作同一数据,就会遇到并发问题。企业开发中系统常常访问的是存储在数据库中的业务数据,我们最常见的例子就是两个用户在相隔很短的时间内先后从数据库中获取了一份相同的某个业务单据的数据拷贝,用户都完成各自的修改后分别向系统提交数据,这样一个简单的场景就导致了更新数据的并发问题之一,更新丢失。

5.1.1. 更新丢失

在前面的例子基础上来演示更新丢失的情况,在UnitTest项目中的CustomerBizTest.cs增加一个测试方法LostUpdateTest来测试更新丢失的并发情况,代码如下:

 

Code


  我们来看测试结果和测试的输出:


 

测试结果和输出都证明了我们的断言,用户A的修改customerA.Lastname = "" 最后提交到数据库时其更新丢失,修改值被后面用户B的更新覆盖掉了,用户A的更新就永远的丢失了。

 

5.1.2. 不一致的读

不一致的读的场景,企业开发中常见的多表记录维护的业务数据(如:报账单),报销人员A在第一次录入完报账单后,子表总共有5条记录,数据提交回系统。这时经理B启动了系统并读到了这张报账单准备进行审核,数据装载到了经理B的电脑终端上,随后经理B还没来得及仔细看报账单详细内容,就接到了一个电话,在电话里他跟对方聊了一会。报销人员A保存完数据后,发现报账单明细(子表)有一个金额错误于是他重新修改了这条记录,把金额从1562.42元修改成15620.42元,随后把修改提交回系统。经理B接完电话仔细看了完报账单没什么问题审核了该单据。通常我们的单据审核的状态会放在主表记录里面,经理B审核了一份单据金额相差1万多元的报账单!

不一致的读导致了上面的这种局面,经理B审核的单据与系统最后报销人员A提交的单据存在不一致的数据。

5.1.4. 隔离数据操作

上述两种情况都会导致业务数据正确性的失败,从而导致系统错误行为。通过数据隔离可以避免上述两种并发的基本情况,一个用户读取数据后,别的用户不能在读取数据,或者只能只读读取数据。企业开发中常用单据状态来对单据数据进行过滤,如:草稿状态,上面的例子里如果使用草稿状态,经理B是不能查看到报销人员A未正式提交的状态的报销单。

通过隔离数据操作来避免正确性失败。但是只考虑数据的正确性是不够的,隔离操作也会导致了一个仅仅浏览数据的用户锁住了数据导致真正要修改业务数据的用户要等他浏览完数据后才能更改业务单据。企业开中我们也要考虑数据使用的灵活性,即多少个并发活动可以同时发生。

5.1.4. 乐观并发控制和悲观并发控制

乐观并发控制在上述场景下,会给经理B提示他提交的数据与系统当前的拷贝不一致,他需要重新加载数据来进行审核,避免造成系统正确性失败的错误。乐观并发控制是关于冲突检测,并提示用户接下来如何操作。悲观并发控制如果使用在上述场景中就是报销人员A在经理B读取报账单后不能再修改他的报账单据了。如果他确实需要修改单据必须等到审核完单据后,去找经理B取消审核该单据,然后再来修改自己的报账单。悲观并发控制可以看成隔离数据的操作来避免并发操作的产生。乐观并发控制需要导致提交冲突的用户放弃自己的数据修改,牺牲自己前面的工作。

   

5.2 事务

企业开发中处理并发最主要的工具就是事务,通常使用ACID来描述软件事务。

原子性:在一个事务里,所有的操作都必须全部完成。要么全部成功,要么回滚所有操作。常见的例子就算是企业开发中的入库单单据,入库单如果某物料A入库数据量为100,当前物料A的库存数据量为30,那么在入库单提交回系统的同时,当前库存物料A的纪录也需要把库存书更新为30+100=130,部分完成不是事务的概念。

一致性:事务开始和完成的过程中,系统的其它资源必须是一致的,没有被改变的状态,也就是事务中不能有其他事务改变系统的资源状态。

隔离性:事务成功完成后,其提交的数据才能被其他事物操作读取本次事务结果。

持久性: 已提交的事务必须是永久保存的。

5.2.1. 系统事务

系统事务常说的就是由关系数据库系统一组SQL命令的组合。如下: 

Code


  在事务里任何一个命令如果执行失败了就必须回滚所有前面执行的SQL命令,只有都执行成功了才提交到数据库,最终完成系统事务。

 

5.2.2. 业务事务

业务事务就是前面举的入库单的例子,我们须在系统事务执行业务事务才能把业务事务变成我们业务系统中的事务处理,来实现客户的业务事务。现在我们回过头来看我们的前面的例子,我们的Dal层都是针对一个Model来设计的,然后由Biz层来调用Dal层提交Model数据。我们把针对单个Model的系统事务实现在了Dal层。可是操作多个Model对象的业务事务是在Biz层实现的,这样就给我们Dal层设计出了一个难题,至少现在我们的Dal层是不能实现这样的支持,增、改、删除方法都默认启动了事务,我们需要重构我们得代码来实现Biz层多Model提交的业务事务支持。

这样的设计是基于业务事务是由业务层(Biz)来封装的,也只有在Biz层最应该负责在哪儿启动事务哪儿提交事务,以及什么情况下回滚事务。因为Nhibernate的系统事务是由它的Session来启动的。我们需要增加一个专门管理事务的类封装事务的启动、提交和回滚。避免Biz层直接引用NhibernateSession来实现业务事务要求(数据访问层的实现逻辑对于Biz层是不可见的)。 

 

5.2.3. 重构Dal层代码

我们增加一个类来专门管理NHibernate Session中的系统事务,同时在单Model提交的Dal中仍然有自己默认系统事务调用,这样的写法的方便性在于对于常见的单Model提交的系统事务由Dal层默认实现,减少在Biz层的事务调用的繁琐操作。

NHibSessionMgr.cs NHibernate事务管理类

 

Code


  本类负责获得NHibernate的会话对象,代码中使用了单件模式,但是为了在某些场合下仍可创建新的会话,我们使用了带参数的GetSession(bool otherSession)函数来实现返回新的话。 

NHibernateSession.cs代码如下: 

Code


  CustomerDal.cs代码如下: 

Code


  注意:上面重构代码的变化,事务调用我们直接调用了基类的统一封装事务方法。Dal层的类需要从基类HibernateSession继承而来,事务函数使用的是基类统一封装的事务函数,这是这次重构中最关键的调整。这样事务就不再直接使用Hibernate Session的事务。同时,为了能在单元测试中模拟不同会话的需要,我们的NHibernateSession类是可以通过构造函数的otherSession参数来确定是否使用另个会话来进行测试,这个对于我们进行并发冲突测试很重要。

 

5.2.4. 重构Biz层代码

CustomerBiz.cs 只调整构造函数,目的也是确保可以打开另一会话来进行我们需要的单元测试或业务逻辑。    

Code


 

5.2.5. 重构更新丢失单元测试代码 

Code

 
  运行单元测试通过说明我们的重构符合了预期的要求。

 

5.2.6. 实现业务事务

目前为止我们还没有实现本章说的业务事务,也就是在一次业务事务中涉及到对多个Model实例的操作,最后需要确保业务事务被系统事务正确的提交到中,避免出现数据丢失或者完整性缺失等情形。业务事务都是在Biz层产生的,我们通过重构Biz层代码来实现多Model操作的系统事务调用。

我们增加一个BaseBiz基类来实现统一的事务调用。BaseBiz.cs代码如下:

 

Code


 

现在我们假设有一个业务需要批量添加的用户必须在一个事务里完成,也就是说我们必须保证批量添加的用户数据要么都提交到系统中,要么全部回滚数据,不允许部分数据提交的情形出现。

 

单元测试代码如下:

 

Code


 

CustomerBiz代码重构和增加批量添加函数如下:

 

Code


 

运行单元测试通过,注意看单元测试代码逻辑,我们假定了两种情况一种是正常提交到系统后,我们使用新的会话来获取数据验证是否与新增的数据是否一致,还有另一段测试代码我们设计了一种提交错误的场景,来检验提交的数据是否被全部回滚了,不存在部分提交的情况。我们的重构实现了我们预期的功能。

 

5.3 结语

本章我们简要的描述了软件开发中并发和事务,并发会产生“更新丢失”和“不一致的读”问题,这两种情况都会导致数据正确性的失败,系统出现错误的业务逻辑操作行为。如果没有两个人同时操作系统中相同的数据,就不会有并发问题。通过隔离数据操作可以解决并发带来的正确性问题,但是却缺少了并发带来的灵活性。乐观并发和悲观并发是两种处理并发的机制,两种机制各有优缺点。乐观锁策略可以看成是关于冲突的检测,悲观所则是关于冲突的避免。他们俩选择使用是看场景来的,如果冲突的频率和严重性很小,或者客户可以接受冲突导致的数据更新丢失,就采用乐观锁策略,它可以带来很好的并发性。如果并发冲突导致的结果对于用户来说是不可接受的,就只能使用悲观锁策略。

事务是企业开发中处理并发最主要的工具,事务经常使用ACID来描述。系统事务主要是指由关系数据库或事务系统所支持的事务,如:一组sql命令组合。系统事务对于业务系统用户来说是没有意义的,只有通过系统事务实现的业务事务对于用户来说才有价值。如我们例子里的批量添加用户是一个业务事务,它需要在一个系统事务中实现。

下一章我们将继续描述几个复杂的业务事务是如何通过系统事务来实现的。加深我们对业务事务与系统事务关系的理解。

 

 

 

 

 

 

 

 

posted on 2009-07-31 08:44  wuch  阅读(3038)  评论(15编辑  收藏  举报

导航