ElasticSearch并发的处理方式:锁和版本控制
  TEZNKK3IfmPf 2023年11月14日 22 0

当我们使用 es 的 API 去进行文档更新时,它首先读取原文档出来,然后对原文档进行更新,更新完成后再重新索引整个文档。无论你执行多少次更新,最终保存在 es 中的是最后一次更新的文档内容。但是如果有两个线程同时去更新,就有可能出问题。

要解决问题,就是使用锁。

悲观锁

很悲观,每一次去读取数据的时候,都认为别人可能会修改数据,所以屏蔽一切可能破坏数据完整性的操作。关系型数据库中,悲观锁使用较多,例如行锁、表锁等等。

乐观锁

很乐观,每次读取数据时,都认为别人不会修改数据,因此也不锁定数据,只有在提交数据时,才会检查数据完整性。这种方式可以省去锁的开销,进而提高吞吐量。

在 es 中,实际上使用的就是乐观锁。

版本控制

es6.7 之前

在 es6.7 之前,使用 version + version_type 来进行乐观并发控制。根据前面的介绍,文档每被修改一个,version 就会自增一次,es 通过 version 字段来确保所有的操作都有序进行。

version 分为内部版本控制和外部版本控制。

内部版本

es 自己维护的就是内部版本,当创建一个文档时,es 会给文档的版本赋值为 1。

每当用户修改一次文档,版本号就会自增 1。

如果使用内部版本,es 要求 version 参数的值必须和 es 文档中 version 的值相当,才能操作成功。

外部版本

也可以维护外部版本。

在添加文档时,就指定版本号:

PUT blog/_doc/1?version=200&version_type=external
{
  "title":"2222"
}

以后更新的时候,版本要大于已有的版本号。

 

  • vertion_type=external 或者 vertion_type=external_gt 表示以后更新的时候,版本要大于已有的版本号。
  • vertion_type=external_gte 表示以后更新的时候,版本要大于等于已有的版本号。

 

最新方案(Es6.7 之后)

现在使用 ​​if_seq_no​​​ 和 ​​if_primary_term​​ 两个参数来做并发控制。

​seq_no​​​ 不属于某一个文档,它是属于整个索引的(version 则是属于某一个文档的,每个文档的 version 互不影响)。现在更新文档时,使用 ​​seq_no​​​ 来做并发。由于 ​​seq_no​​​ 是属于整个 index 的,所以任何文档的修改或者新增,​​seq_no​​ 都会自增。

现在就可以通过 ​​seq_no​​​ 和 ​​primary_term​​ 来做乐观并发控制。

ElasticSearch并发的处理方式:锁和版本控制

ElasticSearch并发的处理方式:锁和版本控制

PUT blog/_doc/b?routing=bntang&if_seq_no=1&if_primary_term=4
{
  "title":"6666"
}
【版权声明】本文内容来自摩杜云社区用户原创、第三方投稿、转载,内容版权归原作者所有。本网站的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@moduyun.com

  1. 分享:
最后一次编辑于 2023年11月14日 0

暂无评论

推荐阅读
TEZNKK3IfmPf