《一起学mongodb》之第五卷 事务

2022-04-08 16:28:44 浏览数 (1)
  • 前言
  • 写事务
    • 使用 writeConcern 保证数据准确落盘
  • 读事务
    • readPreference 来确定从哪里读
    • readConcern 来确定可以读什么样的数据
  • 多文档事务

前言

事务是 mongoDB 中非常核心的一个功能，在 4.0 版本以前，mongoDB 只支持单个文档的事务，在 4.0 和 4.2 版本之后，分别支持了复制集事务和分片事务，也可以说在大多数的数据库中都是非常重要的一个功能，值得我们单独拉一章去讲解

那「怎么样在 mongoDB 中合理的使用事务来保证数据安全呢」？

后续我将会从读、写和多文档事务这三个方向去阐述

写事务

使用 writeConcern 保证数据准确落盘

writeConcern 中有两个选项

  • w（决定一条数据落到写到多少个节点才算真正成功）
    • 0：不关心（最不安全）
    • 数字：写到 n 个节点才算成功（自定义）
    • majority：写入至少一半的节点才算成功（推荐，性能和安全均衡）
    • all：全部写完才算成功（性能差点，很安全，但是只要有一个失败就会失败）
  • j（决定怎样才算真正成功）
    • true：写入 journal 日志 才算成功
    • false：写入内存就算成功
代码语言：javascript复制
  db.collection.insert({a:1},{writeConcen:{w:"majority",j:true});

对于一些「普通数据可以使用 w:1 来确保最佳性能」，对于「重要数据可以用 w:majority 来保证数据安全」

读事务

readPreference 来确定从哪里读

readPreference 有几个属性

  • primary：只从主节点读
  • primaryPreferred：先读主节点，如果挂了再读从节点
  • secondary：只从从节点读
  • secondaryPreferred：先读从节点，如果挂了在读主节点
  • nearest：读最近的节点

「primiry 和 primaryPreferred 适用于对延迟敏感读较高」的数据，比如订单信息

「secondary 和 secondaryPreferred 适用于对延迟敏感度要求较低」的数据，比如日志信息

「nearest 适用于业务域较广的应用」，比如将业务信息同步到全球各地的节点，「中国用户会访问中国的节点，俄罗斯用户会访问俄罗斯的节点」， nearest 的判断也是比较简单的，直接是使用应用到 mongo 服务器的的 ping time 来决定

当然，还有一种是给「服务器打标签(tag) 的方式」，比如要将读取操作定向到标记有 "name": "a"和"key": "person"的辅助节点集：

代码语言：javascript复制
db.collection.find({}).readPref( "secondary", [ { "name": "a", "key": "person" } ] )

readConcern 来确定可以读什么样的数据

readConcern 有几个属性

  • available：读取所有可用的数据
  • loacl：读取所有可用且仅属于当前分片的数据
  • majority：读取大多数节点都写入的数据
    • 「通过快照来维护多个不同的版本，使用 MVCC 实现」，每个被大多数节点确认过的数据就是一个快照
  • linearizable：可线性化读取文档
    • 有时会被阻塞，其保证如果一个线程已经完成了写入并且告知了其他线程，那么这其他的线程就可以看到这些改动。如果某一瞬间你的副本集出现了两个主节点（有一个还未来得及降级）然后你从这个老的主节点上进行读取，与此同时新的主节点上已经有了新的数据，你读到的数据就是旧数据
  • snapshot：读取快照中的数据(类似于可串行化)

loacl 和 available 的区别体现在分片集群中的 chunk 迁移上，如果读 shard2 ，loacl 不能读到 x ，但是 available 可以读到

多文档事务

4.0 版本 mongoDB 支持了复制集的多文档事务 4.2 版本 mongoDB 支持了分片集群的多文档事务

也就是说是说，mongoDB 在 4.2 版本的是有拥有了和 mysql 这种关系型数据库一样的事务能力，这对于业务的选择角度来讲，又给 mongoDB 添加了一笔浓重的色彩

在整个数据库的分布式事务当中，还需要重点提一嘴的就是时间问题，我们先来看看会有什么问题存在

比如有两个操作发向 a、b 两个节点

  • 客户端将 a = 1 发向 a、b 节点
  • a 节点操作 a =1
  • 客户端将 a = a 1 发送给 a、b 节点
  • a 节点操作 a = a 1
  • b 节点由于业务网络等原因先执行了 a = a 1，后操作了 a = 1

最后我们就发现，a、b 两个节点的数据不一致了，那么 mongo 是怎么解决的呢，一般是两种方式：

  • 「全局授时」；比如我们可以采用GPS时钟或者是NTP服务这种全局授时点
  • 「逻辑时钟」：也就是我们采用一种局部的时间戳的方式去演进，这个就叫逻辑时钟。

mongo 采用的是「混合逻辑时钟」:

在这个混合逻辑时钟中，将物理时钟和逻辑时钟混合起来做一个全局的时间出来处理。我们的混合逻辑时钟会采用一种本地的推进方式，这个就是刚才说的一个接受的时候，他会比较本地的时间戳，然后在本地时间戳、本地真实的物理时间和收到最短 request 的时间，「三者取最大的时间，作为本地时间的一个推进」，需要说明的是，这个时间戳的分配是取决于 oplog 的时间戳。只有「当 oplog 真正写入数据的时候，本地的逻辑时钟才会向前推进」。在整个混合逻辑时钟，在整个集群中采用动态推进的方式，「每一条发送和接收的请求，都会依据请求中的时间来推进本地的时钟」，这样在全局的情况下，每个节点的混合逻辑时钟最终会趋同，趋向同一个地址，趋向同一个时间。这样的话，刚才说的时间偏差就已经不存在了，才可以在集群中做分布式事务。

再说说 mongo 提交事务的过程吧

mongoDb 的分布式事务和 mysql 一样，也是基于「两阶段协议」。

  • 第一阶段就是 prepare 阶段，在 prepare 过程中，所有的 coordinator 会向所有的节点去发送 prepare 命令，所有的节点收到了这个命令以后会返回自己的 prepare timestamp，然后由协调节点去决定选取一个最大的 prepare ts 作为 commit timestamp。

coordinator 和所有的 shard 之间的通讯会促使所有的事务参与者得到一个协调一致的 HLC。在这种逻辑时钟一致的情况下，commit timestamp 就是全局顺序一致的。

  • 第二阶段的话就是提交阶段， coordinator 会将刚刚的 committed ts 作为 commit timestamp 的时间戳，然后向所有的节点去广播。

需要关注一点，就是在对具有 prepare timestamp 的事务进行读取的时候，如果当前的事务是处于 prepare 状态的，并不确定自身的读时间戳和 prepare 状态的大小的话，需要去一直等待这个事务，等到事务提交或者 abort 以后才去会处理，这个就是刚才所说的。

https://mongoing.com/archives/77608 巨人的肩膀

mongoDB 整个事务实现的方式都是按照「读提交」这种关系来设计的，也就是说，在客户端读取数据的时候，只能读到该事务节点前已经做了 commit 的数据。

数据安全 unix mongodb 数据库

0 人点赞