mongoDB的事务

更新时间:2023-07-07 00:07:36 阅读: 评论:0

mongoDB的事务官⽹传送门:
MongoDB ACID 多⽂档事务⽀持
事务属性⽀持程度高中英语自我介绍
Atomocity 原⼦性单表单⽂档: 1.x 就⽀持
复制集多表多⾏:4.0 复制集分⽚集群多表多⾏4.2
fruits
rated rConsistency ⼀致性writeConcern, readConcern (3.2)
Isolation 隔离性readConcern (3.2)
Durability 持久性Journal and Replication
Atomocity 原⼦性
⼀个事务作为⼀个提交单位,要么⼀起成功要么⼀起失败,分布式关注的重点就是多节点之间数据的原⼦性控制。Consistency ⼀致性
读和写的⼀致性,会不会读到脏数据。
Isolation 隔离性
每个事务相互之间是独⽴的,每个事务内与主表之间也是互不影响、相互独⽴的。
Durability 持久性
数据落盘持久化,通过记录Journal⽇志⽂件和备份副本。
先从mongoDB的⼀致性相关的writeConcern, readConcern说。
什么是 writeConcern ?
writeConcern 决定⼀个写操作落到多少个节点上才算成功。writeConcern 的取值包括:
• 0:发起写操作,不关⼼是否成功;
• 1~集群最⼤数据节点数:写操作需要被复制到指定节点数才算成功;默认是1。
• majority:写操作需要被复制到⼤多数节点上才算成功。
• all:写⼊所有节点才算成功。
发起写操作的程序将阻塞到写操作到达指定的节点数为⽌
默认情况 w:“1”广州留学中介
⼤多数节点确认(即⼀半以上节点)  w: “majority”
全部节点确认 w: “all”
j:true
writeConcern 可以决定写操作到达多少个节点才算成功,journal 则定义如何才算成
功。取值包括:
• true: 写操作落到 journal ⽂件中才算成功;
• fal: 写操作到达内存即算作成功。
数据库数据写⼊的顺序数据在内存中先写⽇志⽂件(journal 中落地持久化⽇志⽂件),再写数据⽂件
mongoDB shell中使⽤
readPreference与readConcern
readPreference 设置分布式数据库从哪⾥读
readConcern 什么样的数据可以读
readPreference
readPreference 决定使⽤哪⼀个节点来满⾜正在发起的读请求。可选值包括:
• primary: 只选择主节点;
• primaryPreferred:优先选择主节点,如果不可⽤则选择从节点;
• condary:只选择从节点;
• condaryPreferred:优先选择从节点,如果从节点不可⽤则选择主节点;
• nearest:选择最近的节点;
场景举例:⼤量⾼并发读取的数据场景可以选择从节点,写⼊数据的时候,⽤主节点。
readPreference的配置⽅式
通过 MongoDB 的连接串参数:
• mongodb://host1:27107,host2:27107,host3:27017/?replicaSet=rs&readPre ference=condary
通过 MongoDB 驱动程序 API:
• MongoCollection.withReadPreference(ReadPreference readPref)
Mongo Shell:
• db.collection.find({}).readPref( “condary” )
readConcern
在 readPreference 选择了指定的节点后,readConcern 决定这个节点上的数据哪些是可读的,类似于关系数据库的隔离级别。可选值包括:• available:读取所有可⽤的数据;
• local:读取所有可⽤且属于当前分⽚的数据;
• majority:读取在⼤多数节点上提交完成的数据;
• linearizable:可线性化读取⽂档;
• snapshot:读取最近快照中的数据;
在复制集中 local 和 available 是没有区别的。两者的区别主要体现在分⽚集上。考虑以下场景:
• ⼀个 chunk x 正在从 shard1 向 shard2 迁移;
• 整个迁移过程中 chunk x 中的部分数据会在 shard1 和 shard2 中同时存在,但源分⽚ shard1仍然是chunk x 的负责⽅:
  所有对 chunk x 的读写操作仍然进⼊ shard1;
  config 中记录的信息 chunk x 仍然属于 shard1;
• 此时如果读 shard2,则会体现出 local 和 available 的区别:
  local:只取应该由 shard2 负责的数据(不包括 x);
  available:shard2 上有什么就读什么(包括 x);
注意事项:
• 虽然看上去总是应该选择 local,但毕竟对结果集进⾏过滤会造成额外消耗。在⼀些⽆关紧要的场景(例如统计)下,也可以考虑 available;
• MongoDB <=3.6 不⽀持对从节点使⽤ {readConcern: "local"};
• 从主节点读取数据时默认 readConcern 是 local,从从节点读取数据时默认readConcern 是 available(向前兼容原因)。
readConcern : ”majority” vs “local”
majority 如果有如下场景:
应业务需要做读写分离,主节点A主要做写⼊操作,从节点做读取操作;向主节点写⼊⼀条数据;⽴
即从从节点读取这条数据。
如果⽤默认配置local,有的复制集从节点B到主A可能是有延时的,⽽导致在主节点A上修改数据后,⽴刻在从节点读取,发现有脏数据,主从数据不同步。所以需要majority配置,和其他节点互交确认⼤多数据节点上都是⼀样的数据才返回。
#注意配置⽂件内rver参数开启
enableMajorityReadConcern:ture
#这种⽅式读取不到刚写⼊的数据
#使⽤ writeConcern + readConcern majority来解决vegetable可数吗
readConcern: majority 与脏读
MongoDB 中的回滚:
• 写操作到达⼤多数节点之前都是不安全的,⼀旦主节点崩溃,⽽从节还没复制到该次操作,刚才的写操作就丢失了;
• 把⼀次写操作视为⼀个事务,从事务的⾓度,可以认为事务被回滚了。所以从分布式系统的⾓度来看,事务的提交被提升到了分布式集群的多个节点级别的“提交”,⽽不再是单个节点上的“提交”。在可能发⽣回滚的前提下考虑脏读问题:
• 如果在⼀次写操作到达⼤多数节点前读取了这个写操作,然后因为系统故障该操作回滚了,则发⽣了脏读问题;
使⽤ {readConcern: “majority”} 可以有效避免脏读
readConcern: linearizable
只读取⼤多数节点确认过的数据。和 majority 最⼤差别是保证绝对的操作线性顺序:
在写操作⾃然时间后⾯的发⽣的读,⼀定可以读到之前的写(会在读取的节点,向其他所有节点发起确认请求)
人生就像跷跷板- 只对读取单个⽂档时有效;
- 可能导致⾮常慢的读,因此总是建议配合使⽤ maxTimeMS;
tomato怎么读
下图情况是在主节点⽹络异常时,从节点发起选举期间发⽣的脏读
readConcern: snapshot(最⾼级别)
{readConcern: “snapshot”} 只在多⽂档事务中⽣效。将⼀个事务的 readConcern
设置为 snapshot,将保证在事务中的读:
• 不出现脏读;
• 不出现不可重复读;
• 不出现幻读。
因为所有的读都将使⽤同⼀个快照,直到事务提交为⽌该快照才被释放。
pack
官⽹mongoDB Java Client 事务使⽤⽰例:
final MongoClient client = ate(uri);
/*
Prereq: Create collections. CRUD operations in transactions must be on existing collections.
*/
.withWriteConcern(WriteConcern.MAJORITY).inrtOne(new Document("abc", 0));
.withWriteConcern(WriteConcern.MAJORITY).inrtOne(new Document("xyz", 0));
/* Step 1: Start a client ssion. */
final ClientSession clientSession = client.startSession();
/
* Step 2: Optional. Define options to u for the transaction. */
TransactionOptions txnOptions = TransactionOptions.builder()
.readPreference(ReadPreference.primary())
.readConcern(ReadConcern.LOCAL)
.writeConcern(WriteConcern.MAJORITY)
.build();
/* Step 3: Define the quence of operations to perform inside the transactions. */ TransactionBody txnBody = new TransactionBody<String>() {
google翻译浏览器public String execute() {prep
MongoCollection<Document> coll1 = Databa("mydb1").getCollection("foo");        MongoCollection<Document> coll2 = Databa("mydb2").getCollection("bar");
/*
Important:: You must pass the ssion to the operations.
*/
coll1.inrtOne(clientSession, new Document("abc", 1));
coll2.inrtOne(clientSession, new Document("xyz", 999));
return "Inrted into collections in different databas";
}
};
try {
/*
Step 4: U .withTransaction() to start a transaction,
execute the callback, and commit (or abort on error).
*/
clientSession.withTransaction(txnBody, txnOptions);
} catch (RuntimeException e) {
// some error handling
} finally {
clientSession.clo();
}
java ⽰例2:
//MongoDB 多⽂档事务的使⽤⽅式与关系数据库⾮常相似:
try (ClientSession clientSession = client.startSession()) {
clientSession.startTransaction();
collection.inrtOne(clientSession, docOne);
collection.inrtOne(clientSession, docTwo);
}
db.fsyncLock() 与db.fsyncUnlock() 可以锁定/解锁节点的写⼊,可以⽤来做事务代码的测试。

本文发布于:2023-07-07 00:07:36,感谢您对本站的认可!

本文链接:https://www.wtabcd.cn/fanwen/fan/78/1082646.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:节点   数据   操作   事务
相关文章
留言与评论(共有 0 条评论)
   
验证码:
推荐文章
排行榜
Copyright ©2019-2022 Comsenz Inc.Powered by © 专利检索| 网站地图