PHP系统声明式事务处理

1.数据库事务

事务（Transaction）是并发控制的基本单位。所谓的事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。例如，银行转账工作：从一个账号扣款并使另一个账号增款，这两个操作要么都执行，要么都不执行。所以，应该把它们看成一个事务。事务是数据库维护数据一致性的单位，在每个事务结束时，都能保持数据一致性。事务具有以下4个基本特征：● Atomic（原子性）：事务中包含的操作被看做一个逻辑单元，这个逻辑单元中的操作要么全部成功，要么全部失败。● Consistency（一致性）：只有合法的数据可以被写入数据库，否则事务应该将其回滚到最初状态。● Isolation（隔离性）：事务允许多个用户对同一个数据进行并发访问，而不破坏数据的正确性和完整性。同时，并行事务的修改必须与其他并行事务的修改相互独立。● Durability（持久性）：事务结束后，事务处理的结果必须能够得到固化。

2.实现数据库事务管理的方式

2.1 编码式事务

在代码中显式调用beginTransaction()、commit()、rollback()等事务管理相关方法就是编码式事务管理。编码式事务管理需要程序员在具体的业务代码中显式调用事务管理的相关方法，并显式地根据各种条件来判断是提交还是回滚。这种方式在业务简单的系统中还可应付，对于业务复杂的系统可能会因为少了某些条件判断导致错误的提交或回滚，尤其对于业务需求变动极其频繁的系统可能会因为判断条件没有及时根据业务的调整而修改而导致错误的提交和回滚。由于编码式事务存在需要将事务管理与业务逻辑代码耦合，并且难以判断或及时更新回滚条件，甚至出现意料之外的事务嵌套等原因，因此不推荐使用编码式方式管理事务。

2.2 声明式事务

TP系统的声明式事务管理机制在底层是建立在TP框架的行为扩展机制之上的。其实质是在控制器的目标方法执行前开启事务，在执行完控制器的目标方法之后根据实际情形提交或回滚事务。

声明式事务最大的优点就是不需要在具体的业务逻辑代码中搀杂事务管理的代码，只需在模块配置中声明需要开启事务管理的方法，即可将事务运用到业务逻辑中。

3.TP项目的声明式事务处理机制的实现

1)在系统常量配置中增加两个常量：

// 开启数据库事务define('DB_TRANS_ENABLE', true);// 数据库事务全局标志define('DB_TRANS_VAR', 'tx_comment');

2)在BaseModel中重载TP框架的Model类中的add、addAll、delete、execute、save方法

具体可查看相关代码。

3)在MyActionBeginBehavior的run方法中根据系统全局事务开关和模块配置判断是否开启数据库事务

// 开启数据库事务 by 凡墙 2015.09.14 18:05$db_trans_enable = C('DB_TRANS_ENABLE');if(defined('DB_TRANS_ENABLE') && DB_TRANS_ENABLE && is_array($db_trans_enable) && in_array(strtolower(CONTROLLER_NAME . '.' . ACTION_NAME), $db_trans_enable)) {    env(DB_TRANS_VAR, true);    M()->startTrans();}

4)在MyActionEndBehavior的run方法中根据系统全局事务开关、模块配置以及环境变量DB_TRANS_VAR的值判断是否提交事务

// 处理数据库事务 by 凡墙 2015.09.14 18:05$db_trans_enable = C('DB_TRANS_ENABLE');if(defined('DB_TRANS_ENABLE') && DB_TRANS_ENABLE && is_array($db_trans_enable) && in_array(strtolower(CONTROLLER_NAME . '.' . ACTION_NAME), $db_trans_enable)) {   $tx_commit = env(DB_TRANS_VAR);   if ($tx_commit === false) {      // 回滚      M()->rollback();   } else {      // 提交事务      M()->commit();   }}

5)强制回滚

在需要强制回滚的代码处将环境变量 DB_TRANS_VAR 的值设为 false，则系统将在目的方法结束后回滚。

4.存在的问题

4.1 数据库读写分离

数据库读写分离后，按TP框架的机制，一次请求将至少创建两个数据库连接，因此目前的声明式事务实现机制需要针对读连接和写连接分别根据需要管理事务。

4.2 事务控制的细度

和编码式事务相比，声明式事务的最细粒度只能浸入到控制器的方法级别，没法做到像编码式事务那样可以浸入到代码块级别，甚至无法做到对非控制器的方法的事务管理。待扩展。

4.3 事务对数据的影响

幻读phantom read：事务1读取记录时事务2增加了记录并提交，事务1再次读取时可以看到事务2新增的记录；不可重复读unrepeatable read：事务1读取记录时，事务2更新了记录并提交，事务1再次读取时可以看到事务修改后的记录；脏读dirty read：事务1更新了记录，但没有提交，事务2读取了更新后的行，然后事务T1回滚，现在T2读取无效。幻读、不可重复读、脏读等问题可通过数据库的事务隔离级别解决，待优化。

需要注意的是，若在数据模型层对数据做了缓存处理，系统开启事务后可能导致“脏数据”的问题，因此对于一些重要数据字段的读写不能依赖于缓存中的数据。

4.4 分布式事务

数据库分库分表或系统采用微服务架构后将出现分布式事务问题。待研究。