江苏龙网

  1. 首页 > 生活 > >

数据库MVCC中，怎样判断并发事务能否Commit?

这个问题问的是MVCC中，写写冲突的处理流程。一般是以读写冲突的处理来说明MVCC的优点。比如对于数据项A，它的数据版本为A1-\u0026gt;A2-\u0026gt;A3，最新版本是A3。如果事务X在读写数据项A时，A1和A2已提交的，事务Y正在修改A3，那么A3可以被提交，也可能被回滚。在使用锁协议时，事务X要等待Y结束，才能判断是否读到A3。在MVCC中，事务X可以读取已经提交的A2，而不必等待A3。这么操作逻辑上是合理的，因为事务X读到了一个最新的已经提交数据，这不会带来数据不一致，也避免了读写操作的冲突等待。在上面的情况中，X可以读到A2，如果X要写A怎么办？从逻辑上说，A3不确定是提交还是回滚，X必须等待Y结束，才能开始写操作，因此MVCC的写写操作是需要在数据对象上加写锁的，因此对于同一数据对象的写写操作，MVCC也是串行执行的。由于实际业务中读操作事务数量要大于写操作事务，MVCC读写不冲突（不加锁），写写冲突（加做）的机制，能够提高读事务的执行性能，从而提高系统的整体性能。
■网友
你可以想简单点，变量x，两个线程试图修改，一个想做x +=2；一个想做x+=1；1. T1时刻，x=12. 线程A读到x=1，经过运算后试图将x改为3，此时A被系统调度走，排在cpu运行队列里面，所以此时A只是试图要把x改为3，实际还没做3. 线程B起来后也读到了x=1，于是试图将x改为2，并且很幸运的直接改成功了，于是x现在的值是24. 线程A再被调度运行的时候，是否能将x直接改为3呢？不可以。因为按照串行之行的要求，无论是先A后B还是反过来，x的值都应该是4。5. 问题变成A怎么办？这里就有两种基本思路，一个是悲观模式，即A在上面第二步开始加锁，避免任何人读写x，注意读也不行，除线程A外所有人不得操作x，一律等着，这样B起来后干瞪眼，拿不到x的锁就不会继续执行，于是x始终为1。等到轮到A执行的时候，x改为3；线程B如法炮制，先加锁再操作，最后x=4，结束。一个是乐观模式，A不加锁，到了第5步修改x的时候要判断x的值是否是之前读到的值x，很快就会发现x已经被修改了，于是A放弃修改x并重新读x，加2，再做类似事情。推广到事物是类似的，如果冲突严重也就是不同线程经常修改同一个变量，那么使用悲观模式，反之，乐观模式。悲观模式中线程A加锁时候禁止了读写，这是影响读的，MVCC来解决不可读问题，下面一并说明。所谓可重复读意思就是在某个事务没结束前，曾经读到了x=1，之后任何时候读都得是1，想想看如果A已经被修改为3，有人还想看到1怎么实现？那就是x=1，x=3同时保留，这样需要1的线程就被满足了，一个变量保留多个值就是mv，这个技术用于事务处理就是cc。手机码字有些地方简略了，网上文章挺多自己可以找找看。
■网友
参考杨冬冬的答案，觉得把MVCC的Validation操作类比为一个变量的并行修改不太合适，毕竟Validation操作需要扫描大量record，不是一个CAS操作就能解决的。最常见的解决方案就是在records上加锁（latches），我没仔细看过postgresql/Innodb的实现，可以参考这个答案：乐观锁和 MVCC 的区别？ - fleuria 的回答 - 另外随便翻了一下Tidb的实现：专栏（看MVCC那节），就是基于锁的。至于不用锁的方案，HEKATON（SQL-Server）号称整个系统中除了timestamp生成之外不含其他critical sections，可以参考它的论文: http://vldb.org/pvldb/vol5/p298_per-akelarson_vldb2012.pdf，不过猜测Validation时还是会用到锁。
■网友
雷锋来了https://en.m.wikipedia.org/wiki/Optimistic_concurrency_control事务提交的时候把该事务读过和写过的数据重读一遍，看看看看这些数据是否被修改过，如果没有被修改就可以提交
■网友
这里可以分3个问题来回答：1. 一条记录的MVCC结构(entry)可以看作: 注释:txid为1的事务已经提交，3和4更新了这条记录，但是还没有commit很多数据库在实现的时候都会直接锁这条entry，把并发转换为一个抢锁的顺序式更新。


推荐阅读


上一篇：如果只是为了玩游戏，我是该买一个PS4还是7000的神舟

下一篇：开发移动web应用啥调试工具比较方便呢