ES 写入瓶颈需要进行压测，才能确定实际是否达到瓶颈

筛查分析

普及：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 条速度基本一样
实践：国际财务针对此方法进行代码逻辑改造

开启并行数
理论上增加（并行数 / 批量数）的倍数并发处理能力
要求数据无序，针对乱序，数据存储，不影响业务

4.2.2 并行有序的方案

1）实现数据幂等性，增加缓存，并行消费策略

方案流程