Elasticsearch并发写入版本冲突解决方案

这篇具有很好参考价值的文章主要介绍了Elasticsearch并发写入版本冲突解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

搜索公众号,AmCoder干货及时送达👇 

问题产生背景

众所周知,es经常被用于存储日志数据,其中在某些场景下,日志产生的时机不同,并且需要将多类具备关联关系的日志写入同一个document,就会带来同一个文档可能会被其它文档覆盖,或者missing等问题。

大家都知道es是不支持事务的,同时也不具备像关系型数据库那样可以关联查询的能力。所以我们如何将一个document在被完成后具备关联关系呢?我们需要遵循以下流程:

基础document创建------> 更新文档(_update/id) ------> 提交保存

而其中针对多类日志并发写入时,可能基础document结构还未创建,这是直接做update会直接报出document missing的问题,所以这就需要我们针对第一个接收到的日志数据在做update更新之前先做创建,并且需要文档锁级别的控制,才能保证在创建文档时不被后续涌入的数据直接update而报错document missing。我们通常使用

PUT http://ip:port/index/_doc/id?version=0&version_type=external

其中version代表当前document的版本号,所属范围时document级别,而version_type则为版本号类型,如果为external则需要后续更新的版本号需要比上一个版本号大,否则会报出异常。这就是我们今天要解决的问题,虽然用文档锁级别控制住了基础document的生成,但是后续的update操作无法控制由于并发而带来的版本号冲突问题。

问题表象

{
    "error":{
        "reason":"[20KB9MFIODLRPYET110091800X1169C685D4E1675646532216]: version conflict, required seqNo [3], primary term [1]. current document has seqNo [5] and primary term [1]",
        "index_uuid":"eHmesKN8RNC3KUSEFQE0Tw",
        "index":"logclient",
        "type":"version_conflict_engine_exception",
        "shard":"0",
        "root_cause":[
            {
                "reason":"[20KB9MFIODLRPYET110091800X1169C685D4E1675646532216]: version conflict, required seqNo [3], primary term [1]. current document has seqNo [5] and primary term [1]",
                "index_uuid":"eHmesKN8RNC3KUSEFQE0Tw",
                "index":"logclient",
                "type":"version_conflict_engine_exception",
                "shard":"0"
            }
        ]
    },
    "status":409
}

当Elasticsearch在写入或者删除的时候出现错误version_conflict_engine_exception时,表示当前写入或删除存在版本冲突。此时,status为409。其中,_seq_no和_primary_term分别是:

_seq_no:文档版本号,作用同_version,文档级别。

_primary_term:文档所在位置。索引级别

问题分析

在并发冲突的时候,我们有常用的两种策略:

  • 悲观锁并发策略

        在关系型数据库中,通过阻塞并排队的方式,来避免发生冲突。例如在读取数据时阻塞,来保证正在修改行数据的请求完成正常操作后,能够读取到最新的数据。这种方式的前提假设是数据冲突更有可能发生。

优点:方便,直接加锁,对应用程序来说透明,不需要额外的操作。

缺点:并发能力很低,同一时间只有一条线程操作数据。

  • 乐观锁并发策略

        乐观锁假设多用户并发的事务在处理时不会互相影响,各事务能够在不产生锁的情况下处理各自影响的那部分数据,在提交数据更新之前,每个事务会先检查在该事务读取数据后,有没有其他事务又修改了该数据。如果其它事务有更新的话,正在提交的事务会进行回滚。相对于悲观锁,在对数据库进行处理的时候,乐观锁并不会使用数据库提供的锁机制。一般实现乐观锁的方式就是记录数据版本。

        数据版本是为数据增加一个版本标识,当读取数据时,将版本标识的值一同读出。数据每更新一次,同时对版本标识进行更新。当我们提交更新的时候,判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对,如果数据库表当前版本号与第一次取出来的版本标识值相当,则予以更新,否则认为是过期数据。

实现数据版本有两种方式,第一种是使用版本号,第二种是使用时间戳。

优点:并发能力很高,不给数据加锁,可以进行大量线程并发操作。

缺点:麻烦,每次更新的时间都要先比对版本号,然后可能需要重新加载数据,再次修改,再写;这个过程可能要重复好几次。

Elasticsearch中采用的是乐观锁的并发策略,这种方式的前提假设是数据冲突一般不会发生,从而避免阻塞数据请求。然而,在读和写之间,如果数据发生改变,更新就失败了,然后由程序决定如何进行后续的处理。

Elasticsearch内部如何基于_version进行乐观锁并发控制?

Elasticsearch的修改,如果没有带上version的时候,直接替换原来的文档,没有查询过程,多线程操作,不区分执行的先后顺序。这时候Elasticsearch并不阻止别的线程修改这条数据,极大的可能会出现数据回流或数据覆盖。

Elasticsearch是分布式的,文档的创建/变更等都会同步到其他节点。由于其异步性和并发的特点,这些同步请求都是并行的,因此并不能保证数据是按照修改顺序依次到达的。Elasticsearch保证了一个老版本的数据永远无法重写或覆盖新版本的数据。

在索引的Get和Delete请求中,都存在一个_version 字段。数据的变更会导致_version的值递增。第一次创建一个document的时候,它的_version内部版本号如果不指定就是1,后续,每次对这个document执行修改或者删除操作,都会对这个_version版本号自动加1。哪怕是删除,也对这条数据的版本号加1。

其实,每次删除一个document并不是立即进行物理删除的,因为它的一些版本号信息还保留着,比如先删除一条document,再重新创建这条document,会发现新建的这条document的_version版本号的值取自删除时_version的值再加1。

问题解决

那么,如何基于Es的version从而解决并发的更新时所带来的版本冲突问题呢?

方案一:retry策略

Elasticsearch再次获取document数据和最新版本号,成功就更新,失败再试;比如,设置尝试5次更新,retry_on_conflict=5,代表着最大更新5次,5次后不再尝试写入并且抛出异常。需要注意的是,retry策略在增量操作的无关顺序的场景中更适用,比如计数操作,数据写入的先后顺序对最终结果关系不大。其它的一些场景,比如库存的变化,订单的状态,直接更新为指定数值的,retry策略都不适用。除非可以在业务中将数据写入由顺序有关转化成顺序无关,才可以使用retry策略。

具体写法:http://ip:port/index/_doc/id/_update?retry_on_conflict=5

方案二:延时写入

直接回调写入会造成更多的版本冲突发生,虽然可以解决问题但依然存在风险。结合对Elasticsearch的写入机制的深入理解,尝试跳出Elasticsearch本身,在业务侧解决Elasticsearch频繁更新同一document时出现的版本冲突异常。延时写入,将写入请求延迟处理。

一、使用Redis作为中间缓存,将一段时间内的同一document的写入请求缓存,key为document ID,value为变更字段的k-v格式。在这段时间内,后写入的覆盖先写入的,也就是将写入请求合并,只更新一次。

二、将写入失败的数据发送到rocketmq的队列中,按照document ID分区,做延时写入,顺序消费。

优点

  • 实现顺序写入,写入频次降低,大大降低并发冲突的发生。
  • 将数据存储在缓存和消息队列,保证数据不会丢失。

缺点

  • 在本就存在显示延迟的基础上,加大了延迟,具体的延迟指标需要结合集群规格,数据量级等综合考虑。
  • 容易造成消息堆积,如果消费出现异常需要重新消费。

方案三:回调写入

如果遇到status=409的异常直接回调当前写入方法重新写入,直到写入成功为止。以java代码为例,捕获到的异常为ElasticsearchStatusException。本以为当前方案会对Elasticsearch集群造成一定不良影响,但经过一周的观察,Elasticsearch集群的监控指标(包含GC频次)并无异常,但不能保证在更大的数据量级中不会发生其它异常。

优点

  • 开发成本低,可以解决retry策略无法解决的顺序写入的问题,回调写入方法即可。

缺点

  • 尝试写入的次数很高,且无法预估在大数据量级下中的直接回调写入会对集群性能造成何种影响,即使对集群进行扩容升级,也会变相提高成本。
  • 线程消亡或者等待队列溢出会造成数据丢失。
  • 如果当前写入执行了多次的回调写入,那么势必会影响分配到当前线程的其它写入,造成数据延迟,当然也可以通过加大线程池、升级服务器的方式提高性能,但毕竟是治标不治本的方法,一旦产生业务侧不可接受的延迟依然很麻烦。

方案四:Redis外部版本号 + setNx锁 + Rocketmq

采集到的binlog写入rocketmq的队列中(多队列),然后并发消费这些数据。使用表名为key,binlogID为value,在每次写入之前校验当前binlogID与Redis中存储的binlogID的大小,作为判断是否同步的条件,之后用Redis的setNx锁,锁住docID,目的是保证并发条件下,同一doc只有一次更新。如果以上两次校验有任何一次发生版本号异常,那么将此条消息原封不动的发送至队尾,并设置延迟消费(延迟级别根据具体情况分析),执行写入方法后catch出版本号异常,如仍存在版本号异常,即同样将消息发送至队列队尾,延迟消费。

以上简述的方案,虽然不能从根本上解决版本号异常的问题,但是却可以大大减少版本号异常发生的频次,同时也可以降低写入次数,并且当前文档更新的阻塞不会影响后续的数据同步,基本上解决了版本号异常对数据同步造成的堆积延迟。

目前这种方案,适用于外部控制版本号,针对互联网订单,消费的场景较多。文章来源地址https://www.toymoban.com/news/detail-418701.html


以上四种方案,根据不同的场景来使用,由于我的场景时并发多类日志的存储,并且每类日志在同一个document上所更新的字段不同且不要求顺序更新写入,所以针对文档锁级别的控制,方案一就足够了。

到了这里,关于Elasticsearch并发写入版本冲突解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 高版本SpringBoot兼容低版本ElasticSearch解决方案

    由于公司最近需要接入日志数据,然而日志数据在ElasticSearch(版本为 6.8.23)里面,但是接入数据项目使用的是Spring Boot 2.4.x版本,根据Spring Data官方提供的版本对应,明显对应不上,官方文档地址:Spring Data Elasticsearch - Reference Documentation Spring Data Release Train Spring Data Elasticse

    2024年02月07日
    浏览(27)
  • Elasticsearch 8.X 分词插件版本更新不及时解决方案

    球友在 ElasticSearch 版本选型问题中提及:如果要使用ik插件,是不是就使用目前最新的IK对应elasticsearch的版本“8.8.2”? 如果要使用最新es版本,而IK没有对应的,老师有推荐的其他类似插件吗?谢谢!——问题来源:https://t.zsxq.com/13YX8fFQy IK Analyzer 描述:基于词典的中文分词

    2024年02月07日
    浏览(45)
  • jar包冲突解决方案

    使用背景 在构建工程中,不可避免的引入多方依赖。从jar包冲突产生结果可大致分为两类: 1.同一个jar包出现了多个不同的版本。应用选择了错误的版本导致jvm加载不到需要的类或者加载了错误版本的类。 2.不同的jar包出现了类路径一致的类,同样的类出现在多个不同的依赖

    2024年02月09日
    浏览(33)
  • 【多线程】| 线程冲突解决方案

    同一进程内的线程是共享同一内存空间的,所以在多个线程的进程里,线程是可以同时操作这个进程空间的数据的,这样就容易造成线程冲突的情况。 举个小李子:一个房子里(代表一个进程),只有一个厕所(代表一个资源)。屋子里面有两个人A和B(代表两个线程),共

    2024年02月05日
    浏览(29)
  • Git_常用命令+代码冲突解决方案

    –local: 配置对当前仓库有效 –global: 配置对当前用户(指的是当前用于登录系统的用户)的所有仓库有效 设置用户名及邮箱 注意:由于此处设置的用户名中间有空格所以要使用双引号,正常设置时无需使用双引号 设置仓库的认证方式 credentail.helper后的参数可选: cache: 在第

    2024年04月14日
    浏览(40)
  • EIP-6963: 多钱包冲突的解决方案

    最近提出的 EIP-6963 旨在提供一个解决方案,以解决当用户试图在一个单一的网络浏览器中使用多个钱包供应商时出现的冲突问题。在这种情况下,这些冲突的钱包会导致用户体验下降,阻碍用户对其以太坊界面的控制,并使与 dApp 互动的过程变得复杂。 原始提案文档地址:

    2024年03月10日
    浏览(40)
  • git请求合并时出现冲突的解决方案

    请求合并时出现冲突,一般是有多人修改了同一个地方导致的,我们一般在本地解决好冲突后再上传到远端仓库,然后再次发起合并。 本流程适合无主分支权限的情况 在出现冲突的开发分支上解决流程: 1、先拉取主干分支 main到本地开发分支dev git pull origin main 2、借助工具

    2024年02月11日
    浏览(39)
  • 千万级数据并发解决方案(理论+实战) 高并发解决思路 方案

    课程地址 项目地址 秒杀 高并发 新闻系统 超大数据量 一般的网站 写入的少 读取的次数多 模糊查询 数据量少的时候可以用 like 数据量多的时候用 Elasticsearch搜索引擎 占用磁盘空间比较大 在laravel中 创建 要提前配置好数据库 在Tests文件中写入 运行命令 php artisan app:tests 生成

    2024年02月08日
    浏览(71)
  • mysql‘逻辑删除‘和‘唯一索引‘冲突的解决方案

    在user表中将name字段设置唯一索引,添加逻辑删除字段del_flag(1为删除,0为未删除)之后,将name=张四的字段删除,再添加一个name=张四的记录则会出现冲突 删除的时候将del_flag设置为null,未删除时候为0,冲突解决 在配置文件中这样配置:

    2024年02月10日
    浏览(29)
  • Three.js深度冲突(模型闪烁)与解决方案

    下面代码创建两个重合的矩形平面Mesh,通过浏览器预览,当你旋转三维场景的时候,你会发现模型渲染的时候产生闪烁。 这种现象,主要是两个Mesh重合,电脑GPU分不清谁在前谁在后,这种现象,可以称为深度冲突 Z-fighting 。 look 适当偏移,解决深度冲突,偏移尺寸相对模型

    2024年02月17日
    浏览(30)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包