京东云开发者｜mysql基于binlake同步ES积压解决方案 _生活百科

1 背景与目标1.1 背景国际财务泰国每月月初账单任务生成，或者重算账单数据，数据同步方案为mysql通过binlake同步ES数据，在同步过程中发现计费事件表，计费结果表均有延迟，ES数据与Mysql数据不一致，导致业务页面查询数据不准确，部分核心计算通过ES校验失败
1.2目标解决binlake到JMQ积压同步ES延迟问题
2 当前业务流程2.1 流程图现有业务基本流程如下图，包含运营端和外部数据接入，整体操作到数据存储流程

文章插图
2.2 数据流

文章插图
3 问题分析3.1 问题现象jmq积压，报警国内站截图如下

文章插图

文章插图
3.2 筛查分析普及：JMQ默认生产者发送消息QPS受到主题的broker数量影响，(8w/s)/broker
3.2.1 MQ积压分析1）分析原因一、ES写入量大，导致ES写入QPS瓶颈
ES写入瓶颈需要进行压测，才能确定实际是否达到瓶颈；通过查询集群负载，写入队列有无积压，cpu高不高，来定位以下为调整MQ批量消费大小后的ES监控写入队列无积压，CPU不高，写入QPS没有达到瓶颈

文章插图

文章插图
2）分析原因二、ES写入慢导致消费积压
ES解析服务解析慢，瓶颈在ES解析处根据当前系统CPU、负载信息定位是否服务器性能满负荷，是否扩容无报警信息，整体运行平稳，基本排除业务资源达到瓶颈问题引起写入慢

文章插图
MQ消费端消费慢，瓶颈在消费并发处当前主题分片数3，队列数为15，默认最大并发数为15*10，报警当时入队数500~700/s定位问题，为MQ消费慢，其根本原因为受到ES-Parse业务系统处理速度影响
3.3 临时处理方案开启mq并行消费策略，写入QPS显著增加

文章插图
4 如何提升消费速率，提升写入ES速率造成问题原因核心点是MQ积压，业务系统消费慢，MQ入队数大于出队数，导致积压
4.1 原理分析4.1.1 存储流程解析第一步：binlake订阅mysql binlog第二步：发MQ，JMQ数据传输第三步：消费JMQ数据，ES Paser数据解析，第四步：数据存储

文章插图
4.1.2 binlake基本原理

文章插图
4.1.3 binlake发送MQ过程

文章插图
4.1.4 JMQ消费原理JMQ消费默认就是批量消费消费原理如下图

文章插图
批量消费与并行消费原理如下图

文章插图
通过分析，在未开启并行消费前提下，当前主题最大处并发的消费处理能力即是队列数
4.2 提升消费速率的几种方案4.2.1MQ增加消费速度方法扩容，增加并发消费能力针对MQ默认情况下，一切扩容都能解决问题，增大分片数，增加队列数需要额外资源，申请扩容新的broker，同时考虑增加消费端实例
增加批量大小首先保证，业务系统(ES-Parse)消费MQ消息，处理10条和处理100条速度基本一样实践：国际财务针对此方法进行代码逻辑改造