mongodb事务机制浅谈(不是真正意义上的事务)

mongodb summary_2018/10

1、mongodb事务机制浅谈

1.1、概述

• 要了解mongodb的事务机制，需要先了解一下事务的概念、ACID特性、隔离机制等等，注意在这里的事务和关系型数据库，比如mysql的事务是有区别的。
• 我们先看一下mongodb对事务的支持：
  
• Tips：MongoDB在3.2之前使用的是“读未提交”，这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。

1.2、原子性(文档级别)

• 有些人也许会感觉到奇怪，什么是文档级别的原子性，这其实是由于mongo的文档相对复杂，文档可以嵌套子文档，比如：
  
• 所谓文档级别原子性，就是保证salary、jobs、hours全部更新成功，或者全部不更新成功。
• 再举一个例子：
  
• 如果要更新slary>500000的数据，此时就涉及到多文档的更新，如果更新途中发生机器故障等，服务器重启后已经更改的数据，不会回滚；那有什么方法可以解决这个问题吗？？可以通过建模来解决，即把需要更改的放到单行文档级别（比如全部放到子文档中）。

1.3、一致性

• 对于传统型数据库来说，数据一致性主要是在单机上，单机的问题主要是数据进来时的规则检验，数据不能被破坏掉。而在分布式数据库上，因为他们都是多节点分布式的，一致性往往就是讲的各个节点之间的数据是否一致。mongodb作为分布式数据库:
  
• MongoDB支持强一致性或最终一致性（弱一致性）:
  
• 有个问题，如果单机mongo的一致性呐，有数据规则效验？？

1.4、隔离性

• 在关系型数据库中，SQL2定义了四种隔离级别，分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。比如mysql的默认隔离级别是RC。
• MongoDB在3.2之前使用的是“读未提交”，这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。

1.5、持久性

• 对于数据持久性来说，在传统数据库中（单机）的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题，因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。
• 看一下mongo中的持久性：
  
• 从上图可以看出，MongoDB同样是使用数据进来先写日志（日志刷盘的速度是非常快）然后在写入到数据库中的这种方式来保证数据的持久性，如果出现服务器宕机，当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging（预写日志系统），而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好，MongoDB的复制默认节点就是三节点以上的复制集群，当数据到达主节点之后会马上同步到从节点上去。(具体实现：Write Concern机制)

1.6、多文档事务的支持

• Starting in version 4.0, for situations that require atomicity for updates to multiple documents or consistency between reads to multiple documents, MongoDB provides multi-document transactions for replica sets.（副本集支持）
• Tips：In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transaction should not be a replacement for effective schema design.(在大多数情况下，多文档事务比单文档事务具有更多的花销，推荐使用单文档事务+建模取代多文档事务)

1.7、参考文献

• MongoDB是如何实现事务的ACID？
• Atomicity and Transactions
• Transactions