1.1. ACID
原子性（Atomicity）：事务是一个不可分割的工作单位，事务中的所有操作要么全部执行成功，要么全部不执行（即回滚）。如果事务中任何一部分失败，整个事务都会被回滚，就像从未发生过一样。 一致性（Consistency）：事务执行前后，数据库的状态必须从一种合法状态转换到另一种合法状态。这意味着事务必须遵循所有的数据完整性规则，如实体完整性、参照完整性和用户定义的完整性约束。 隔离性（Isolation）：多个事务并发执行时，彼此间不应互相影响。事务的隔离级别决定了一个事务可以看到其他事务修改数据的程度，从最低级的读未提交（Read Uncommitted）到最高的串行化（Serializable），隔离级别越高，并发性能越低，但数据一致性越好。 持久性（Durability）：一旦事务被提交，它对数据库的改变就是永久性的，即使系统出现故障，事务的效果也不能丢失。
1.2. 生命周期
开始事务：通常通过编程语言提供的API或SQL语句显式声明事务的开始，如BEGIN TRANSACTION。 执行操作：在事务开始和结束之间，可以执行一系列数据库操作，如INSERT、UPDATE、DELETE等。 提交事务：如果所有操作成功完成，通过COMMIT语句提交事务，将更改永久保存到数据库。 回滚事务：如果在事务过程中发生错误，可以通过ROLLBACK语句撤销事务中所有已完成的操作，恢复到事务开始前的状态。
1.3. 分类
简单事务：在一个数据库实例内进行的事务操作。 分布式事务：微服务架构下，原子服务（拥有自己的部署容器和数据存储容器）部署在不同的服务器上，服务间调用就会出现跨越多个数据库或服务的事务，需要特殊的协调机制（如两阶段提交）来确保所有参与方的一致性。 嵌套事务：在一个事务内部再启动新的事务，通过事务传播行为控制内部事务与外部事务的关系。
1.4. 实现技术
两阶段提交（2PC）：一种经典的分布式事务协调协议，分为预提交和提交两个阶段，确保所有参与节点达成一致决策。 三阶段提交（3PC）：在2PC基础上改进，增加了预预提交阶段，减少阻塞范围，提高系统可用性。 Saga模式：通过一系列有事务补偿操作的业务步骤来模拟长事务，支持最终一致性，适用于微服务架构。 乐观锁与悲观锁：在并发控制中用于解决事务间的冲突，乐观锁假设并发冲突较少，悲观锁则假设冲突频繁。
2.1. 业务场景
transaction 1 会落table A 一条 A数据，然后将内容塞入上下文，供transaction 2使用。然后会发一条消息。然后执行 transaction 2。 transaction 2 首先判断上下文内容是否存在A数据，如果存在，则继续insert table B一条数据B；反之，则直接return，不做什么操作。
就是加了个幂等判断，见蓝色代码。查询A数据是否已经落单，若落单则直接return，不发消息，继续执行transaction 2；反之会发消息，执行transaction 2。
2.2. 测试验证
2.3. 触发缺陷
2.4. 测试复盘
往期推荐
