共计 3345 个字符，预计需要花费 9 分钟才能阅读完成。
✏️ 编者按：
在《一文解析数据库的三生三世》这篇文章中，咱们站在历史的角度意识了数据库的「前世今生」。文中提到在线事务处理等要害场景，那到底什么是数据库的事务？为什么数据库须要反对事务？为了实现数据库事务，各种数据库是如何设计的？让咱们一起来看看数据库事务的三个元问题吧！
什么是数据库事务
事务，就是用来保证数据操作合乎业务逻辑要求而实现的一系列性能。换句话说，如果数据库不反对事务，下层业务零碎的程序员就须要本人写代码，以保障相干数据处理逻辑的正确性。举个例子，数据库最开始遍及就是在金融业，银行的存取款场景就是一个最典型的 OLTP 数据库场景，而事务就是用来保障相似场景的业务逻辑正确性的。
（图片来自网络，侵删）
原子性：如果你要给家人转账，必须在你的账户里扣掉 100 块，在家人账户里加上 100 块，这两笔操作须要一起实现，业务逻辑才是正确的。然而程序在做批改时，必定会有先后顺序，试想一下程序扣了你的钱，这个时候程序解体了，家人账户的钱没有加上，那这 100 块是不是隐没了？你是不是要发疯？那么，就把这两笔操作放进一个事务里，通过原子性保障，这两笔操作要么都胜利，要么都失败。这样能力保障业务逻辑的正确性。
一致性：有很多文章讲过一致性，然而很多人会把一致性跟原子性混在一起说。事务的一致性指的是，每一个事务必须保障执行之后所有库内的规定仍旧成立，比方内外键、constraint、触发器等。举例来说，你在储蓄卡里有 100 元，理财账户里有 100 元，基金账户有 100 元，那么你在资产总和里会看到 300 元，这 300 元必须是三个账户余额加在一起失去的。你从储蓄卡里转出去了 100 元给家人，那么能够在数据库上创立触发器，当储蓄卡余额账户减 100 元的同时，把资产总和也同步减去 100 元，不然就会呈现逻辑上的谬误。你曾经转走了 100 元储蓄卡余额，理论资产总和应该是 200 元，若还是 300 元，数据库状态就不统一了。因而实现事务的时候，必须要保障相关联的触发器以及其余外部规定都执行胜利，事务才算执行胜利。如果在减去资产总额时出错，数据库就会进入不统一的状态 ， 那么这笔转帐交易也不能胜利。
那么一致性跟原子性的区别到底在哪里呢？原子性是指多个用户指令之间必须作为一个整体实现或失败，而一致性更多是数据库内的相干数据规定同时实现或失败。
持久性：事务只有提交了，对数据库的批改就会保留下来不会丢了。简略来说，只有提交了，数据库就算解体了，重启之后你刚存的 100 块仍然在你的账户里。
隔离性：每个事务绝对于其余的事务有肯定独立性、不能相互影响，因为数据库须要反对并发的操作来提高效率。在并发操作时，肯定要通过操作之间的隔离来保障业务逻辑的正确性。比方，你转帐 100 块给家人，一系列操作的最初一步可能是输出验证码，这个时候转帐还没有实现，然而在数据库里，你的账户对应的记录中曾经减去 100 块，家人账户也加了 100 块，就等着验证码输出当前，事务提交，实现操作。那么，这个时候，家人通过手机银行可能查到这 100 块么？你的答案可能是不能，因为你的转帐操作还没有提交，事务还没有实现，那么数据库就应该保障这两个并发操作之间具备肯定的隔离性，这样才合乎业务逻辑。
到底应该隔离到什么水平呢？隔离性又分为 4 个等级：由低到高顺次为 Read uncommitted（读未提交)、Read committed（读提交）、Repeatable read（可反复读取）、Serializable（序列化），这四个级别能够一一解决脏读、不可反复读、幻象读这几类问题。
怎么了解不同的隔离等级呢？首先要了解并发操作，并发操作就是指有不同的用户同时对一个数据进行读、写操作，那么在这个过程中，每个用户应该看到什么数据能力保障业务逻辑的正确性呢？
如果是后面存取款的场景，我看到的是曾经存进来的钱，也就是必须是曾经提交的事务。而 12306 刷火车票，你能够看到有 10 张余票，然而在下单的时候通知你票卖完了，因为同时有 10 个用户把票买掉了，你须要从新刷余票。这个也是能够承受的。也就是说我能够读到一些虚伪的余票，在业务上也没有什么问题。那么在设计这两个不同零碎时，就能够抉择不同的事务隔离级别来实现不同的并发成果。不同的隔离等级就是在零碎的并发性和数据逻辑的严谨性之间做出的均衡。
数据库如何实现事务
数据库实现事务会有多种不同的形式，但根本的原理相似，比方都须要对事务进行对立的编号解决，都须要记录事务的状态（是胜利了还是失败了），都须要在数据存储的层面对事务进行反对，以明确哪些数据是被哪些事务插入、批改和删除的。同时还会记录事务日志等，对事务进行系统化的治理以实现数据的原子性、一致性和持久性。
要实现事务的隔离性，最根底的就是通过加锁机制，把并发操作适当串行化来保证数据操作的正确逻辑。然而为了要保证系统具备良好的并发性能，必须要在实现事务隔离性时找到正当的平衡点。
大部分数据库（包含 Oracle、MySQL、Postgres 在内）在做并发管制的时候，都会采纳 MVCC（多版本并发管制）的机制来保证系统具备较高的并发性。不同数据库实现 MVCC 的具体计划不尽相同，但其基本原理相似。
MVCC 实现原理
所谓 MVCC，就是数据库中的同一查问依据相干事务执行的先后顺序以及隔离级别的不同，可能会存在不同版本的后果，通过这样的伎俩来保障大部分查问操作不会被批改操作阻塞并保证数据逻辑的正确性。简略来说就是，用存储空间来替换并发能力。
上面以 Postgres 为例介绍一下 MVCC 的一种实现形式，下图用以解释 Posrgres 里最根本的数据可见性是如何实现多版本控制的。
（图片来自网络，侵删）
首先，Postgres 里的每一个事务都有编号，这里能够简略了解为工夫程序编号，编号越大的事务产生越晚。而后，数据库里的每一行记录都会保留创立这条记录的事务号（Cre），也会在记录删除时保留删除这条记录的事务号（Exp），换句话说，只有 Exp 这里一列里记录了事务编号，就阐明这条记录被删除了。那么一个事务应该能看见哪些记录呢？Postgres 里每一个事务都会保留一个以后零碎的事务快照（Snapshot），这个快照里会保留事务创立时以后零碎的最高（最晚）事务编号，以及目前还在进行中的事务编号。在如上图所示的一个事务的快照里，最高事务编号为 100，目前正在进行的事务有 25、50 和 75。对应右边数据记录，这 6 行数据的可见性就如同标注的个别：
- 第一行，Cre 30，没有删除，在 100 这个工夫点，应该能看到。
- 第二行，Cre 50，没有删除，然而 50 这个事务还没有提交，正在进行中，所以看不见。
- 第三行，Cre 110，没有删除，然而 100 这个工夫点 110 事务还没有产生，所以看不见。
- 第四行，Cre 30，Exp 80，在 80 的时候数据被删掉了，所以看不见。
- 第五行，Cre 30，Exp 75，在 30 的时候被创立，75 时候被删掉了，然而 75 这个事务在 100 的时候还没有提交，这条记录在 100 的时候还没有删掉，所以看得见。
- 第六行，Cre30，Exp 110，在 30 的时被创立，110 时候被删掉，然而在 100 时候，110 还没有产生，所以看得见。
综上就是这个事务对这六条记录的可见性，也就是一个数据版本。大家能够看一下，如果另一个事务的快照里存的是最高事务编号为 110，正在进行的事务为 50，那么它能看到的数据应该是哪几行呢？
同时大家也看到，Postgres 里删除一行数据就是在这一行的 Exp 这个列记录一个删除事务的编号。相当于做了一个删除标记，而数据没有真正被删除，因而 Postgres 数据库须要定期做数据清理操作（Vacuum）。咱们这里假设所有的事务最终都是正确提交了，Postgre 在事实场景里的可见性比介绍的要简单，会存在某些事务没有提交的状况，这里不再开展。
Zilliz 以从新定义数据迷信为愿景，致力于打造一家寰球当先的开源技术创新公司，并通过开源和云原生解决方案为企业解锁非结构化数据的暗藏价值。
Zilliz 构建了 Milvus 向量数据库，以放慢下一代数据平台的倒退。Milvus 数据库是 LF AI & Data 基金会的毕业我的项目，可能治理大量非结构化数据集，在新药发现、举荐零碎、聊天机器人等方面具备宽泛的利用。
