MONGODB 谁说我没有事务，NOSQL 事务化

MongoDB 在4.0的时候已经开始支持了多文档的 ACID 和隔离，看上去好像对比传统数据库并没有什么值得称颂，但实际上着对于NOSQL的MONGODB是非常有意义的。

先用一个图来表达一下 3.6 和 4.0 在document事务上的不同，还是根据一贯的做法，先实践，在理论。

图中我们想几个问题，3.6 的两个update 如果有一个失败了，会影响另一个update的操作吗，3.6 和 4.0 的操作中，4.0在commit之前我们能否看到已经update的数据，但没有commit

我们在一台mongo database 4.0 社区版的服务器上

1 建立一个 test database

2 通过JS 来生成两个一样的临时数据collection

下面是一段python 完成多文档插入的事务，简易代码

下面我们返回来看看mongodb 4.0提供的多文档事务到底是怎样的来龙去脉。

1 多文档事务，必须建立在复制集的基础上，实际上我也试了，在单机mongodb上是无法完成多文档事务的。（会报错）

2 多文档事务不能用于sharding 集群 （想想都明白为什么不能）

3 仅在wiredTiger 数据引擎支持

4 进行操作时，collection必须已经存在

5 对collection的创建和删除操作，不能再事务中出现

6 对INDEX的创建，删除操作不可以在事务中出现

7 仅仅支持CRUD 操作，其他操作不能再事务中出现

8 仅仅对用户级别的collection 可以操作，系统级别的collection 或db 是不能操作的

9 对事务的大小的限制在 16MB

10 对事务的操作整体不允许超过60秒

11 虽然是事务，但也要尽快的操作完成，否则WireTiger中使用快照来操作维护事务，会造成大量的内存的使用不被释放。

12 事务不能再会话外运行（session）

13 一个session 只能一次运行一个事务，但可以运行多个session 并行运行事务

那下面我们做一个相关的例子，看看isolation是否在MONGODB中存在（查出两条的原因是因为我之前插入过一次数据）

首先整体操作是OK 的

下面我们清理一下数据，将已经插入的数据清空，然后分批的执行事务，但不commit, 来验证一下隔离的问题是否在MONGODB 中生效

在commit 后，相关的信息才能在其他的session中看到 （这就是传统数据库的 RC）

那既然有事务，就会有冲突，在不同的session中修改同一个数据，

自然就报错了。

通过错误可以看到，同时有两个修改同样记录的操作，后者（根据时间），会被自动kill 掉。

session.getDatabase("test").test.find({name:'timenocc'})WriteCommandError({

"errorLabels" : [

"TransientTransactionError"

],

"operationTime" : Timestamp(1587628382, 1),

"ok" : 0,

"errmsg" : "WriteConflict",

"code" : 112,

"codeName" : "WriteConflict",

"$clusterTime" : {

"clusterTime" : Timestamp(1587628382, 1),

"signature" : {

"hash" : BinData(0,"MIsoLQSNFGymhCFZrxcJj/OhuGQ="),

"keyId" : NumberLong("6818778345002500099")

到目前总结一下MONGODB 的事务

1 基本达到了传统数据库的RC级别的事务操作

2 可以进行ISOLATION RC 级别的事务隔离性

3 对多事务中的冲突可以检测，并根据事务的先后，将后来的事务终止，并报错

最后提一下Retryable Writes，这是一个在3.6引入的由于网络问题，造成写失效的补救措施，他会让MONGODB 在重试一次写，前提也是必须是 集群或分片。

这里如果使用事务的情况下，则不管这个Retryable Writes 是开还是关，事务都会在操作失败的时候，进行一次 Retryable Writes.

曾经听说一些关于MONGODB的话，他发展不起来，有局限性，其实到时觉得与其diss ,不如打开心门，迎接变化，就算diss 也先了解以后再说。