ES 支持乐观锁吗?如何实现的?

本篇主要介绍一下Elasticsearch的并发控制和乐观锁的实现原理,列举常见的电商场景,关系型数据库的并发控制、ES的并发控制实践。

并发场景

不论是关系型数据库的应用,还是使用Elasticsearch做搜索加速的场景,只要有数据更新,并发控制是永恒的话题。

当我们使用ES更新document的时候,先读取原始文档,做修改,然后把document重新索引,如果有多人同时在做相同的操作,不做并发控制的话,就极有可能会发生修改丢失的。可能有些场景,丢失一两条数据不要紧(比如文章阅读数量统计,评论数量统计),但有些场景对数据严谨性要求极高,丢失一条可能会导致很严重的生产问题,比如电商系统中商品的库存数量,丢失一次更新,可能会导致超卖的现象。

我们还是以电商系统的下单环节举例,某商品库存100个,两个用户下单购买,都包含这件商品,常规下单扣库存的实现步骤

  1. 客户端完成订单数据校验,准备执行下单事务。

  2. 客户端从ES中获取商品的库存数量。

  3. 客户端提交订单事务,并将库存数量扣减。

  4. 客户端将更新后的库存数量写回到ES。

示例流程图如下:

如果没有并发控制,这件商品的库存就会更新成99(实际正确的值是98),这样就会导致超卖现象。假定http-1比http-2先一步执行,出现这个问题的原因是http-2在获取库存数据时,http-1还未完成下单扣减库存后,更新到ES的环节,导致http-2获取的数据已经是过期数据,后续的更新肯定也是错的。

上述的场景,如果更新操作越是频繁,并发数越多,读取到更新这一段的耗时越长,数据出错的概率就越大。

常用的锁方案

并发控制尤为重要,有两种通用的方案可以确保数据在并发更新时的正确性。

悲观并发控制

悲观锁的含义:我认为每次更新都有冲突的可能,并发更新这种操作特别不靠谱,我只相信只有严格按我定义的粒度进行串行更新,才是最安全的,一个线程更新时,其他的线程等着,前一个线程更新完成后,下一个线程再上。

关系型数据库中广泛使用该方案,常见的表锁、行锁、读锁、写锁,依赖redis或memcache等实现的分布式锁,都属于悲观锁的范畴。明显的特征是后续的线程会被挂起等待,性能一般来说比较低,不过自行实现的分布式锁,粒度可以自行控制(按行记录、按客户、按业务类型等),在数据正确性与并发性能方面也能找到很好的折衷点。

乐观并发控制

乐观锁的含义:我认为冲突不经常发生,我想提高并发的性能,如果真有冲突,被冲突的线程重新再尝试几次就好了。

在使用关系型数据库的应用,也经常会自行实现乐观锁的方案,有性能优势,方案实现也不难,还是挺吸引人的。

Elasticsearch默认使用的是乐观锁方案,前面介绍的_version字段,记录的就是每次更新的版本号,只有拿到最新版本号的更新操作,才能更新成功,其他拿到过期数据的更新失败,由客户端程序决定失败后的处理方案,一般是重试。

ES的乐观锁方案

我们还是以上面的案例为背景,若http-2向ES提交更新数据时,ES会判断提交过来的版本号与当前document版本号,document版本号单调递增,如果提交过来的版本号比document版本号小,则说明是过期数据,更新请求将提示错误,过程图如下:

使用外部_version实战乐观锁控制效果

虽然ElasticSearch的最新本版已经不再支持直接使用version字段实现乐观锁,但仍然允许利用外部版本号version实现乐观锁。

所谓外部版本号version,意思就是version字段的值不是由ElasticSearch自动生成的,而是在创建或修改文档时由应用程序在请求参数中明确指定的。

例如在生产实践中,我们通常使用关系型数据库作为主数据源,将数据从DB同步到ElasticSearch以提供数据搜索服务。而DB中的每行记录都会有update_time字段表示数据最后被更新的时间戳。我们可以利用这个时间戳作为外部版本号,以确保从DB同步数据给ElasticSearch的数据一致性。

删除之前的索引,执行如下命令重新创建一个新的文档;

PUT /book_store/_doc/97876381260?version=1638430097013&version_type=external
{
  "title": "零基础学Java",
  "ISBN": "97876381260",
  "price": 66.88, 
  "stock": 100
}

version_type参数的值是external,明确指定使用外部版本号作为文档version字段的值。

version参数的值是笔者写这篇文章时的时间戳,会作为文档的version字段的值。

该命令与普通的Index API类似,也是"先尝试创建一个新的文档,如果对应的文档已存在就更新那个文档"。但区别是当且仅当request中的version参数的值大于该文档中version字段的值时才会更新成功,否则就会报错表示并发冲突。

ElasticSearch收到该请求后返回如下结果;可以看到文档version字段的值就是创建文档时提供的外部版本号。

{
  "_index" : "book_store",
  "_type" : "_doc",
  "_id" : "97876381260",
  "_version" : 1638430097013,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 2,
    "failed" : 0
  },
  "_seq_no" : 0,
  "_primary_term" : 1
}

再执行一次与上面完全相同的命令,ElasticSearch会返回如下错误结果;

{
  "error" : {
    "root_cause" : [
      {
        "type" : "version_conflict_engine_exception",
        "reason" : "[97876381260]: version conflict, current version [1638430097013] is higher or equal to the one provided [1638430097013]",
        "index_uuid" : "NUfx6zIrQFGWcgh5NNwP4g",
        "shard" : "0",
        "index" : "book_store"
      }
    ],
    "type" : "version_conflict_engine_exception",
    "reason" : "[97876381260]: version conflict, current version [1638430097013] is higher or equal to the one provided [1638430097013]",
    "index_uuid" : "NUfx6zIrQFGWcgh5NNwP4g",
    "shard" : "0",
    "index" : "book_store"
  },
  "status" : 409
}

从错误原因可以看出,由于提供的版本号参数不大于文档中的版本号,所以导致了并发冲突的异常。

如果我们要更新这个文档,则必须用一个新的外部版本号,且这个外部版本号必须大于文档当前的version字段的值。

使用了一个新的时间戳构造文档更新请求;

PUT /book_store/_doc/97876381260?version=1638435446074&version_type=external
{
  "doc": {
    "stock": 99
  }
}

ElasticSearch收到该请求后返回如下结果;更新成功,且文档version字段的值已经被更新成新的外部版本号了。

{
  "_index" : "book_store",
  "_type" : "_doc",
  "_id" : "97876381260",
  "_version" : 1638435446074,
  "result" : "updated",
  "_shards" : {
    "total" : 2,
    "successful" : 2,
    "failed" : 0
  },
  "_seq_no" : 1,
  "_primary_term" : 1
}

_seq_no & _primary_term

_seq_no 和 _primary_term 是用来并发控制,和 _version不同,_version属于当前文档,而 _seq_no属于整个index。

_seq_no & _primary_term

  • _seq_no :索引级别的版本号,索引中所有文档共享一个 _seq_no

  • _primary_term:primary_term是一个整数,每当Primary Shard发生重新分配时,比如节点重启,Primary选举或重新分配等primary_term会递增1。主要作用是用来恢复数据时处理当多个文档的_seq_no 一样时的冲突,避免 Primary Shard 上的数据写入被覆盖。

if_seq_no & if_primary_term

在Elasticsearch中,if_seq_noif_primary_term 是用于乐观锁并发控制的参数,用于确保对文档的操作不会与其他操作产生冲突。

if_seq_no 参数用于指定期望的文档序列号(seq_no),而 if_primary_term 参数用于指定期望的 primary term。这两个参数一起作为条件,如果提供的条件与实际存储的文档序列号和主要项匹配,则操作成功执行;否则,操作将失败并返回版本冲突的错误。

假设我们有一个名为 my_index 的索引,其中包含 _id1 的文档。当前文档的 seq_no10primary_term1

示例 1:更新文档

PUT my_index/_doc/1?if_seq_no=10&if_primary_term=1
{
  "foo": "bar"
}

输出:

{
  "_index": "my_index",
  "_type": "_doc",
  "_id": "1",
  "_version": 11,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  }
}

在这个示例中,通过提供正确的 if_seq_noif_primary_term 条件,操作成功地更新了文档,并返回了更新后的版本号 _version

示例 2:更新文档,但条件不匹配

PUT my_index/_doc/1?if_seq_no=11&if_primary_term=1
{
  "foo": "bar"
}

输出:

{
  "error": {
    "root_cause": [
      {
        "type": "version_conflict_engine_exception",
        "reason": "[1]: version conflict, current version [11], provided version [11]",
        "index_uuid": "xxxxxxxxxxxxx",
        "shard": "0",
        "index": "my_index"
      }
    ],
    "type": "version_conflict_engine_exception",
    "reason": "[1]: version conflict, current version [11], provided version [11]",
    "index_uuid": "xxxxxxxxxxxxx",
    "shard": "0",
    "index": "my_index"
  },
  "status": 409
}

在这个示例中,由于提供的 if_seq_noif_primary_term 条件与实际存储的文档序列号和主要项不匹配,操作失败并返回版本冲突的错误。

通过使用 if_seq_noif_primary_term 参数,我们可以精确控制对文档的并发操作,并避免冲突。

复制代码
相关推荐
jwolf21 小时前
Elasticsearch向量搜索:从语义搜索到图搜图只有一步之遥
elasticsearch·搜索引擎·ai
你可以叫我仔哥呀2 小时前
ElasticSearch学习笔记三:基础操作(一)
笔记·学习·elasticsearch
hummhumm3 小时前
第 25 章 - Golang 项目结构
java·开发语言·前端·后端·python·elasticsearch·golang
java1234_小锋6 小时前
Elasticsearch中的节点(比如共20个),其中的10个选了一个master,另外10个选了另一个master,怎么办?
大数据·elasticsearch·jenkins
Elastic 中国社区官方博客6 小时前
Elasticsearch 开放推理 API 增加了对 IBM watsonx.ai Slate 嵌入模型的支持
大数据·数据库·人工智能·elasticsearch·搜索引擎·ai·全文检索
我的运维人生6 小时前
Elasticsearch实战应用:构建高效搜索与分析平台
大数据·elasticsearch·jenkins·运维开发·技术共享
jwolf26 小时前
摸一下elasticsearch8的AI能力:语义搜索/vector向量搜索案例
人工智能·搜索引擎
Mephisto.java11 小时前
【大数据学习 | Spark】Spark的改变分区的算子
大数据·elasticsearch·oracle·spark·kafka·memcache
mqiqe11 小时前
Elasticsearch 分词器
python·elasticsearch
小马爱打代码11 小时前
Elasticsearch简介与实操
大数据·elasticsearch·搜索引擎