1. 一个典型的“源头快、写入慢”的同步卡点前段时间在维护一套基于 FlinkCDC 的实时数据同步链路场景不算复杂把线上 MySQL 业务库的增量变更经过 FlinkCDC 捕获后写入下游 Kafka再由一个旁路任务继续分发到数仓和指标系统。整体链路跑了大半个月突然某一天监控告警显示同步延迟持续上涨从最初的秒级拉到了分钟级而且还在继续扩大。我先看了下 Kafka 侧的消费 Lag 和 MySQL 侧的 Binlog 位点推进情况发现了一个很典型的矛盾现象MySQL Binlog 的读取位点其实推进得并不慢说明 FlinkCDC 的 Source 端抓取能力还有富余但到了 Kafka 侧的写入 TPS 就是上不去分区间的消息积压越来越明显。继续深挖才发现问题根本不在网络、不在磁盘也不在下游集群而是落在了 FlinkCDC 任务本身的写入并行度上——并行度被限制住之后整条链路的同步性能被死死摁在了低位。这个问题的表面现象很简单但背后牵扯到的原理和排查过程我觉得很值得拆开来讲一遍。特别是如果你也在用 FlinkCDC 做实时数据同步或者正在为同步速率上不去发愁这篇文章应该能给你省下不少排查时间。先说结论FlinkCDC 数据同步的吞吐上限常常不取决于 Source 端的抓取速度而是被 Sink 端写入并行度所约束。一旦写入并行度和下游分区数、事务模型、连接池参数不匹配同步性能就会被卡在某个固定值附近怎么调 Flink 内存、怎么加资源都无济于事。下面我会从问题定位、并行度配置原理、实际解决方案三个角度展开并结合我这次踩坑过程中用到的排查命令和参数调整细节尽量还原整个处理过程让大家能直接照着去排查自己的同步任务。2. FlinkCDC 同步性能瓶颈的定位思路2.1 先搞清楚 FlinkCDC 的读写模型再谈性能很多同学一遇到 FlinkCDC 同步慢第一反应就是加资源、加并行度。但如果没搞懂 FlinkCDC 的读写模型盲目调参往往会适得其反。一个 FlinkCDC 同步任务本质上是一个 Flink 流式作业。作业内部包含两类核心算子Source 端算子负责读取 MySQL Binlog 或者执行全量快照扫描Sink 端算子负责把解析好的数据写入目标端。两类算子之间通过 Flink 内部的网络缓冲区进行数据交换Flink 任务框架会根据上下游并行度的配置将数据分发到不同的子任务上。在这条链路里Source 端并行度的实际含义和普通 Flink 任务不大一样。FlinkCDC 的 Source 端基于 Debezium 内核实现MySQL CDC Source 的单并行度上限受到表数量和分片策略的制约。对于单张表来说FlinkCDC 默认只能用一个并行度读取 Binlog因为 Binlog 本身是一条有序的字节流如果拆成多个并行度去读就会破坏事务的完整性产生一致性问题。这一点和 Kafka Source 天然支持多分区并行消费是完全不同的。而 Sink 端的写入并行度就灵活多了它指的是下游写入操作可以同时开启多少个并发连接。比如写入 Kafka Sink并行度决定了同时有多少个 Producer 实例向下游分区发送消息写入 JDBC Sink并行度决定了同时有多少个数据库连接在执行写入事务。所以我们在评估 FlinkCDC 同步性能时一定要有一个清晰的认识源头抓取能力只是一个方面真正限制同步吞吐量的往往是“数据变换处理节点”和“Sink 端写入节点”的并行处理能力。我这次遇到的性能问题恰恰就是从这两者之间的差距暴露出来的。2.2 排查性能问题先从监控指标定位瓶颈所在当同步延迟告警出现后我做了三步快速排查这套方法不仅适用于 FlinkCDC也适用于大多数 Flink 流式作业的性能定位第一步查看 Flink Web UI 中各个算子的 BackPressure 状态。BackPressure 高说明某个算子处理速度跟不上上游数据产生的速度数据在队列里排队等待。如果 Source 端出现高背压说明源头读取或解析速度已经成为瓶颈如果 Sink 端出现高背压说明问题出在写入侧。第二步对比 Source 端记录的 Binlog 位点推进速度和 Sink 端的实际写入速率。具体操作是在 Flink Web UI 中查看 Source 算子的“CurrentFetchEventTimeLag”指标同时在下游 Kafka 中查看消息堆积量。如果 Source 端位点推进快但 Kafka 消费 Lag 不减反增说明数据已经读出来了但写不进去瓶颈一定在 Sink 端。第三步查看 Sink 端算子的 busy 时间和 numRecordsOutPerSecond。busy 时间持续接近 100%说明 Sink 算子线程始终处于忙碌状态性能已经吃满numRecordsOutPerSecond 是实际的写出速率将这个值和 Source 端的读取速率做对比就能估算出吞吐缺口有多大。我当时看到的数据是Source 端读取速率在每秒约 2.1 万条记录的水平但 Sink 端写出速率只有每秒 5600 条左右而且 Sink 端 busy 时间长期处于 98% 附近BackPressure 状态为 HIGH。这就等于明牌了——数据在边界处被堵住了问题就出在 Sink 写入环节。2.3 资质不够并行度来凑并行度不是随便调的确认瓶颈在 Sink 端后我的第一反应是把 Sink 并行度调高。但这里的坑在于如果想给某个算子单独设置并行度必须要在代码里通过调用算子实例的 setParallelism 方法来实现。只改全局的 flink parallelism 参数对 FlinkCDC 的某些算子并不生效甚至会引发新的问题。这里需要理解 Flink 并行度传播的规则。如果在 env.execute 之前没有对某个算子调用 setParallelism该算子会继承上游算子的并行度。对于 FlinkCDC 的 Source 端算子如果我们没有显式设置并行度它会取全局并行度配置但真正读取这张表的子任务数量仍然受限于表的分片数量。当全局并行度设成 8而 FlinkCDC Source 端实际只有 1 个子任务在干活时剩下的 7 个子任务是空转状态不仅浪费资源还可能造成数据倾斜的表象。但 Sink 算子不同它的并行度直接决定写入端的并发连接数。如果 Sink 并行度设为 1哪怕全局并行度是 16写入任务依然只有一个子任务在运行其余资源都在等待这样同步性能自然上不去。我最初在定位问题时只增大了 TaskManager 的数量和堆内存结果同步速率毫无变化。原因很简单Sink 并行度没变写入端的并发能力就没有本质提升。后来我看了任务拓扑图才发现Sink 算子像“孤岛”一样挂在拓扑尾部并行度始终是 1所有的写入压力都集中在这一个子任务上。3. 并行度配置背后的原理与选型分析3.1 Sink 并行度到底是由什么决定的在实际配置 FlinkCDC 同步作业前我们需要先把 Sink 并行度的决定性因素梳理清楚。以我这次用的 Kafka Sink 为例Sink 并行度和目标 Topic 的分区数存在直接关系。如果 Topic 分区数是 6而 Sink 并行度设为 12那么实际运行时会有一部分子任务永远分配不到数据形成资源浪费如果 Sink 并行度设为 3那么每个子任务平均要负责 2 个分区的写入单个子任务的写入压力又会增大。理想的配置关系是 Sink 并行度和目标分区数保持一致或者 Sink 并行度为分区数的整数倍。这样既保证了每个子任务都有数据可写又不会因为子任务过多造成线程切换开销。对于 JDBC Sink例如写入 MySQL、PostgreSQL的场景并行度的设置还要考虑目标数据库的连接数限制和写入事务的冲突概率。我在另一个项目里遇到过一个更典型的场景Sink 连接的是 MySQL单库连接数上限是 200而我将 Sink 并行度盲目调到了 64结果连接池频繁报错大量事务因为连接等待而超时同步性能反而比之前更低。所以Sink 并行度不是越大越好需要结合下游能力综合评估。这里我整理了一个简单的配置参考表下游类型并行度设置建议主要限制因子Kafka与目标 Topic 分区数保持一致或整数倍分区数、Producer 吞吐JDBC 关系型数据库视连接池大小而定通常设为 8-16数据库连接数、锁竞争、事务冲突Elasticsearch与下游 ES 节点数和分片数对齐分片数、批量写入大小、索引 refresh 间隔Hive/Iceberg 等数仓结合文件大小和分区策略设定小文件数量、合并策略、下游计算资源3.2 FlinkCDC 全量加增量阶段的并行度差异还有一个特别容易踩坑的点FlinkCDC 任务在“全量阶段”和“增量阶段”的并行度表现是完全不同的。全量阶段是对表中已有历史数据进行快照扫描这个阶段 FlinkCDC 可以根据表的主键或唯一键将数据划分为多个 chunk每个 chunk 由一个独立线程去读取。所以全量阶段我们是可以设置多个并行度来加速扫描的。增量阶段则完全不一样增量数据流来自于 Binlog为了保证事务一致性和数据顺序FlinkCDC 只能用一个并行度消费 Binlog 事件。如果你在增量阶段观察到 CPU 使用率很低、Source 端并行度很高但大量子任务空闲不要惊讶这是 FlinkCDC 的内在机制决定的。这里有一个实操中常用的技巧在全量阶段可以临时调大 Source 并行度加速扫描进入增量阶段后再动态调整或人为约束并行度来节省资源。但在一个 Flink 作业中算子的并行度在作业启动后是无法动态修改的所以通常的做法是拆成两个作业一个专门做全量初始化一个做长期增量同步或者接受增量阶段的“单并行度限制”把调优重心放在 Sink 端和中间处理环节上。理解了这一点之后我们再回头看这次的性能问题就会发现真正的优化抓手并不在 Source 端。既然 FLinkCDC 的 Source 端增量读取天然只能单并行度而 Source 端的读取速率已经达到了每秒 2 万条以上说明源头不是瓶颈瓶颈就在下游的写入环节。这时候把 Sink 并行度调整到合理值往往立竿见影。3.3 为什么上下游并行度不匹配会造成背压Flink 的背压机制是理解这个问题的最后一块拼图。当 Sink 子任务写入速率低于上游传输给它的数据速率时Sink 端算子的输入缓冲区会逐渐占满然后通过反压信号一层层向上游传递。最终结果是 Source 端的读取也会被拖慢即使 MySQL 的 Binlog 还在不断产生Flink 也不会无限制地拉取而是在一个互相拉扯的平衡点上运行。这个平衡点就是那条让我头疼的“5600 条每秒”。表面上看是 Kafka 写入慢实际上是 Sink 算子的单并行度处理能力已经饱和。在 Sink 并行度为 1 的情况下所有写入压力都集中在一个子线程上该线程不仅要处理数据序列化、事务提交还要和下游 Kafka 建立网络连接、等待 ACK任何一个环节的耗时都会直接拉低整体吞吐。而并行度的作用在于把这条串行通道拆成多条并行通道让不同的子任务各自负责一批分区的写入从而将单个线程的瓶颈分散到多个线程上。这和“一个窗口只有一个收银员”与“多个窗口同时结账”之间的差别是同一个道理。写入并行度从 1 调到 8理论上单算子吞吐也能接近线性扩展当然前提是下游 Kafka 集群和 Topic 分区数撑得住。4. 实操解决写入并行度限制问题的完整步骤4.1 第一步确认当前作业的并行度配置状态在推进配置修改之前我先做了一次全面盘点确认当前作业的实际并行度情况。我用的是 Flink Web UI 中的“Job Graph”页面点开每个算子查看其“Parallelism”字段。这一步一定要仔细看因为不同版本的 FlinkCDC 在算子命名的展示上有差别有些版本显示为“Source: MySQL”和“Sink: Kafka”有些版本则显示为“TableSourceScan”和“StreamRecordWriter”。我这次作业中的显示结果是Source 端并行度为 1中间处理算子并行度为 8Sink 端并行度为 1。问题一目了然——变换算子和 Sink 算子之间出现了并行度的“剪刀差”数据经过处理算子并发处理后全部汇聚到单一的 Sink 子任务上形成明显的写入瓶颈。同时我也查看了 Sink 算子对应的“Metrics”面板重点关注了以下几个指标numRecordsOutPerSecond每秒写出记录数numRecordsInPerSecond每秒接收记录数currentInputWatermark当前输入水位busyTimeMsPerSecond每秒忙碌时间这些指标在 Flink Web UI 的任务管理器中可以直接看到也可以在 Prometheus 中通过 Flink Metrics Reporter 做长期监控。我建议在定位阶段重点关注 busyTimeMsPerSecond这个指标非常直观如果数值长期接近 1000说明该子任务已经饱和。4.2 第二步调整 Sink 端并行度并重跑任务确认问题出在 Sink 并行度之后我开始修改作业代码。以 FlinkSQL 方式实现的 CDC 同步为例设置 Sink 并行度的方法是在 INSERT INTO 语句后面加上提示例如INSERT INTO kafka_sink_table SELECT * FROM mysql_source_table;如果需要给这个 Sink 单独设置并行度可以使用 FlinkSQL 的 dynamic table options或者在 TableConfig 中指定SET parallelism.default 8;但这样设置的是全局并行度并不能精确控制 Sink 端。更精细的做法是在 DataStream API 中直接对 Sink 算子调用 setParallelism示例代码如下DataStreamString jsonStream tableEnv .toChangelogStream(resultTable) .map(new JsonSerialization()) .setParallelism(8); jsonStream .sinkTo(new KafkaSinkString().build()) .setParallelism(8);这段代码的关键点在于 map 阶段和 sink 阶段都设置了并行度 8确保处理算子和写入算子处在同一并发水平避免上游 8 个分区数据在下游汇聚到单个写入线程。我还额外调整了 Kafka Sink 本身的参数例如将 batch.size 调大到 3276832KB将 linger.ms 设置为 100让 Producer 能够攒一批数据再发送减少网络交互次数。这些参数在吞吐量调优中至关重要很多情况下并行度调上去了但如果 Producer 还是每条消息都立刻发送性能提升依然有限。4.3 第三步验证下游分区数是否匹配并行度和目标资源不匹配是写并行度调整中最常见的“隐藏雷区”。我这次作业的 Sink 并行度从 1 调到 8 之后第一次重启测试Kafka Topic 的分区数是 3结果发现 8 个并行子任务中只有 3 个子任务在真正工作其余 5 个子任务因为分配不到分区表现极其空闲。Kafka Producer 的分区分配策略默认是按照消息的 key 进行 hash如果消息 key 为 null则使用粘性分区策略将一个批次内的消息发往同一个分区。这种策略下Sink 并行度和 Topic 分区数如果不匹配会造成明显的数据倾斜和写入热点。后来我直接将目标 Topic 的分区数扩容到了 8 个和 Sink 并行度保持一致效果立刻不一样。这里不是说要盲目扩容分区而是在前期设计时就要规划好目标 Topic 的分区数通常建议分区数为 Sink 并行度的一倍到两倍既能满足并行写入需求又不会因为分区过多造成文件碎片和元数据膨胀。下表是我在这个环节调整前后的一组对比数据配置项调整前调整后Sink 并行度18Topic 分区数38平均写入速率条/秒562319380延迟秒持续增长稳定小于 5 秒背压状态HIGHOK可以看到Sink 并行度调整之后写入速率提升了接近 3.5 倍延迟指标也恢复正常。这个效果在我的项目中是立竿见影的整个过程从定位到验证完毕大约花了两个小时。4.4 第四步关注事务模型和连接池配置如果写入目标不是 Kafka 而是关系型数据库或者经过某种中间处理还需要额外关注写入的事务模型。JDBC Sink 并行度调大后同时写入数据库的连接数会成倍增加每个连接上的事务也可能因为并发写入产生锁等待和死锁风险。对于 MySQL 这类数据库建议在调大 Sink 并行度的同时将目标表的写入模式设置为批量更新Flink JDBC Sink 提供了 setBatchSize 和 setFlushInterval 两个参数用来控制攒批的条数和刷写周期。我在另一个项目中的实践值是 batchSize2000flushInterval5000ms这样能显著降低事务提交频率减少锁竞争。有些团队喜欢用 FlinkCDC 同步数据到 StarRocks 或 ClickHouse这类 OLAP 数据库对高频写入也有一套独立的优化参数比如 Stream Load 的 buffer 大小、channel 数量等。无论下游是什么核心思路是一样的写入端并发能力的提升必须和下游的并发承受能力、事务处理机制联合考虑。只调 Flink 端并行度不调下游连接池和攒批策略往往还是会被下游的某一项限制卡住。5. 常见问题与排查技巧实录5.1 Sink 并行度调上去了但速率不动是什么原因这个情况我在社区里看到好多人问过。并行度确实调到 8 了Web UI 上也显示 Sink 有 8 个并发子任务但整体写入速率还是和之前单并行度时差不多。这时候第一反应要看网络或磁盘但我实际测试过很多次最常见的其实是攒批参数没有跟上。以 Kafka Sink 为例如果 linger.ms 设置过小batch.size 又配置得很小那么即使有 8 个 Producer 并发每个 Producer 依然在频繁地发送极小的消息包网络往返时间完全主导了写入耗时。这种情况下并行度提高并不能降低单条消息的发送延迟速率自然上不去。相应的解决方案是确认批量发送参数足够宽松。我这里有一组可以用于生产环境的起点值linger.ms200-500batch.size32768-65536request.timeout.ms30000delivery.timeout.ms120000这几个参数配合 Sink 并行度一起调整写入速率曲线会有一个比较明显的跳跃提升。5.2 数据倾斜是不是也会影响 Sink 端性能会而且非常常见。FlinkCDC 捕获的数据在写入 Kafka 或数据库时如果消息 key 设置不均匀会导致某些 Sink 子任务分到大量数据而其他子任务处于空闲状态。这时候从 Web UI 上看Sink 端并行度是高了但实际只有少数几个子任务在忙碌整体写入速率依然上不去。解决办法是在数据序列化之前根据业务需要重新设计分区 key。如果需要保证同一主键的数据按顺序写入可以把主键作为 key如果更看重写入均匀性可以拼接一个随机字段或者在 key 中加入分区因子。这里需要做一个权衡强顺序保证和写入均匀性在某些场景下是不可兼得的。我当时遇到的情况是消息 key 用了用户 ID但业务数据中 80% 的变更集中在某几个头部用户身上导致个别分区持续积压。最后我改成用表名加随机后缀作为 key顺序性要求通过下游的窗口聚合去弥补Sink 端的写入倾斜立刻就缓解了。5.3 并行度设置和资源分配之间的关系Flink 任务的并行度设置会直接影响 TaskManager 的槽位分配。假设一个 TaskManager 有 4 个槽位如果作业的总并行度是 12那么需要至少 3 个 TaskManager 才能承载整个作业。当 Sink 并行度调大时如果 TaskManager 数量没有同步扩展作业可能因为槽位不足而一直处于重启或等待调度状态。所以在修改并行度配置时要同步检查作业的资源配置是否满足要求。公式很简单所需槽位 所有算子并行度的最大值。如果任务拓扑中某个算子的并行度为 8其中包含多个算子链实际占用的槽位数量还要考虑算子链的合并情况。不夸张地说我见过有同事只改了并行度忘了加 TaskManager 数量作业一直无法从 RESTARTING 状态恢复还以为是代码 bug。我的实操习惯是在提交 Flink 作业时通过参数显式声明并行度和槽位之间的关系例如flink run -d \ -p 8 \ -ytm 2048 \ -yD taskmanager.numberOfTaskSlots4 \ -c com.example.CdcSyncJob \ flink-cdc-sync.jar这里 -p 8 指定作业整体并行度-yD taskmanager.numberOfTaskSlots4 配置每个 TaskManager 的槽位数这样两个 TaskManager 就能提供 8 个槽位满足作业需求。5.4 全量阶段与增量阶段的性能表现差异还有一个用户经常忽略的问题FlinkCDC 作业在全量数据初始化阶段和增量同步阶段的写入性能差异巨大。全量阶段需要读取表中的所有历史数据数据量动辄几百万、上千万行此时如果 Sink 并行度设置很低全量初始化可能会跑几个小时甚至更久。而进入增量阶段后数据量是实时的、平缓的写入压力明显减小。但如果一个作业要用在全量和增量两个场景并行度配置会陷入两难全量阶段需要高并行度加速扫描和写入增量阶段并行度太高又浪费资源。我的建议是如果全量数据量较大千万行以上不要期望一次性搞定最好拆开处理。首先用 FlinkCDC 的全量阶段导出一份历史快照到临时表或临时目录然后启动一个独立的增量同步作业接续 Binlog 位点。这样全量和增量各自使用最优的并行度配置互不干扰。FlinkCDC 2.x 版本支持 checkpoint 记录位点增量作业可以从指定的 Binlog 文件名和位置开始消费完全可以实现两者的无缝衔接。6. 同步性能调优的进一步扩展思路如果上面的步骤你都走了一遍Sink 并行度、攒批参数、目标分区数都已经调到位同步速率仍然不能满足业务需求那么还可以从以下几个方向继续扩展优化思路。第一个方向是优化数据序列化格式。FlinkCDC 默认输出的 JSON 格式中包含大量元数据字段比如表名、数据库名、操作类型、主键信息等序列化之后的数据体积往往是原始 Binlog 事件的数倍。如果下游消费方并不依赖这些元数据可以在 Sink 之前做一次投影只保留业务需要的字段甚至直接使用 Avro 或 Protobuf 这类紧凑的二进制序列化格式。数据体积缩小之后网络传输时间和下游存储压力都会随之下降写入速率自然提升。第二个方向是降低数据采集的频率粒度。有些场景并不需要每一条变更都实时同步比如某些统计指标只需要分钟级别的聚合结果。这种场景可以用 Flink 的窗口函数在 Sink 之前做一次预聚合将细粒度的变更流聚合成粗粒度结果再写入下游。这相当于在整条链路的末端做了一次“数据压缩”减少写入的记录量Sink 的压力会成倍降低。第三个方向是引入中间缓冲层。如果短期峰值流量特别大Sink 端再怎么调并行度也无法消化瞬间涌入的数据可以考虑在 Flink 和最终目标之间加一层 Kafka 或者 Pulsar 作为缓冲。FlinkCDC 先写入 Kafka再由下游单独的消费任务写入最终目标。不要觉得这是多此一举这种“削峰填谷”的架构在很多大流量场景下是必要的因为 Kafka 的横向扩展能力远强于关系型数据库的写入能力。我在实际项目中曾经把 JDBC Sink 的同步链路改造成“FlinkCDC → Kafka → 独立消费者写库”的架构虽然链路多了一跳但整体稳定性反而提升了原因就在于 Kafka 能够容忍写入端的瞬时抖动而不会把背压直接传导到 FlinkCDC 的 Binlog 读取线程上。7. 踩坑记录几个曾经让我困惑的瞬间讲完了完整的解决过程再分享几个我在处理这类问题时踩过的具体坑希望大家能绕开。第一个坑是关于并行度和顺序性的误解。我在调整并行度之前一直担心并行度调大会破坏写入下游的数据顺序性。后来阅读 Flink 官方文档和实践验证后确认并行度本身不直接破坏键级别的顺序性只要 Partitioning 策略保证相同 key 的数据被分配到同一个下游分区并行度只是改变了处理通道的数量并不会打乱同 key 数据的先后顺序。这一点消除了我很多顾虑。第二个坑是关于 checkpoint 和并行度的关系。调整 Sink 并行度之前我特意检查了作业的 checkpoint 状态确认状态可以正常恢复。如果一个作业的状态数据量很大并行度调整之后状态恢复阶段会经历一次重新分配这个过程可能会产生额外的 IO 开销导致作业重启后的一段时间内性能下降。好在 Flink 的 Keyed State 重新分配机制会自动处理这种情况我只需要确保 checkpoint 间隔不要太短避免状态恢复和增量消费同时抢占资源就好。第三个坑是关于多个同步任务共享同一个下游连接池的场景。有一次我为了提升单个任务的并行度把两个 FlinkCDC 任务都配置了 16 的 Sink 并行度结果下游同一个 MySQL 实例的连接池被打满两个任务互相影响最终同步性能反而双双下降。这提醒我并行度的评估一定要从整个数据链路的全局视角出发不能只盯着单个 Flink 作业。下游能够承受的总连接数、总写入吞吐量才是最终的天花板。第四个坑也是让我印象最深的调整完并行度之后我盯着 Flink Web UI 看了一个小时发现写入速率指标始终没有变化几乎以为配置没有生效。后来才意识到Web UI 的指标面板有大约 30 秒到 1 分钟的刷新延迟而且在数据量不足的情况下平均值会被摊平看起来就像没有提升。正确做法是主动向下游 Topic 灌入一批压测数据用吞吐量的峰值来判断配置是否生效而不是看着平均值曲线焦虑。最后再分享一个小技巧如果条件允许建议在调整并行度之前先做一次 24 小时的基线监控记录下原有配置下的同步速率、延迟、背压状态和资源使用率。有了基线数据之后每做一次调优就能用真实的数字来评估效果而不是凭感觉判断“快了一点”还是“没变化”。这套方法我从这之后一直在用处理和排查大多数同步性能问题就都有据可依了。
