数据同步一旦变慢，业务侧通常最先察觉：报表数据对不上，缓存里还是旧值，目标库落后源库越来越多。阿里云 DTS（Data Transmission Service，数据传输服务）是阿里云提供的托管数据传输服务，常用于迁移、同步和变更订阅。延迟问题很少出在某一个按钮上，多数情况下要沿着链路逐段排查。
一、DTS 是什么，延迟从哪里来
DTS 的基本思路是读取数据库的增量日志，例如 MySQL 的 binlog，再按顺序把变更回放到目标端。换句话说，延迟就是变更已经写进源库，却还没有落到目标库的那段时间。这段时间拉长，原因无非三类：源库产生变更太快，链路传输太慢，或者目标库写入太慢。
从使用角度看，DTS 主要有三类能力：
- 数据迁移：把数据从自建库或其他云厂商的数据库搬到阿里云数据库，可以组合结构迁移、全量迁移和增量迁移。
- 数据同步：在两个数据源之间保持持续一致，常见于异地容灾、业务拆分和读写分离。
- 变更数据订阅：把变更记录投递给下游，用于缓存刷新、搜索索引更新和实时数仓入湖。
二、一个迁移场景：从停机导出到增量追平
某电商团队的订单库跑在自建 MySQL 上，数据量有数百 GB，白天写入一直没停。团队原本想用 mysqldump 导入导出，在测试环境里跑了六个多小时，而线上停机窗口只有凌晨一小段，这个方案行不通。下面是一个简化的示意案例，数字和步骤只用来说明思路。
后来他们改用 DTS，流程分三段：
- 全量迁移先把历史数据搬到目标库，这一步业务照常读写。
- 全量完成后自动转入增量同步，持续追平迁移期间产生的变更。
- 选在业务低峰期切换应用的数据库连接地址，确认数据无误后再停掉同步任务。
切换阶段的停机时间被压到几分钟以内。增量同步的好处是，团队不必依赖一次性的停机导出，切换时只需要处理最后一小段差异。这段差异越小，切换越稳，所以同步延迟一旦升高，切换风险会跟着上升。
同样的思路也适用于其他场景：
- 异地容灾：把核心业务库实时同步到另一地域，故障时可以更快切换。
- 搜索与缓存更新：订阅数据库变更，驱动 Elasticsearch 索引或 Redis 缓存刷新，业务代码里就不用再写双写逻辑。
- 实时分析：把交易库的变更投递到分析库，报表不必再等每天一次的批量任务。
三、同步延迟变高，先看这三处
遇到延迟升高，不要急着调参数或者重启任务。按下面三处逐一排查，通常能较快找到原因。
第一处：源库的写入压力
同步的输入是源库的 binlog。如果源库在某段时间出现大批量更新、大事务或批量删除，日志会突然变多，DTS 需要更多时间解析和回放。排查时把延迟曲线和业务高峰时段对照一下，看两者是否重合。如果是批量任务造成的，可以把它拆成小批次分次提交，或者挪到低峰时段执行。
第二处：网络链路
跨地域或跨云同步，最常见的问题是带宽不足或链路抖动。两端距离远，单次往返本来就慢，一旦出现丢包，重传会把延迟放大。上线前最好实测两端之间的带宽和时延，记下正常值，之后延迟升高时才有对比基准。如果同步任务和其他大流量业务共用一条专线，也要确认彼此不会互相挤占。
第三处：目标库的写入能力
目标库如果规格偏小、磁盘 IO 跑满，或者目标表缺少主键，回放速度会明显变慢。缺主键还会让更新操作难以定位记录，写入效率更低，也更容易出现重复或覆盖。这些问题最好在结构迁移阶段就处理，事后补救代价更高。查看目标库的 CPU、IO 和慢查询日志，通常能判断它是不是瓶颈。
四、迁移前的准备和切换前的检查
很多延迟问题在准备阶段就已经埋下。项目开始前，先确认源库的版本、字符集和存储引擎是否兼容，binlog 是否已开启且格式为 ROW。迁移账号只授予必要的最小权限，不要直接用超级管理员连接。
在测试环境完整演练一次，记录全量耗时、增量延迟和切换步骤。正式切流量前，对比两端的行数、校验和或抽样数据，两端一致后再切。
五、切换后的风险与回滚
切换只是开始。同步过程中如果有 DDL 变更，需要先确认目标端是否支持同步这类变更，否则数据可能错位。切换之后如果发现问题，要有反向同步或回切的方案，不能只规划正向迁移。另外，对同步延迟、任务状态和错误日志配置告警，链路一旦中断，能第一时间知道。
六、收尾
DTS 的价值在于把迁移和同步变成可以分阶段、可观测、可回退的操作。延迟高的时候，先看源库、链路和目标库这三处，比直接调参数更有效。落地时，建议先从非核心库演练，经验攒够了再推广到核心业务。
