MySQL批量更新数百万条数据致ES查询延迟飙升

某内部平台执行常规MySQL批量刷数操作（更新数百万条订单记录），引发下游Elasticsearch查询延迟显著上升。系统采用RCP平台（基于Flink）消费MySQL binlog，经清洗后同步至共享ES集群与Redis。此次刷数虽仅修改非查询字段（如内部标记位），但所有变更仍完整进入binlog并被同步任务捕获重写至ES。

故障期间，ES写入线程池满载、内部队列持续堆积，三次采样中完成写入文档数近乎为零；问题集中于少数热点分片——因数据分布不均或索引映射设计缺陷，大量更新请求路由至同一物理分片，叠加segment merge等后台任务，资源争抢致吞吐骤降。

Kafka引入未根本缓解：其仅提供消息持久化，RCP消费端无动态流控，积压恢复时消费者以最大吞吐拉取历史消息，形成二次写入洪峰。

应急措施已将共享ES集群拆分为B端与C端独立集群，实现物理隔离；长期改进聚焦两点：一是无效变更过滤，识别对ES查询无影响的字段更新并跳过写入；二是统一写入预算管理，从RCP层面对ES写入总量、速率、并发实施限流，并纳入重试与回放任务。

行业经验表明，数据同步需兼顾“精准”与“可控”，避免仅追求全量同步。当前要求刷数必须小批次推进，同步监控ES延迟、写入速率与积压量；平台级能力补全仍在落地中，包括CPU流控启用与分片均衡调整。