“多数"与“多数"之间的区别在于:术语“线性化"和“线性化". [英] The difference between "majority" and "linearizable"

查看:72
本文介绍了“多数"与“多数"之间的区别在于:术语“线性化"和“线性化".的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

几次阅读文档,但仍然无法理解多数"和线性化"行为的区别.阅读关注内容:

Read the docs a few times but still cannot understand the difference in the behavior of "majority" and "linearizable" read concerns:

"majority"
该查询将返回实例的最新数据,该数据已被确认已写入副本集中的大多数成员.

"majority"
The query returns the instance’s most recent data acknowledged as having been written to a majority of members in the replica set.

"linearizable"
该查询返回的数据反映了所有以多数"作为写关注点发出并在读取操作开始之前被确认的成功写操作.

"linearizable"
The query returns data that reflects all successful writes issued with a write concern of "majority" and acknowledged prior to the start of the read operation.

文档中还提到了一个选项"writeConcernMajorityJournalDefault",该选项设置为false,即使使用"linearizable"也可以回滚数据.

The docs also mention an option "writeConcernMajorityJournalDefault", it says that with that option set to false the data can be rolled back even when using "linearizable".

有人可以解释一下,这两个问题如何起作用,以及该选项如何影响他们?

Could someone explain please, how both concerns work and how this option impacts them?

推荐答案

"可线性化"在MongoDb 3.4中引入了阅读关注,以解决"多数"可能出现的问题阅读关注内容.

"Linearizable" read concern was introduced in MongoDb 3.4 to solve a possible issue with "majority" Read concern.

让我们尝试理解"多数"引起的问题,以了解"可线性化"给我们带来的好处.

Lets try to understand the problem with "majority" read concern to sense what "Linearizable" brings to us.

假设我们有一个3个节点的副本集,看起来像这样:

Suppose, we have a replicaset of 3 nodes, which looks something like this:

在哪里, A 是主要的, B 是次要的, C 是次要

Where, A is Primary, B is Secondary, C is Secondary

我们还有两个用户 Alice Bob ,它们将对位于" 用户"中的以下文档执行一些操作"集合.

Lets also have two users Alice and Bob, which will be performing some operations on following document which resides in "users" collection.

{
 "_id": 100234,
 "name": "Katelyn"
}

在时间点T0:

以下情况发生

At time instant T0:

following happens,

  1. Alice连接到 A (主要)并发出以下命令.
  1. Alice gets connected to A (primary) and issues following command.

db.users.find({"_ id":100234}); ->带有多数"字样的阅读

db.users.find({"_id":100234}); --> with read concern 'majority'

输出:

{"_id":100234,"name":"Katelyn"}

{ "_id" : 100234, "name" : "Katelyn" }

  1. B C 意识到 A 已停止响应并开始选举程序.(可能是由于网络分区 em>).
  1. B and C realizes that A has stopped responding and starts election procedure.(May be due to network partitioning).

在时刻T1:

以下情况发生

At time instant T1:

following happens,

  1. 由于选举过程, B代表新的主要候选人.

但是,直到未传达 A A 本身意识到自己需要降级为次要角色时,它才继续充当主要角色(通常是为了不过很短的时间.)

However, till the time A is not communicated or A itself realizes that it needs to demote itself to a secondary it continues serving as a primary (this is generally for a very small period of time though).

  1. Bob连接到 B (新的主节点)并发出以下命令.
  1. Bob gets connected to B (new primary) and issues following command.

db.users.update({"_id":100234},{$ set:{name:"Sansa"}})); ->与 写关注多数".

db.users.update( {"_id":100234}, {$set: {name:"Sansa"} } ); --> with write concern 'majority'.

  1. 鲍勃被确认为写信.

在时刻T3:

  1. Alice连接到 A (旧的主要服务器)并发出以下命令.
  1. Alice gets connected to A (old primary) and issues following command.

db.users.find({"_ id":100234}); ->阅读关注多数"

db.users.find({"_id":100234}); --> read concern 'majority'

输出:

{"_id":100234,"name":"Katelyn"}

{ "_id" : 100234, "name" : "Katelyn" }

即使在发布多数读取问题后,这里的爱丽丝也会获得陈旧的数据,也就是说,爱丽丝看不到鲍勃所做的写操作. 因此,在这种情况下,会补偿" Linearizability "的属性.

Alice here gets the stale data even after issuing the majority read concern, i.e the write made by Bob is not visible to Alice. Thus, the property of "Linearizability" is compensated in this case.

线性化的定义: 写入应该看起来是瞬时的.不精确地,一次写 完成后,所有以后的读取(后"由壁钟定义 开始时间)应返回该写入的值或a的值 以后写.读取返回特定值后,所有后续读取 应该返回该值或以后写入的值.

Definition of Linearizability: writes should appear to be instantaneous. Imprecisely, once a write completes, all later reads (where "later" is defined by wall-clock start time) should return the value of that write or the value of a later write. Once a read returns a particular value, all later reads should return that value or the value of a later write.

因此,出现了解决方案,即" linearizable "阅读问题.使用此属性,mongod会检查其主要节点并可以查看大多数节点 在发出读取操作的结果之前. 但是,使用这种针对多数"的阅读关注存在性能成本的损失,因此这不能替代多数"阅读关注.

Hence, comes the solution i.e "linearizable" read concern. With this property, mongod checks its primary and can see majority of nodes before issuing the results of read operation. However, there is a performance cost penality of using this Read Concern over "majority", thus this is not a replacement for "majority" read concern.

关于 writeConcernMajorityJournalDefault 属性,它只是一个副本集配置选项.它接受布尔值.

Regarding writeConcernMajorityJournalDefault property, it is merely a replica set configuration option. It accepts boolean value.

意味着,在大多数有投票权的成员已将其写入磁盘日志后,MongoDB会确认该写操作.

True means, MongoDB acknowledges the write operation after a majority of the voting members have written to the on-disk journal.

False 表示,在大多数投票成员将内存中的操作应用到该操作之后,MongoDB会确认该写操作.

False means, MongoDB acknowledges the write operation after a majority of the voting members have applied the operation in memory.

以上属性仅在以下情况下适用:使用写关注多数"并且未指定日记标记.

The above property is applicable only when, write concern "majority" is used and journaling flag is not specified.

这篇关于“多数"与“多数"之间的区别在于:术语“线性化"和“线性化".的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆