这里的“热点”不是说它同一时间承受了太多的负载，而是说您的测试不一定准确，比如（有可能）：
- 写入进程写入 1000，binlog 同步到 DM
- 检查进程从上游拿到当前结果为 1000
- 写入进程写入新结果 2000，binlog 到达 DM
- 检查进程拿到下游结果为 900，计算 lag 100
- DM 合并同步 1000 + 2000 -> 2000 到下游
这里可以去看一下 dm-worker 的 log，看看具体的 SQL 是在什么时候执行的，或许也能看到造成延迟的原因（比如，SQL 执行时间过长或者处理 binlog 的速度太慢）。
具体的延迟其实是可以参考 replication lag 指标的。像您业务上这种复杂的场景或许可以通过 sysbench 这种更加完备的测试工具来进行复现，再看看 replication lag 是否有波动或者持续在高位水平。如果您觉得延迟太大，或者有看到 replication lag 不断升高，可以上调 syncers 配置项的 worker-count 提高导入的并行度，但同时也会对上下游造成更大的压力；不过如果是由于下游 TiDB 的执行延迟过高，调大并行度可能并没有太大影响，所以还是需要确定一下造成具体延迟的原因。
另外附上 DM 各版本的性能测试报告给您参考一下：
https://docs.pingcap.com/zh/tidb-data-migration/v5.3/dm-benchmark-v5.3.0#dm-530-性能测试报告