ElasticSearch - 批量更新bulk死锁问题排查 | 京东云技术团队

原创

于 2023-07-05 14:08:48 发布 · 2k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#elasticsearch #京东云 #jenkins #bulk #死锁

文章描述了一个在618大促期间，由于商品变更MQ消息频繁，导致MQ消息积压和消费线程出现死锁的问题。问题源于BulkProcessor的重试策略和flush任务线程池的竞争，造成业务线程无法获取锁，进而引发死锁。提出了两种解决方案，包括升级ES客户端版本和调整重试逻辑。

一、问题系统介绍

监听商品变更MQ消息，查询商品最新的信息，调用BulkProcessor批量更新ES集群中的商品字段信息;
由于商品数据非常多，所以将商品数据存储到ES集群上，整个ES集群共划分了256个分片，并根据商品的三级类目ID进行分片路由。

比如一个SKU的商品名称发生变化，我们就会收到这个SKU的变更MQ消息，然后再去查询商品接口，将商品的最新名称查询回来，再根据这个SKU的三级分类ID进行路由，找到对应的ES集群分片，然后更新商品名称字段信息。

由于商品变更MQ消息量巨大，为了提升更新ES的性能，防止出现MQ消息积压问题，所以本系统使用了BulkProcessor进行批量异步更新。

ES客户端版本如下：

        <dependency>
            <artifactId>elasticsearch-rest-client</artifactId>
            <groupId>org.elasticsearch.client</groupId>
            <version>6.5.3</version>
        </dependency>

BulkProcessor配置伪代码如下：

        //在这里调用build()方法构造bulkProcessor,在底层实际上是用了bulk的异步操作
        this.fullDataBulkProcessor = BulkProcessor.builder((request, bulkListener) ->
                fullDataEsClient.getClient().bulkAsync(request, RequestOptions.DEFAULT, bulkListener), listener)
                // 1000条数据请求执行一次bulk
                .setBulkActions(1000)
                // 5mb的数据刷新一次bulk
                .setBulkSize(new ByteSizeValue(5L, ByteSizeUnit.MB))
                // 并发请求数量, 0不并发, 1并发允许执行
                .setConcurrentRequests(1)
                // 固定1s必须刷新一次
                .setFlushInterval(TimeValue.timeValueSeconds(1L))
                // 重试5次，间隔1s
                .setBackoffPolicy(BackoffPolicy.constantBackoff(TimeValue.timeValueSeconds(1L), 5))
                .build();

二、问题怎么发现的

618大促开始后，由于商品变更MQ消息非常频繁，MQ消息每天的消息量更是达到了日常的数倍，而且好多商品还变更了三级类目ID；
系统在更新这些三级类目ID发生变化的SKU商品信息时，根据修改后的三级类目ID路由后的分片更新商品信息时发生了错误，并且重试了5次，依然没有成功；
因为在新路由的分片上没有这个商品的索引信息，这些更新请求永远也不会执行成功，系统的日志文件中也记录了大量的异常重试日志。
商品变更MQ消息也开始出现了积压报警，MQ消息的消费速度明显赶不上生产速度。
观察MQ消息消费者的UMP监控数据，发现消费性能很平稳，没有明显波动，但是调用次数会在系统消费MQ一段时间后出现断崖式下降，由原来的每分钟几万调用量逐渐下降到个位数。
在重启应用后，系统又开始消费，UMP监控调用次数恢复到正常水平，但是系统运行一段时间后，还是会出现消费暂停问题，仿佛所有消费线程都被暂停了一样。