关于数据库:一文读懂数据库中的乐观锁和悲观锁和MVVC

前言

在数据库的理论应用过程中，咱们经常会遇到不心愿数据被同时写或者读的情景，例如秒杀场景下，两个申请同时读到零碎还有库存 1 个，而后又先后把库存更新为 0，这时候就会呈现超卖的状况，这时候货物的理论库存和咱们的记录就会对应不上了。

为了解决这种资源竞争导致的数据不统一等问题，咱们须要有一种机制来进行保证数据的正确拜访和批改，而在数据库中，这种机制就是数据库的并发管制。其中乐观并发管制，乐观并发管制和多版本并发管制是数据库并发管制次要采纳的技术手段。

乐观并发管制

实质

维基百科：在关系数据库管理系统里，乐观并发管制（又名“乐观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发管制的办法。它能够阻止一个事务以影响其余用户的形式来批改数据。如果一个事务执行的操作读某行数据利用了锁，那只有当这个事务把锁开释，其余事务才可能执行与该锁抵触的操作。

事实上咱们常说的乐观锁并不是一种理论的锁，而是一种并发管制的思维，乐观并发管制对于数据被批改持乐观的态度，认为数据被外界拜访时，必然会产生抵触，所以在数据处理的过程中都采纳加锁的形式来保障对资源的独占。

数据库的锁机制其实都是基于乐观并发管制的观点进行实现的，而且依照理论应用状况，数据库的锁又能够分为许多品种，具体能够见我前面的文章。

实现形式

数据库乐观锁的加锁流程大抵如下：

• 开始事务后，依照操作类型给须要加锁的数据申请加某一类锁：例如共享行锁等
• 加锁胜利则持续前面的操作，如果数据曾经被加了其余的锁，而且和当初要加的锁抵触，则会加锁失败（例如曾经加了排他锁），此时需期待其余的锁开释（可能呈现死锁）
• 实现事务后开释所加的锁

优缺点

长处：
乐观并发管制采取的是激进策略：“先取锁，胜利了才拜访数据”，这保障了数据获取和批改都是有序进行的，因而适宜在写多读少的环境中应用。当然应用乐观锁无奈维持十分高的性能，然而在乐观锁也无奈提供更好的性能前提下，乐观锁却能够做到保证数据的安全性。

毛病：
因为须要加锁，而且可能面临锁抵触甚至死锁的问题，乐观并发管制减少了零碎的额定开销，升高了零碎的效率，同时也会升高了零碎的并行性。

乐观并发管制

实质

维基百科：在关系数据库管理系统里，乐观并发管制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发管制的办法。它假如多用户并发的事务在解决时不会彼此相互影响，各事务可能在不产生锁的状况下解决各自影响的那局部数据。

乐观并发管制对数据批改持乐观态度，认为即便在并发环境中，外界对数据的操作个别是不会造成抵触，所以并不会去加锁，而是在提交数据更新之前，每个事务会先查看在该事务读取数据后，有没有其余事务又批改了该数据。如果其余事务有更新的话，则让返回抵触信息，让用户决定如何去做下一步，比如说重试或者回滚。

能够看出，乐观锁其实也不是理论的锁，甚至没有用到锁来实现并发管制，而是采取其余形式来判断是否批改数据。乐观锁个别是用户本人实现的一种锁机制，尽管没有用到理论的锁，然而能产生加锁的成果。

实现形式

CAS（比拟与替换，Compare and swap）是一种有名的无锁算法。无锁编程，即不应用锁的状况下实现多线程之间的变量同步，也就是在没有线程被阻塞的状况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。实现非阻塞同步的计划称为“无锁编程算法”（Non-blocking algorithm）。

乐观锁根本都是基于 CAS（Compare and swap）算法来实现的。咱们先来看下 CAS 过程，一个 CAS 操作的过程能够用以下 c 代码示意:

int cas(long *addr, long old, long new)
{
    /* Executes atomically. */
    if(*addr != old)
        return 0;
    *addr = new;
    return 1;
}

CAS 有 3 个操作数，内存值 V，旧的预期值 A，要批改的新值 B。当且仅当预期值 A 和内存值 V 雷同时，将内存值 V 批改为 B，否则什么都不做。整个 CAS 操作是一个原子操作，是不可分割的。

乐观锁的实现就相似于下面的过程，次要有以下几种形式：

• 版本号标记：在表中新增一个字段：version，用于保留版本号。获取数据的时候同时获取版本号，而后更新数据的时候用以下命令:update xxx set version=version+1,… where … version="old version" and ....。这时候通过判断返回后果的影响行数是否为 0 来判断是否更新胜利，更新失败则阐明有其余申请曾经更新了数据了。
• 工夫戳标记：和版本号一样，只是通过工夫戳来判断。一般来说很多数据表都会有更新工夫这一个字段，通过这个字段来判断就不必再新增一个字段了。
• 待更新字段：如果没有工夫戳字段，而且不想新增字段，那能够思考用待更新字段来判断，因为更新数据个别都会发生变化，那更新前能够拿要更新的字段的旧值和数据库的现值进行比对，没有变动则更新。
• 所有字段标记：数据表所有字段都用来判断。这种相当于就、不仅仅对某几个字段做加锁了，而是对整个数据行加锁，只有本行数据发生变化，就不进行更新。

优缺点

长处：
乐观并发管制没有理论加锁，所以没有额定开销，也不错呈现死锁问题，实用于读多写少的并发场景，因为没有额定开销，所以能极大进步数据库的性能。

毛病：
乐观并发管制不适宜于写多读少的并发场景下，因为会呈现很多的写抵触，导致数据写入要屡次期待重试，在这种状况下，其开销实际上是比乐观锁更高的。而且乐观锁的业务逻辑比乐观锁要更为简单，业务逻辑上要思考到失败，期待重试的状况，而且也无奈防止其余第三方系统对数据库的间接批改的状况。

多版本并发管制

实质

维基百科: 多版本并发管制(Multiversion concurrency control，MCC 或 MVCC)，是数据库管理系统罕用的一种并发管制，也用于程序设计语言实现事务内存。

乐观并发管制和乐观并发管制都是通过提早或者终止相应的事务来解决事务之间的竞争条件来保障事务的可串行化；尽管后面的两种并发管制机制的确可能从根本上解决并发事务的可串行化的问题，然而其实都是在解决写抵触的问题，两者区别在于对写抵触的乐观水平不同(乐观锁也能解决读写抵触问题，然而性能就个别了)。而在理论应用过程中，数据库读申请是写申请的很多倍，咱们如果能解决读写并发的问题的话，就能更大地进步数据库的读性能，而这就是多版本并发管制所能做到的事件。

与乐观并发管制和乐观并发管制不同的是，MVCC 是为了解决读写锁造成的多个、长时间的读操作饿死写操作问题，也就是解决读写抵触的问题。MVCC 能够与前两者中的任意一种机制联合应用，以进步数据库的读性能。

数据库的乐观锁基于晋升并发性能的思考，个别都同时实现了多版本并发管制。不仅是 MySQL，包含 Oracle、PostgreSQL 等其余数据库系统也都实现了 MVCC，但各自的实现机制不尽相同，因为 MVCC 没有一个对立的实现规范。

总的来说，MVCC 的呈现就是数据库不满用乐观锁去解决读 - 写抵触问题，因性能不高而提出的解决方案。

实现形式

MVCC 的实现，是通过保留数据在某个工夫点的快照来实现的。每个事务读到的数据项都是一个历史快照，被称为快照读，不同于以后读的是快照读读到的数据可能不是最新的，然而快照隔离能使得在整个事务看到的数据都是它启动时的数据状态。而写操作不笼罩已有数据项，而是创立一个新的版本，直至所在事务提交时才变为可见。

以后读和快照读

什么是 MySQL InnoDB 下的以后读和快照读?

以后读
像 select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种以后读，为什么叫以后读？就是它读取的是记录的最新版本，读取时还要保障其余并发事务不能批改以后记录，会对读取的记录进行加锁。

快照读
像不加锁的 select 操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是未提交读和串行化级别，因为未提交读总是读取最新的数据行，而不是合乎以后事务版本的数据行。而串行化则会对所有读取的行都加锁

优缺点

MVCC 使大多数读操作都能够不必加锁，这样设计使得读数据操作很简略，性能很好，并且也能保障只会读取到符合标准的行。不足之处是每行记录都须要额定的存储空间，须要做更多的行查看工作，以及一些额定的保护工作。

实用场景

• 乐观锁

  • 用来解决读 - 写抵触和写 - 写抵触的的加锁并发管制
  • 实用于写多读少，写抵触重大的状况，因为乐观锁是在读取数据的时候就加锁的，读多的场景会须要频繁的加锁和很多的的等待时间，而在写抵触重大的状况下应用乐观锁能够保证数据的一致性
  • 数据一致性要求高
  • 能够解决脏读，幻读，不可反复读，第一类更新失落，第二类更新失落的问题

• 乐观锁

  • 解决写 - 写抵触的无锁并发管制
  • 实用于读多写少，因为如果呈现大量的写操作，写抵触的可能性就会增大，业务层须要一直重试，这会大大降低零碎性能
  • 数据一致性要求不高，但要求十分高的响应速度
  • 无奈解决脏读，幻读，不可反复读，然而能够解决更新失落问题

• MVCC

  • 解决读 - 写抵触的无锁并发管制
  • 与下面两者联合，晋升它们的读性能
  • 能够解决脏读，幻读，不可反复读等事务问题，更新失落问题除外

参考资料

维基百科
https://www.cnblogs.com/rinack/p/10032207.html
https://draveness.me/database-concurrency-control/

版权申明

转载请注明作者和文章出处
作者: X 学生
https://segmentfault.com/a/1190000023332101