AurorePaladin / AurorePaladin.github.io

个人主页。同时也通过 Issues 记录学习笔记
5 stars 1 forks source link

MongoDB事务开发 #64

Open AurorePaladin opened 2 years ago

AurorePaladin commented 2 years ago

MongoDB事务开发

写事务

什么是 writeConcern ?

writeConcern 决定一个写操作落到多少个节点上才算成功。writeConcern 的取值包括:

发起写操作的程序将阻塞到写操作到达指定的节点数为止。

注意:
默认MongoDB所谓的“写入成功”指写入到节点内存即算成功,无需等待数据真实写入硬盘(落盘)。

journal则定义如何才算成功:

  • true:写操作落到 journal 文件中才算成功
  • false:写操作到达内存即算成功

writeConcern 设置代码格式如下:

{
  writeConcern:{w:"majority",j:true,wtimeout:3000}
}

注意事项

  1. 虽然多于半数的 writeConcern 都是安全的,但通常只会设置 majority,因为这是等待写入延迟时间最短的选择。
  2. 不要设置 writeConcern 等于总节点数,因为一旦有一个节点故障,所有写操作都将失败。
  3. writeConcern 虽然会增加些操作的延迟时间,但并不会显著增加集群压力,因此无论是否等待,写操作最终都会复制到所有节点上。设置 writeConcern 只是让写操作等待复制后再返回而已。
  4. 应对重要数据,应使用 {w:"majority"},普通数据可以应用{w:1} 以确保最佳性能。

读数据

在读取数据的过程中,我们需要关注以下两个问题:

  1. 从哪里读? 关注数据节点位置
  2. 什么样的数据可以读?关注数据的隔离性

第一个问题是由 readPreference 来解决。
第二个问题是由 readConcern 来解决。

readPreference

readPreference 决定使用哪个节点来满足正在发起的请求。
可选值包括:

  1. primary:只选择主节点
  2. primaryPreferred:优先选择主节点,如果不可用则选择从节点
  3. secondary:值选择从节点
  4. secondaryPreferred:优先选择从节点,如果从节点不可用则选择主节点
  5. nearest:选择最近的节点

readPreference 场景举例

  1. 用户下订单后马上将用户转到订单详情页——primary/primaryPreferred。 因为此时从节点可能还没复制到新订单。

  2. 用户查询自己下过的订单——secondary/secondaryPreferred。查询历史订单时效性通常没有太高要求。

  3. 生成报表——secondary。报表对时效性要求不高,但资源需求大,可以在从节点上单独处理,避免对线上用户造成影响。

  4. 将用户上传的图片分发到全世界,让各地用户能够就近读取——nearest。 每个地区的应用选择最近的节点读取数据。

readPerference 与 Tag

readPerference 只能控制使用一类节点,Tag 则可以将节点选择控制到一个或几个节点。

考虑以下场景:

可以使用 Tag 来达到这样的控制目的:

  1. 为3个较好的节点打上{purpose:"online"}
  2. 为2个较差的节点打上{purpose:"analyse"}
  3. 在线应用读取时指定 online,报表读取时指定 reporting。

如何配置 readPreference ?

有3种配置方式:

第1种:通过 MongoDB 的连接串参数
mongodb://host1:27107,host2:27107,host3:27107/?replicaSet=rs&readPreference=secondary

第2种:通过 MongoDB 的驱动程序 API
MongoCollection.withReadPreference(ReadPreference readPref)

第3种:Mongo Shell
db.collection.find({}).readPref("secondary")

注意事项

  1. 指定 readPreference 时也应注意高可用问题。例如将 readPreference 指定 primary,则发生故障转移不存在 primary 期间将没有节点可读。 如果业务允许,则应选择 primaryPerferred。

  2. 使用 Tag 时也会遇到同样的问题,如果只有一个节点拥有一个特定 Tag,则在这个节点失效时将无节点可读。 这在偶时候是期望的结果,有时候不是。 例如:

  1. Tag 有时需要与优先级、选举权综合考虑。例如做报表的节点通常不会希望它称为主节点,则优先级应为 0 。

什么是 readConcern ?

在 readPreference 选择了指定的节点后,readConcern 决定这个节点上的数据哪些是可读的,类似于关系数据库的隔离级别。

可选值包括:

available 和 local

在复制集中 local 和 available 是没有区别的。两者的区别主要体现在分片集上。

考虑以下场景:

注意事项:

  1. 虽然看上去总是应该选择 local,但毕竟对结果集进行过滤会造成额外消耗。 在一些无关紧要的场景(例如统计)下,也可以看考虑 available。

  2. MongoDB <= 3.6版本,不支持对从节点使用 {readComcern:"local"}

  3. 从主节点读取数据时默认 readConcern 是 local,从从节点读取数据时默认 readConcern 是 available(向前兼容原因)。

majority 的实现方式

节点上维护多个 x 版本,MVCC机制:
MongoDB通过维护多个快照来链接不同的版本,每个被大多数节点确认过的版本都将是一个快照,快照持续到没有人使用为止才被删除。

majority 与 脏读(读到的数据是不干净的)

MongoDB 中的回滚:

所以从分布式系统的角度来看,事务的提交被提升到了分布式集群的多个节点级别的“提交”,而不再是单个节点上的“提交”。

在可能发生回滚的前提下考虑脏读问题:

使用{readConcern:"majority"} 可以有效避免脏读。

如何实现安全的读写分离

场景举例:向主节点写入一条数据,立即从从节点读取这条数据。

如何保证自己能读到刚刚写入的那条数据?

答:使用 writeConcern + readConcern majority来解决。

db.orders.insert({oid:34},{writeConcern:{w:"majority")});

db.orders.find({oid:34}).readPref("secondary").readConnern("majority");

linearizable

只读取大多数节点确认过的数据。和 majority 最大差别是保证绝对的操作现行顺序。

注意:

  1. 只对读取单个文档时有效
  2. 可能导致非常慢的时候,因此总是建议配合使用 maxTimeMS。

snapshot

{readConcern:"snapshot"} 只在多文档事务中生效。将一个事务的 readConcern 设置为 snapshot,将保证在事务中的读:

因为所有的读都将使用同一个快照,直到事务提交为止该快照才被释放。

多文档事务

MongoDB 4.2 开始全面支持了多文档事务,但并不代表大家应该毫无节制地使用它。相反,对事务的使用原则应该是:能不用尽量不用。

通过合理地设计文档模型,可以规避绝大部分使用事务的必要性。

为什么?
事务=锁、节点协调,额外开销,性能影响。

MongoDB ACID 多文档事务支持

多行,多表,多文档 一次性完成或都一个也不完成(数据回滚),这就叫 多文档事务。

事务属性 支持程度
Atomocity 原子性 单表单文档、复制集多表多行、分片集群多表多航
Consistency 一致性 writeConcern,readConcern
Isolation 隔离性 readConcern
Durability 持久性 Journal and Replication

事务的隔离级别

事务写机制

MongoDB 的事务错误处理机制不同于关系数据库:

注意事项: