来自MongoDB的新年大礼： MongoDB 4.0将正式支持ACID事务！
来自MongoDB的新年大礼： MongoDB 4.0将正式支持ACID事务！
MongoDB CTO Eliot Horowitz 刚刚于2月16日凌晨在MongoDB西雅图大会上宣布（当地时间2月15日上午），MongoDB将在4.0版本中正式推出多文档ACID事务支持 。
“MongoDB 4.0 will add support for multi-document transactions, making it the only database to combine the speed, flexibility, and power of the document model with ACID data integrity guarantees. Through snapshot isolation, transactions provide a globally consistent view of data, and enforce all-or-nothing execution to maintain data integrity.” - Eliot Horowitz
“MongoDB 4.0 将支持多文档事务，届时MongoDB将成为唯一能够同时支持速度，灵活性，JSON文档模型优势 和ACID数据完整性保证的数据库。通过快照隔离，（MongoDB）的事务能够提供一个全局一致的数据视图，并可以实现all-or-nothing的事务提交及回滚机制，保证数据的完整性。”
这个功能的支持，完全不亚于2014年MongoDB引入WiredTiger存储引擎的影o响力。因为这个功能的引入，原计划是3.8版本的MongoDB将直接进入4.0时代。
在经历了许多年的等待之后，MongoDB在狗年的大年初一为我们带来了最好的新年礼物！事务，你终于来了！
MongoDB不是号称早就支持ACID吗？
是的。MongoDB很早就支持ACID事务，只不过是在单文档级别。这个是之前我在一个讲座中 和MySQL做的对比：
MongoDB的JSON文档结构可以汇聚相关联的数据。通过内嵌和数组把关系型内的父子关系或一对多关系等直接在一个JSON文档内予以表现。加上MongoDB对这样一个复杂结构的单个JSON文档的多个操作（修改多个字段，增加一个数组元素等）有原子性保证
今天宣布的，是对多文档事务的支持。多文档，或者关系型的多行事务支持，是默认就有的，也是大家熟悉的支持回滚的事务。
什么是多文档事务？
多文档事务，可以理解为关系型数据库的多行事务。在关系型的事务支持中，大家几乎无一例外支持同一事务内操作的原子性，即要么全部提交，要么全部回滚。这个同一事务内可以有多个操作，针对于多个表，或者是同一个表内的多行数据。
最为经典的例子就是银行转账，比如说在支付宝和微信发明之前，TJ向星爷借了20万买车， 现金交易略不方便，所以就通过转账，伪代码看上去像是这样：
正常情况下，从星爷账上扣20万，然后给TJ账上加20万，搞掂！但是如果最后一行的时候系统异常或者崩溃了？银行白赚20万吗？当然不会，两种方法防止这种情况发生：
1） 写一堆代码来处理，如异常时把星爷已经扣除的20万加回去，或者使用事务补偿机制自动对之前已经实现的业务做反操作
2） 让数据库的多行（多文档）事务来处理
在MongoDB里面，目前为止的解决方式都是第一种，比如说，自己实现二阶段提交，使用同步字段，任务队列，引入版本号等解决方案。支持多文档事务以后，只需要在代码放在一个事务（transaction）封装内，如下所示：
这个时候如果第6行再出问题，数据库会自动回滚这个事务内之前已经实施的（但尚未提交的）操作。
（注：实际银行转账都是通过异步队列方式，此处仅为示例说明）
在MongoDB里面我真的需要多文档事务吗？
只要你使用MongoDB并恰当地按照它进行模型设计后，很多时候多文档ACID 的要求不是非常必须 。因为传统的多表设计，在MongoDB内嵌模式的影响下，已经合并成少数几个集合（MongoDB Collection）之内。这个时候多行事务自然转换成了对单文档事务。这也是为什么MongoDB即使是在没有多文档事务的情况下，仍然成为今天最流行的非关系型数据库。
但是，回答必须是YES! 原因如下：
1） 你可能现在不需要多文档，但你也可能无法保证将来用不到。
2） 很多时候无法将所有的关系表都集成到一个集合里，比如一些多对多关系。多集合之间的关联数据一致性需要事务来维护
什么样的场景我会需要多文档事务？
非常之多：
· 一个业务涉及多个集合：
o 电商的下单，包含减库存，修改订单状态，推送到队列等一系列动作
o 银行转账
o 电信账单
o 金融交易
o 文件存储：二进制和元数据保持一致
· 一个业务涉及到多个文档：
o 每天晚上执行的批处理任务
o 2018一次性调整所有员工的工资级别！
事实上，目前不少用户在使用MongoDB的时候会采用混合模式，关系型+MongoDB并存的模式。这种模式的原因，很大程度上是因为MongoDB缺乏对多文档事务的支持，导致用户不得不把一些事务性较强的业务放到关系型数据库里面，然后用MongoDB来存储事务性较弱的数据。
MongoDB支持事务后是不是就和关系型数据库一样了？
随着事务支持的增加，MongoDB功能上更接近于关系型数据库，但是和关系型还是有本质上的区别：关系数据库是基于关系模型的，其固定化的数据模型严格死板，对新一代应用迭代式开发支持不好，对各种数据多变的场景如物联网或社交化都无法支持的很好。MongoDB的JSON模型则具有动态灵活，数据库无须下线就可以进行模式变迁升级，特别适用于敏捷式的开发环境。
从这个角度上来讲，具有事务性的MongoDB将比关系型数据库更具有竞争力。试想，一个成熟的具有大数据能力的分布式数据库，补足了最后一个关键的功能缺失（和关系型相比）后，它的想象力有多大？
启用事务后性能是不是会变慢？
对于不需要事务的应用，使用4.0 将不会有性能上的影响。
如果你需要启用事务，由于事务的处理会有一些额外开销，具体的影响取决于你事务内操作的数量，会有一定程度上的影响。但是这个就像启用授权、journal，同步等功能一样，是一个平衡。另外，MongoDB的性能的损耗尚可以通过扩展的方式来弥补。
分片集群也会支持事务吗？
4.0将首先在复制集内支持事务。目前 MongoDB的集群部署中复制集更大的一部分是复制集。MongoDB将在4.2里推出分片集群的多文档事务支持。
为什么到现在才支持事务？
事务支持，特别是对于一个分布式系统来说，是一个巨大的挑战。事实上，MongoDB在3年多前就开始了对事务支持的历程。下图说明了在3.0版本以后团队对事务支持开始做的一系列准备工作（绿色表示已完成，橙色表示进行中, 白色表示计划中）
事务支持大事
记：
- 3.0 ： 集成WiredTiger存储引擎
- 3.2 ： 优化改善复制协议，支持从多数节点读
- 3.4 ： 分片感知
- 3.6 ：
o 因果一致性：从节点读也保证强一致
o 逻辑会话
o 可重试写
o 集群级逻辑时钟
o Timestamp下推到存储引擎
o 分片里采用UUID机制
o In-place更新（而不是copy-on-write）
o 删除表使用二阶段提交
- 4.0：
o 复制集多文档事务支持
o 基于时间戳的恢复
o 复制集Point-in-time读操作
o 引擎支持prepared transaction
o 改进的rollback机制：依赖于WiredTiger的checkpoint
WiredTiger做了什么主要改动来支持多文档事务？
今年一月初，我们有幸邀请到了MongoDB存储引擎的研发总监Michael Cahill博士来到mongoing中文社区的年终大会分享。他分享的主要内容之一就是他们团队对事务支持上做的工作，包括：
o 删除表使用二阶段提交
o 集合元数据版本管理
o 时间戳下推到存储引擎
特别是时间戳这个改进是做了很大的重构，是支持事务中的隔离性和All/Nothing回滚的最重要的基石。Cahill博士介绍到，WiredTiger使用的是一种MVCC的存储结构，对文档的每一次更新是通过一个链式机制来管理历史改变和版本。每一个更新都是链条上的一个记录，包含Transaction ID和实际更新的数据。
在3.6以后，WiredTiger对这些更新操作增加了Timestamp（之前都是在MongoDB 复制协议级别处理操作的时序性），这样在存储引擎内就可以保证操作的严格时序。有了这个时间戳，存储引擎可以支持下述上层调用：
- “As of”time的读操作（事务开始点，读指定点数据 - Point in time read）
- “As of”time的写操作，用于事务提交时候来标记事务提交时间
如果想了解WiredTiger方面具体细节，可以到Mongoing中文社区回看中文社区2017年终大会的Cahill博士的演讲视频。（也可微信内搜索并关注mongoing中文社区获得视频直播信息）。
太棒了 – MongoDB4.0什么时候发布？
MongoDB 4.0将在2018年夏天发布，但是如果你现在就跃跃欲试，欢迎加入MongoDB的Beta试用项目：http://mongodb.com/transactions/。
关于作者：
唐建法（TJ）
MongoDB大中华区首席架构师 Mongoing中文社区联合发起人
一个开源软件的受益者，贡献者，和推广者。
此文中信息来自于以下官方来源：
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
https://www.mongodb.com/blog/post/multi-document-transactions
Safe Harbour Statement
The development, release, and timing of any features orfunctionality described for our products remains at our sole discretion. This information is merely intended to outline our general product direction and it should not be relied on in making a purchasing decision nor is this acommitment, promise, or legal obligation to deliver any material, code, orfunctionality.