RCP 是内部运行 Flink 同步任务的平台。
批量改了 MySQL，为什么用户查订单也变慢了？这次故障的关键，是数据库变化太快，下游 ES 接不住。
01 先看数据怎么走
MySQL 保存业务数据，binlog 像一本“变更流水账”。RCP 读取这本账，用 Flink SQL 整理数据，再写入 ES 或 Redis，供查询服务读取。
ES 是 Elasticsearch，适合搜索和筛选；Redis 常用来快速读取缓存或预先算好的结果。它们不一定与 MySQL 同时更新完成。
02 为什么最初这么设计？
早期只写 SQL 就能搭建查询数据，开发很快。后来任务和关联越来越多，各个任务都努力写，ES 却只有一份共享的处理能力。
03 刷数怎样引发故障？
“刷数”就是批量修改数据库。即使修改的字段不影响用户查询，也可能触发同步。多个任务同时写入，遇到热点分片处理变慢，积压就开始增长。
分片可以理解为 ES 中分担数据和工作的单元；数据或压力集中在少数分片上，就形成热点。
04 当时看到了哪些信号？
写线程忙满、队列增长，连续三次采样的完成数没有增加。它们说明写入进展严重受阻；还不能仅凭这些证明死锁或某个引擎缺陷。
05 已采取：拆分集群
把 B 端和 C 端分开，能减少相互影响。拆分配合迁移、扩容等措施用于恢复服务，但每个集群仍可能被过量写入压垮。
06 待开发：过滤不影响查询的变化
不能只看最终展示哪些字段，还要看关联、筛选和统计依赖哪些字段。只有相关值都没变，才考虑过滤；插入、删除仍要正确处理。
少 SELECT 几列，不代表 RCP 就一定不再写 ES。当前需要平台补能力。
07 待开发：所有任务共用写入预算
好比一座桥限制总通行量，不能只分别管理每条入口车道。平台要统一限制写入条数、数据大小和同时发送的请求数量，重试和回放也算在内。
目标是在 RCP 的 ES 写入模块统一建设，业务继续使用 SQL，不必各自开发 Java 消费者。
08 为什么加 Kafka 也不够？
Kafka 可以保留消息、支持回放，却不会自动让消费变慢。当前 RCP 消费 Kafka 也不支持限速，积压恢复时仍可能再次压垮 ES。
只需要暂停任务时，一段 RCP 作业也能暂停；确有独立保留或重建需求，再考虑拆两段。
09 大厂实践，借鉴原则
阿里 Havenask 的公开架构支持构建与服务分层；京东 POP 订单 B 端复盘 讨论了多次更新、大商家热点等问题。
值得借鉴的是隔离资源、减少重复更新、治理热点。这些资料不代表两家公司当前系统全貌，京东部分方案仍属于演进讨论。
10 最后，把状态分清楚
眼下可以小批刷数，观察 ES 查询延迟、写入完成量和同步积压后再继续。长期需要平台补齐两件事：少写无效变化，管住所有任务的总写入。
CPU 流控在所提供配置中未开启，能力与效果待验证；分片调整的完成情况也待确认。
进一步阅读：Flink ES 连接器参数 中的批量大小和失败退避不等于集群限速；Elastic 写入指南 建议过载时采用退避重试。本文没有未经验证的生产限速阈值或压测结论。
