数据库事务概念和实现技术

北方刀客

给数据库初学者做的事务管理技术的topic，适合初学者入门。
事务基本概念

属性	含义	数据库系统实现
Atomic	事务的操作要么都成功，要么都不成功	WAL，2PC，1PC
Consistency	数据库必须保证事务的执行保证数据库从一个一致的状态到下一个一致的状态。	A、I、D支持实现
Isolation	多个事务并发执行，对每个事务来说，并不会感受系统中其它的事务在执行	2PL，MVCC，OCC
Durability	一个事物提交后，该事务对数据库的该表是持久的。	WAL+存储管理

Jim Gray于1981年VLDB描述了事务的原子性、一致性和持久性，在此基础上，Haerder和Reuter在1983年中提出了事务的隔离性并提出术语 “ACID”，自此，事务的ACID四个性质成为业内标准术语 。
磁盘IO能力决定数据库事务能力上限


WAL技术在实现AD同时，通过下面优化解决数据库性能问题：

• 把磁盘的随机操作改为顺序读写
  
• 引入缓存，尽量减少读写磁盘操作
  

PostgreSQL的WAL实现


WAL（Write Ahead Logging ）
All log records pertaining to an updated page are written to non-volatile storage before the page itself is allowed to be overwritten in non-volatile storage. 

A transaction is not considered to be committed until all of its log records(including its commit record) have been written to stable storage. 

采用WAL协议的恢复算法: Dr. C. Mohan ARIES: Algorithms for Recovery and Isolation Exploiting Semantics, 1993, IBM DB2
MySQL的WAL实现



小结：MySQL与PostgreSQL的WAL实现对比

MySQL（有undo）	PostgreSQL（没有undo）
大事务	undo容易爆盘	-
运行平稳	-	vacuum导致IO抢占
快速abort	需要做undo	支持

PostgreSQL 12 已经支持undo，参考：https://wiki.postgresql.org/wiki/Zheap
分布式原子性保证：2PC协议


Jim Gray等研究者在1978年提出了两阶段提交协议，用于保证分布式事务提交的原子性
可以用于单机集中式系统，由事务管理器协调多个资源管理器;也可以用于分布式系 统，由一个全局的 
事务管理器协调各个子系统的局部事务管理器完成两阶段提交 .
分布式原子性保证：2PC实现


分布式原子性保证：1PC实现


分布式原子性保证：1PC实现


满足一阶段提交的分布式事务:
• 有写操作，参与者只有一个
• 只读事务
小结：AD保证

• 单机通过WAL+Buffer Pool来优化磁盘IO性能，同时保证原子性和持久性，WAL的原子性通过磁盘4k写的原子性保证；
  
• PostgreSQL的单机AD能力在小事务频繁update/delete场景下相比MySQL有缺陷，但是在大事务场景下更优；
  
• 分布式的AD通过2PC的方案来解决，2PC的参与者与协调者本身的AD也是通过WAL来保证；
  
• 为了解决2PC的性能问题，在只读和单点写的场景下，提供1PC的优化方案。
  

事务隔离级别
通过定义不同隔离级别，由业务方在可能出现的问题，提高并发度上做选择。


PostgreSQL的Repeatable Read，实际是Snapshot Isolation的隔离级别，解决了幻读的问题。
并发控制：2PL

• 2PL可以保证Serializable隔离级别；
  
• 2PL并发能力受限。
  

PostgreSQL的表级锁


PostgreSQL通过细化锁（8级锁）的兼容性，通过2PL来实现表级别的并发冲突。
MVCC技术
解决的问题：MVCC解决对数据行的读-写冲突问题。
实现机制：不用加锁，通过一定机制生成一个数据请求时间点时的一致性数据快照， 并用这个快照来提供一定级别 （语句级或事务级） 的一致性读取。实现读和写的并发。
PG实现举例：





PostgreSQL MVCC实现：update


Postgresql MVCC实现：快照读


MVCC的分布式实现


ww-conflict：lost update问题
MVCC只处理了读写并发的问题，无法解决写写并发的问题。

Time	事务A汇款	事务B取款
T1	开启事务
T2	开启事务
T3	查询kaka账户余额为1000元
T4	查询kaka账户余额为1000元
T5	取出100元把kaka余额改为900元
T6	提交事务
T7	汇入100元
T8	提交事务（把余额改为1100 元 ）

上面的例子里由于汇入事务覆盖了取款事务对存款余额所做的更新，导致银行最后损失了100元，相反如果转账事务先提交，那么用户账户将损失100元。
PostgreSQL的ww-conflict解法


小结：隔离性实现与一致性保证

• 隔离性和一致性问题的根源来自并发，读读没有并发问题，有问题的是读写并发和写写并发；
  
• 2PL可以解决读写，写写并发的问题，并提Serializable隔离级别，但是并发低，所以传统数据库主要用来管理表级别的并发；
  
• MVCC只解决读写并发的问题，PG基于MVCC实现的RR隔离级别实际为SI，解决的幻读的问题。
  
• PostgreSQL通过行锁的方式解决了ww-conflict导致的lost update问题。
  
• GTM可以实现分布式的事务快照，解决分布式事务可见性的问题。
  

事务的稳健性保证

白盒测试


-- Scenario to test
Fix 2PC may be committed on coordinator, aborted on segments
— 1. session 1: COMMIT is blocked at start_insertedDistributedCommitted
-- 2. checkpointer: Start a CHECKPOINT and wait to reach before_wait_VirtualXIDsDelayingChkpt
-- 3. session 1: COMMIT is resumed
-- 4. checkpointer: CHECKPOINT is resumed and executes to keep_log_seg to finally introduce panic and perform crash recovery
核心点：

• 模拟并发
  
• 模拟故障注入，覆盖各种故障类型。
  
• 覆盖设计的全流程
  

一致性测试




ACID与CAP中的“C”的差别



https://jepsen.io/consistency
Highly Available Transactions: Virtues and Limitations
还有什么可以做的？
长稳测试&压力测试
组织保障：

• 团队的稳定性；
  
• 需要有专业的测试团队，测试，研发团队独立考核。
  

产品流程：

• 规范化的版本规划与发布标准
  
• bug分级定级制度
  

架构设计：冗余设计，保证紧急情况下还能数据救回来。
工程能力：
快速发现：监控告警机制
快速定位：保留现场和日志
快速止血：故障恢复机制和数据备份恢复
快速修复：滚动升级
AP系统的事务能力对比

事务能力 （用户价值）	snowflake	databricks (deltalake/hudi/iceberg)	Redshift	clickhouse	Doris/Starrocks
AD (用户体验)	YES	YES	YES	NO	YES
隔离性和数据一致性（金融场景）	RC	SI	SI	NO	NO
写写并发能力	文件级别并发	文件级别并发	表级别并发	N/A	表级别并发

关东响马

好文[赞同]

好吃的蜡笔

「undo容易爆盘」应该是 GC 模式的问题吧