数据库里那些冲突到底咋串行化处理，简单聊聊几种方法和思路

假装是单线程 串行化处理的终极目标，就是让一堆并发执行的事务，最终达成的数据状态，和它们某个顺序地、一个接一个执行的结果完全相同，只要做到了这一点，数据的一致性就有保证了，下面聊聊几种常见的实现思路和方法,它们各有各的招。

最笨但最保险的法子——真·排队（严格串行执行） 这招最简单粗暴了，你不是怕冲突吗？那咱就别并发了，所有事务都老老实实排队，数据库一次只处理一个事务，等这个完全结束了,再放下一个。

• 思路：就像只有一个柜员的银行，大家必须排队办理业务,绝对不可能出现互相干扰。
• 优缺点：好处是绝对安全，100%不会出现任何冲突导致的数据问题，坏处也显而易见：性能太差了！当只有一个事务在跑的时候，数据库的CPU、内存、磁盘大部分都在闲着，资源浪费严重，系统吞吐量会非常低，这通常只用在一些对一致性要求极高、但并发压力极小的特殊场景。

先拿票，后修改（两阶段锁 - 2PL） 这是最经典、使用最广泛的一种实现串行化的方法，很多数据库的默认隔离级别“可串行化”就是基于它或它的变种。

• 思路：它引入了一个“锁”的机制，事务在读写任何数据之前，都必须先申请并获得对应的锁，锁基本分两种：读锁（共享锁）和写锁（排他锁），它的核心规则很严格：
  1. 增长阶段：事务只能不断申请新的锁,不能释放任何锁。
  2. 收缩阶段：事务只能释放已经持有的锁,不能再申请新的锁。
• 为啥能串行化：通过锁的互斥性（写锁会阻塞其他所有锁）和两阶段的规则，它强制了事务之间的执行顺序，如果两个事务要操作同一个数据，那么它们必然会在锁的获取上分出先后，后一个必须等前一个释放锁,从而实现了类似排队的效应。
• 现实中的麻烦：这种方法虽然有效，但容易导致“死锁”——两个事务互相等待对方释放锁，卡死了，数据库得有死锁检测和解除机制，锁的粒度（是锁一整张表，还是锁一行数据）对性能影响巨大,锁多了还会严重影响并发度。

不锁了，事后验票（乐观并发控制 - OCC） 这个方法的思想很“乐观”：它假设事务之间冲突的概率很小，它允许所有事务“撒开了跑”，不加锁，效率很高，但在事务最终要提交的时候,它才来检查一下这段时间内有没有发生冲突。

• 思路：事务执行分为三阶段：
  1. 读阶段：事务可以随意读数据,并把要写的数据在自己的一块私人空间里准备好。
  2. 验证阶段：在提交前，检查一下从自己开始读到现在，有没有其他已经提交的事务修改过自己读过的数据，如果被改过了,说明有冲突。
  3. 写阶段：如果验证通过，就把私人空间里的修改正式写入数据库；如果验证失败,整个事务就回滚重试。
• 适用场景：这种方法在读多写少、冲突不频繁的环境下特别高效，因为大部分时间都不需要加锁,很多Web应用场景就符合这个特点。
• 缺点：万一冲突真的发生了，代价比较大，需要回滚重试，如果系统处于高冲突的状态（比如多人频繁抢购同一件商品），大量的事务会回滚,性能反而会急剧下降。

给数据贴上“版本号”（多版本并发控制 - MVCC） 这是现在很多现代数据库（如PostgreSQL、MySQL InnoDB）实现高并发的主流技术，它常常被用来实现“可串行化”以下的隔离级别，但通过一些增强（如PostgreSQL的可串行化快照隔离）也能达到真正的串行化效果。

• 思路：MVCC的核心是给数据保留多个历史版本，每当有事务更新数据时，它不是直接覆盖，而是创建一个新的数据版本，并打上时间戳或事务ID的标记，当一个事务读数据时，它看到的不是最新版本，而是启动时数据库的一个“快照”——即所有在该事务开始之前已经提交的数据版本。
• 如何避免冲突：这样一来，读操作和写操作通常就不会互相阻塞了，你读你的历史快照，我写我的新版本，大家井水不犯河水,极大地提高了读并发性能。
• 实现真串行化：但光靠快照读本身（即快照隔离级别）并不能解决所有冲突，比如可能遇到“写偏斜”这种诡异问题，要达成真正的串行化，数据库需要在MVCC基础上增加额外的冲突检测机制，PostgreSQL的可串行化隔离级别，就是基于MVCC，但它会动态监控事务之间的读写依赖关系，如果发现执行顺序可能无法构成一个串行化的历史,就果断中止后提交的事务。

总结一下 这几种方法没有绝对的好坏,只有合不合适。

• 真排队是理论基准,实用价值低。
• 两阶段锁（2PL） 是悲观的“保镖”，先控制住现场再办事，安全但开销大,可能阻塞。
• 乐观并发控制（OCC） 是乐观的“裁判”，让大家先自由竞赛，最后看结果裁定,低冲突时效率极高。
• 多版本并发控制（MVCC） 则像个“时光管理员”，通过管理数据的历史版本来让读写分离，是平衡性能和一致性的优雅方案,也是当前技术发展的主流。

数据库系统会根据不同的应用场景，选择或组合这些方法，在保证数据正确性的前提下,尽可能地提升并发处理能力。