ElasticSearch之并发操作处理

写在前面

并发控制,一般有两种方案,悲观锁和乐观锁,其中悲观锁是默认每次更新操作肯定会冲突,所以每次操作都要先获取锁,操作完毕再释放锁,适用于写比较多的场景。而乐观锁是默认每次更新操作都不会冲突,所以在更新前和更新后都不需要获取锁和释放锁的操作,所以效率更高,适合于读多写少的场景中。

在es中采用的是乐观锁机制,这也很好理解,因为es的定位是一个搜索引擎,所以一般是应用于读多写少的场景中。

1:es的乐观锁机制

有如下3中方式:

复制代码
1:每次更新文档的version都会+1
    这种方式已废弃
2:内部版本号控制,通过if_seq_no+if_primary_term
3:外部版本号控制,version+verion_type=exeternal,其中verison由外部数据源指定,如数据从MySQL同步

如果是数据在es中维护更新则采用2,内部版本号控制方案,如果是数据来自于外部数据源的同步,则采用3,外部版本号控制。

1.1:内部版本号控制

  • 插入数据

    DELETE products

    PUT products/_doc/1
    {
    "title": "iphone",
    "count": 100
    }

注意返回的_seq_no和_primary_term需要记住,在做并发更新控制时需要用到:

  • 指定if_seq_no和if_primary_term更新一次

    PUT products/_doc/1?if_seq_no=0&if_primary_term=1
    {
    "title": "iphone",
    "count": 100
    }

假定此时有一个并发修改也指定了?if_seq_no=0&if_primary_term=1则会因为乐观锁检测而失败:

1.2:外部版本号控制

外部版本号通过version=${外部版本号}&version_type=external完成,如下:

复制代码
DELETE products

PUT products/_doc/1
{
  "title": "iphone",
  "count": 100
}

假定外部版本号时10000:

复制代码
PUT products/_doc/1?version=10000&version_type=external
{
  "title": "iphone",
  "count": 100
}

其中version由外部数据源指定,此时如果有并发修改的话,同样会被乐观锁机制检测到异常:

写在后面

参考文章列表

相关推荐
Elasticsearch3 小时前
Elastic 社区通讯 — 2026 年 8 月
elasticsearch
lsh曙光3 小时前
ES数据备份与恢复
大数据·elasticsearch·搜索引擎
Shawn Dev7 小时前
MySQL Binlog 数据误删除恢复完全指南
数据库·mysql·elasticsearch
Elastic 中国社区官方博客9 小时前
用两行 JSON 替换你的 ILM 策略:数据流生命周期新增冻结层支持
大数据·运维·elasticsearch·搜索引擎·架构·全文检索
小张同学a.9 小时前
ELK企业级日志分析平台3——ES数据备份 & 集群监控 & ELFK+Kafka 架构部署
linux·运维·elk·elasticsearch·架构·kafka·filebeat
lsh曙光1 天前
ELK日志平台--elasticsearch部署
elasticsearch
Elasticsearch1 天前
训练量仅占 0.35%,竞争力却达到 100%:jina-embeddings-v5-omni 背后的冻结塔架构
elasticsearch
扶苏10021 天前
同一个 Git 项目整出两份,切分支互不影响?两种方案实测
大数据·git·elasticsearch
Elasticsearch1 天前
用两行 JSON 替换你的 ILM 策略:数据流生命周期新增冻结层支持
elasticsearch
AI大模型-小雄2 天前
Codex写分页接口为什么越翻越慢?用Cursor Pagination解决重复与漏数据
大数据·数据库·elasticsearch·搜索引擎·chatgpt·后端开发·codex