先看一场真实到刺眼的事故。某电商业务库平时一天的 binlog 产出稳定在 20GB 上下，同步链路跑了一年多没出过事。大促当晚八点开始，订单表和库存表的写入翻了十几倍，零点前后 binlog 的产出速率冲到平时的 15 倍以上，一晚上写出去 180GB。值班的同学凌晨看了一眼监控，延迟曲线在涨，但想着「白天会追平」，就放着了。
第二天早上九点，数仓的看板还停在昨晚八点。更麻烦的不是停了十三个小时，而是——运维把积压的 binlog 量报出来之后，大家算了一下：按当前解析端的处理速度，把这一夜的变更追平要三个小时。也就是说，即便立刻开始修，上午的业务复盘、库存对账、实时推荐的特征，全部要在缺数据的状态下跑。而这三小时里，新的变更还在源源不断产生。
事后复盘，团队起初的判断是「网络带宽不够」。把链路两端的带宽都查了一遍，内网千兆只跑到 20% 出头，队列的写入也没到上限。真正被打满的是解析端那台机器上的两个东西：一个是单核 CPU——解析 binlog 的主线程把一颗核跑到了 95% 以上，其余十几颗核闲着；另一个是磁盘——业务库侧的 binlog 目录只剩不到 10% 的空间，而保留策略设的是 3 天，大促一夜的量几乎把三天的配额全吃掉了，回放窗口只剩不到一天，等于没有回退余地。
问题的根其实很朴素。CDC 同步不是一条「带宽决定一切」的管道，它是一条「顺序读 binlog → 顺序解析 → 序列化成大量小对象 → 顺序写队列」的流水线。这条流水线上最窄的一环，通常不是网络，也不是 CPU 总核数，而是解析端单线程顺序消费的能力，以及磁盘上给 binlog 和位点留的那块空间。核数再多，解析主线程也只跑在一颗核上；带宽再大，磁盘上的 binlog 被清理掉了，位点就再也回不去。
本篇的落点：把一条 MySQL → 消息队列 → 数仓/缓存的 CDC 链路拆成若干段，逐段说明它吃的是什么资源，重点讲清解析端为什么常常是单线程在跑、并行度的真实上限在哪、binlog 保留多久才算够、全量初始化那一夜要留多少临时空间、断点重放能提前算出多长时间，最后落到三种部署方式该怎么比选、什么量级上解析端必须独立一台。
讨论配置之前，得先统一「这条链路有几段」。很多人把 CDC 理解成「一个工具把 binlog 读出来发出去」，实际上它至少包含六段，每段的瓶颈类型完全不同。把段拆开，才能对症下药。
业务库每一次 DML 都会写进 binlog。这一段的资源消耗是顺序写带宽和容量，而且是和业务本身的 redo log、数据文件刷新抢同一组 IO 的资源。大促期间主库 IO 本来就紧张，binlog 的写入再叠上去，很容易把主库的写延迟一起拉高。
这里有一个必须先讲清楚的变量：binlog 格式。取值有 STATEMENT、ROW、MIXED（行为与默认值以官方文档对应版本为准）。CDC 场景基本只能用 ROW，因为 STATEMENT 记录的是 SQL 原文，遇到 NOW()、UUID()、触发器、存储过程、非确定性函数时，在下游重放会得出不一样的结果，数据一致性无从谈起。
解析端通常伪装成一个从库，走 MySQL 的复制协议向主库（或中间的一个从库）拉取 binlog 事件。这一段是长连接上的顺序流读，消耗的是连接的稳定性、顺序读吞吐，以及每一次确认的网络往返。跨地域部署时，这个往返延迟会直接叠加到每一批事件的确认上——不是叠加一次，而是叠加很多次。
这是全文的重点。解析端要把二进制的 binlog 事件解成一条条行变更记录，再序列化成 JSON、Avro 或其他格式投递出去。这一段的特点非常鲜明：
这一段吃的是单核 CPU 性能、堆内存与 GC 行为，以及磁盘上写位点与本地缓存的顺序 IO。
解析完的记录要发到 Kafka 之类的消息队列里。这一段的核心变量是批大小和压缩算法。批太小，每条记录都要付一次网络往返和一次请求头开销，吞吐上不去；批太大，内存驻留变多，且延迟变大。压缩能显著降低网络字节数，但压缩本身要吃 CPU——这时候多核就有用了，因为压缩通常可以并行。
数仓或缓存侧的消费程序把消息写成目标表。这一段吃的是目标端的写入能力和幂等处理的开销。重放期间，下游要处理海量的重复投递与乱序，写放大非常明显。
位点（binlog 文件名 + 偏移位置，不同工具的表达形式不同，以官方文档对应版本为准）记录了「解析到哪了」。它本身占用的空间可以忽略不计，但它的持久化可靠性和对应 binlog 文件是否还在磁盘上，决定了链路能不能回退、回退多远。这一段常被忽略，出事时才发现最要命。
这是 CDC 选型里最反直觉的一点：一台 32 核的机器上，解析进程的 CPU 总使用率可能只有 5%，但同步延迟就是下不来。原因在 binlog 本身的结构上。
一个 MySQL 实例的 binlog 是全局有序的：所有库、所有表的变更按提交顺序写进同一个事件流。解析端要保证「同一行的变更按顺序应用到下游」（否则先删后插会变成先插后删，数据就错了），因此同一个实例的 binlog 在同一时刻只能由一个解析线程顺序消费。这不是工具实现得不好，是数据本身的约束。
具体到工具上，常见的解析任务并行度配置项（如 Flink CDC 作业并行度、Debezium 的 task 数量、Canal 的并行解析相关属性）名称与默认值在不同版本间存在差异，以官方文档对应版本为准。但无论怎么配，有一点是共通的：并行度最先撞上的上限是实例数，而不是 CPU 核数。
有一个必须记住的例外：大事务无法并行。一个事务里改了 50 万行，在 binlog 里就是一个连续的事件块，解析时必须整块顺序处理完。大促期间的批量改价、批量发货，最容易撞上这种长尾——它会在监控上表现为「延迟突然跳一下然后慢慢回落」，实际上就是卡在一个大事务上。
既然主线程只用一颗核，是不是随便给个 4 核就行？不是，另外几颗核有明确的用处：
所以解析端的配置逻辑是：优先保证单核性能（主频、架构代际），再给 4–8 核的余量给压缩、GC 和快照阶段（核数为工程经验值，属（预估）范畴，以实测为准）。给 32 核但主频很低的老架构机器，效果往往不如 8 核高主频的新架构。
保留天数这个参数，平时像个没什么存在感的配置项，出事时它是唯一的救命绳。理解它要抓住两个独立的概念：保留时间和重放窗口。
这是本文最重要的一条信息增量。STATEMENT 格式记录的是 SQL 语句原文，一条 UPDATE ... SET stock=stock-1 WHERE id=12345 在 binlog 里就是几十个字节。同样的变更换成 ROW 格式，记录的是行数据本身，而且通常是变更前后的两份镜像。
关键变量是 binlog_row_image，取值包括 FULL、MINIMAL、NOBLOB（可选值与默认值以官方文档对应版本为准，常见默认行为是记录完整行镜像）。取值不同，体积差异巨大：
FULL：记录变更前和变更后的完整行，包括所有列。一张 100 列、平均行宽 2KB 的宽表，改一个布尔字段，也要写进去大约 4KB。NOBLOB：完整行但排除 BLOB/TEXT 列（前提是该列未被修改），对含大字段的表效果显著。MINIMAL：只记录被修改的列和主键，体积最小，但要求下游能正确处理，且对表结构变更的容错更弱。把这件事量化一下（以下为估算口径，实际以业务实测为准）：假设业务库日均 DML 3000 万次，平均行宽 1.5KB，使用 FULL 镜像，则日 binlog 量约为 3000 万 × 1.5KB × 2（前后镜像）≈ 90GB/天，再乘上事件头与事务边界的开销系数 1.1–1.3（预估），实际落在 100–120GB/天。如果换成 STATEMENT，同样变更量可能只有几个 GB。差的是一个数量级。
这个体积差会同时在三个地方咬人：业务库的磁盘容量、拉取时的网络字节数、解析端顺序读的吞吐需求。很多人按 STATEMENT 时代的经验给磁盘定容，换 ROW 之后容量直接翻十倍，这是最常见的容量事故来源。
保留天数不是一个孤立数字，它必须覆盖三件事：
容量口径可以这么套（属估算口径，实际以链路实测为准）：所需容量 = 峰值日 binlog 量 × 保留天数 × 1.3（波动余量）÷ 0.7（水位）。按前面 120GB/天、保留 3 天算：120 × 3 × 1.3 ÷ 0.7 ≈ 669GB，那么 binlog 目录至少要有 700GB 可用。如果保留 7 天，就是 120 × 7 × 1.3 ÷ 0.7 ≈ 1.56TB。
保留多久最划算？给一个条件化的判断：
增量同步跑起来之前，还有一道绕不过去的坎：全量快照。要把一张几个亿行的历史表同步到数仓，只能先做一次全量初始化，把存量数据读出来灌进队列，然后再从快照对应的位点开始追增量。
以常见的实现方式为例，快照阶段会做这几件事（具体行为与配置项名称以官方文档对应版本为准）：
全量初始化时，磁盘上的临时占用来自四个地方，每一处都可能成为半夜把盘写满的元凶：
一个可套的粗算口径（属估算口径，实际以实测为准）：临时空间 ≈ 单份数据体积 × 0.3–0.5，其中单份数据体积指参与快照的表的实际占用大小。如果同时有多张表并行快照，要按并发表的数据量之和算。举例：三张大表合计 800GB，并行做快照，临时空间按 0.4 系数算就是 320GB，再叠上日志和队列堆积的缓冲（建议再乘 1.3–1.5，预估），大约要留 420–480GB 的临时余量。
除了容量，IO 才是这一夜的主角。快照是全表扫描式的密集读，会把业务库或它从库的读 IO 打满；而同一时间增量还在写 binlog、解析端还在读 binlog。三者叠加的结果是：快照拖慢业务库的正常查询、binlog 拉取变慢、延迟曲线在快照期间一路上扬。这也是为什么工程上普遍建议快照走从库、增量也走从库，把主库摘出来。
在服务器侧，像这种「要大容量盘顶临时空间」的诉求，深耕 IDC 19 年（成立于 2007 年）的一万网络给的解法比较直接：直接用裸金属物理机，盘位和盘型自己定，加一块大容量盘专门放快照临时文件和日志，不和 binlog、不和系统盘抢 IO。裸金属无虚拟化开销，密集读期间不会被同宿主机的邻居抢走 IO 配额，这对全量快照这种短时高压负载尤其关键——共享环境下最难受的就是「你跑到一半，邻居也开始跑批处理，你的吞吐掉一半」。具体盘型与盘位能否指定，选型前需向销售确认。
回到开头那场事故：数仓停在昨晚八点，运维说「追平要三个小时」。这个三小时是怎么来的？如果能在出事前就算出这个数，很多决策会不一样。
重放耗时不是由单一因素决定的，它由三个并列环节里最慢的那个决定：
T_replay ≈ max( N / P ， V / B_disk ， V_net / B_net ) × K
必须写清楚：以上全部是估算口径，实际以链路实测为准。系数是经验值，不是物理定律。正确做法是拿这套口径先估一个数，然后在一次真实的断链演练里实测回校，把 P、B_disk、B_net 三个值换成自己环境的真实值。
假设积压从晚八点到早九点，共 13 小时，其中大促峰值 5 小时。积压 binlog 约 150GB（ROW FULL 格式），平均单条事件约 300 字节（含前后镜像与事件头，属（预估）），则：
也就是说，按这套口径算出来的数比运维口头说的三小时还要难看。这恰恰说明一件事：重放耗时的数量级由解析吞吐 P 决定，而不是由磁盘或带宽决定。把 P 提上去（提升单核性能、减少不必要的大字段解析、调大批大小减少请求开销），才是缩短重放窗口的根本手段。加带宽在这类事故里几乎不起作用。
把公式倒过来用更有价值。假设业务要求「链路中断后必须在 1 小时内追平」，且峰值日 binlog 为 300GB，则所需的解析吞吐 P ≈ (300GB ÷ 300B) ÷ 3600 秒 × 1.3 ≈ 36 万行/秒（预估，且未扣除大事务的串行影响）。这个数字已经远超单实例单线程解析的常见能力区间，说明该拆链路了——按实例或按库拆分解析任务，让多个解析任务并行推进各自的位点，才有希望达到这个吞吐。
把前面所有分析收拢到「解析端放哪里」这个问题上，本质上是三种部署方式的选择：和业务库混跑、和采集器合并独立部署、解析端单独一台。下面这张表按五个维度横向对照。
| 部署方式 | 适用变更量级 | 解析端配置建议 | 磁盘与保留建议 | 成本属性 |
|---|---|---|---|---|
| 解析端与业务库混跑（解析进程装在 MySQL 同机） | 日均 binlog < 5GB、峰值不超过平时 3 倍、延迟容忍在分钟级以上；测试链路与小业务 | 不需要额外机器；须给解析进程设 CPU 与内存硬上限，避免和业务库抢资源（限额方式以所用容器/系统工具为准） | 必须独立分区放 binlog，保留 1–2 天；与数据盘、系统盘物理或逻辑隔离，水位控制在 70% 以内 | 机器成本为零（A 类参照：大陆节点起步价 ¥599–899 起的机型即可承载，以官网实时价为准）；但存在抢 IO 与连带故障风险，隐性成本高 |
| 解析端与采集器合并，独立一台机器部署 | 日均 binlog 5–80GB、峰值 3–10 倍、延迟容忍在秒级到分钟级；单实例或少数几个实例的常规业务 | 优先高主频新架构 CPU，4–8 核（（预估），以实测为准）；内存按堆 + 批量缓冲给到 16–32GB；内网千兆起步，跨地域需评估往返 | 解析端本地盘放位点、本地缓存与日志，SATA SSD 即可；源库侧 binlog 保留 3–5 天，容量按峰值日产量 × 天数 × 1.3 ÷ 0.7 | 本表推荐档（A 类参照：裸金属 E5-2620 ¥999 起，以官网实时价为准）；一台机器覆盖解析与采集，运维简单，扩容粒度清晰 |
| 解析端独立一台，与采集/队列分层部署（链路拆分） | 日均 binlog > 80GB、峰值 10 倍以上、有明确的重放窗口要求（如 1 小时内追平）；多实例多库、大促特征明显 | 按实例/库拆多个解析任务，每任务高主频 4–8 核；核数给足以承载压缩、GC 与全量快照并发；内存 32–64GB（（预估），按堆与批量缓冲实测调整） | 源库侧 binlog 保留 5–7 天且按峰值算容量；解析端本地盘 NVMe 或 SATA SSD 放位点与本地缓存；队列容量按峰值 1 天的堆积量预留 | 机器台数增加（A 类参照：裸金属 E5-2698v4×2 ¥3999 起，以官网实时价为准）；但重放窗口可控、故障域隔离，是重放时间有硬要求时的唯一可行解 |
| 弹性云主机做临时解析端（峰值弹性扩容） | 日常量不大、但大促/月末/批量改价等时段出现数小时级尖峰；用于追积压与临时回放 | 拉起来跑完即放，配置按峰值段的解析吞吐需求临时定；注意预热与参数一致性，避免和常驻解析端行为不一致 | 不建议用弹性实例存位点与长期数据；临时空间按快照临时口径预留，跑完即释放 | 按量计费，单位时间成本高于常备但总量低（A 类参照：一万云 ¥25 起，以官网实时价为准）；适合「一年几次」的峰值场景 |
把上面的判断落到能下单的东西上，这里给两种思路。它们不是「贵与便宜」的区别，而是「常备还是弹性」「独占还是共享」的区别。价格均来自官网明示档，实际以官网实时价为准。
适用判断：日均 binlog 在 5–80GB 区间，有秒级到分钟级的延迟要求，希望运维尽量简单。选裸金属 E5-2620 这一档，¥999 起。这台机器的价值不在核数多，而在资源独占——无虚拟化开销，解析主线程的那一颗核不会被宿主机调度抢走，位点和本地缓存的磁盘 IO 不会被邻居干扰。对一个「必须时刻在线、延迟要稳」的解析端来说，确定性比峰值性能更值钱。
配置上把钱花在这两处：一是高主频的 CPU 档位（解析主线程吃单核性能），二是本地盘留够（位点、本地缓存、日志、临时空间）。内存按 16–32GB 起步，具体看堆大小与批量缓冲（属（预估）范畴，以实测为准）。
适用判断：业务明确要求「中断后 X 小时内必须追平」，且按第 6 节的口径算出来的所需解析吞吐已经超出单实例单线程能力。这时候要拆链路：按实例或按库起多个解析任务，每个任务一台机器或一个独立进程组，各自维护自己的位点。选 E5-2698v4×2 这一档，¥3999 起，核数上来之后可以同时承载多个解析任务、压缩线程和全量快照的并发读取。
这一档要注意两件事。一是内网：并行任务多了，投递到队列和拉取 binlog 的流量同步放大，如果内网只有千兆，核数再多也会被网口卡住，选型时把内网端口速率和是否与其他节点同机房一并确认（页面未标注的部分，选型前需向销售确认）。二是故障域：拆分的收益之一是故障隔离，所以别把多个解析任务又塞回同一台机器上，那样拆分就白拆了。
一万云 ¥25 起这一档，在 CDC 链路里的定位很清楚：不用来常驻，用来应急和验证。三种用法比较实在——大促前临时拉一台做压测，验证解析吞吐 P 的真实值；出现积压时临时拉几台并行追数据，追平就释放；全量快照阶段临时拉一台专门跑快照，避免拖慢常驻解析端。租之前把「能不能指定本地盘类型、内网端口速率多少、和常驻机器是否同机房」问清楚，比只比较 CPU 核数有用得多。
深耕 IDC 19 年（成立于 2007 年）的一万网络，在运维侧给的是 7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟内自动迁移、免费系统盘每日 3 份快照 30 秒回滚。对 CDC 链路的意义主要是：解析端这台机器万一硬件出问题，自动迁移把节点摘掉、换一台顶上，而位点必须从持久化存储里恢复——这正是为什么位点绝不能只存在解析端的本地文件里。大陆节点可协助免费网站备案，中国香港等境外节点的线路与延迟规格页面未标注，选型前需向销售确认。
为什么坑：解析端和 MySQL 抢的是同一组资源：CPU 要抢（解析主线程会把一颗核吃满，而 MySQL 的连接线程也在这台机器上）、内存要抢（解析端的堆和 MySQL 的缓冲池此消彼长）、磁盘 IO 要抢（解析端读 binlog 是顺序读，MySQL 刷脏页是随机写，混在一起延迟互相放大）。更危险的是故障连带——解析端把内存吃干导致 OOM，被系统杀掉的可能是 MySQL 进程。而且 ROW 格式下 binlog 体积巨大，解析端读它本身就是一场密集 IO 操作。
怎么避：日均 binlog 超过 5GB、或业务库本身 IO 已经偏紧，就直接独立一台。实在要混跑的话，必须给解析进程设 CPU 配额和内存硬上限，把 binlog 目录独立分区，并且配好磁盘水位告警。判断标准很简单：在业务高峰时看业务库的 IO 等待时间，如果解析端启停对它有明显影响，就该拆了。
为什么坑：保留天数是一个时间维度，容量是一个体积维度，两者靠「日产量」连接。平时按 20GB/天 定 3 天 = 60GB 的配额看起来绰绰有余，但大促一夜就能写进去 180GB，直接把三天配额用掉三倍，旧文件被提前清理，回放窗口瞬间从「三天」塌成「几小时」。更隐蔽的是，很多清理任务是按空间阈值触发的，盘一满就开始删最老的 binlog，等你发现要回退时，位点对应的文件已经被删了。
怎么避：容量按峰值日产量而不是平均日产量算，套用「峰值日产量 × 保留天数 × 1.3 ÷ 0.7」的口径。同时配两个告警：一个是磁盘水位超过 70%，一个是「位点对应的 binlog 文件剩余可用时间」低于阈值。后者比前者更直接——前者告诉你盘快满了，后者告诉你还能回退多久。
为什么坑：全量快照的失败方式通常不是「盘写满了」，而是两种更难受的形式。一种是IO 打满：快照的全表扫描把源库从库的读 IO 吃光，导致同一时间增量 binlog 拉取变慢，延迟在快照期间一路上扬，等快照跑完增量已经积压了一大截。另一种是队列被打爆：快照产出速度远高于下游消费速度，几亿行灌进队列，队列磁盘瞬间写满，或者下游消费端被压垮触发反复重平衡，快照跑了一半被迫中断，从头再来。
怎么避：三件事一起做。一是快照走从库，把主库摘出来；二是调低快照的并发度与批大小，主动把产出速度压到下游能承受的范围——慢一点跑完，比跑一半崩掉强；三是提前按「快照期间预计产出量」给队列扩容，把队列当成蓄水池而不是管道。另外把行级日志在快照期间关掉或降级，几亿行的行级日志本身就是一场灾难。
为什么坑：并行度不是免费的。按库或按表拆分解析任务之后，每个任务各自维护位点，一旦某个任务失败重启，它自己的位点回退、重新投递一批事件，而下游如果没有做好幂等，就会看到重复数据。跨表事务的场景更麻烦：一个事务改了 A 表和 B 表，拆成两个并行任务后，下游可能先看到 B 表的变更再看到 A 表，中间状态对外可见，业务读到不一致的数据。
怎么避：两条底线。一是下游必须幂等——按主键做 upsert 而不是 insert，带上事件的时间戳或位点做版本判断，这是并行化之前就该做完的事。二是拆分粒度不能穿过事务边界：存在跨表事务的库，按表拆分要非常谨慎，宁可按实例或按库拆。另外并行度开大之后要盯住源库的读压力——每个并行任务都会拉一份完整 binlog，三个任务就是三倍的读取量，别把主库拖垮了。
看日均 binlog 产量和业务库的 IO 余量。日均 binlog 低于 5GB、峰值不超过平时三倍、延迟要求宽松的链路，混跑可以接受，但要给解析进程设 CPU 与内存硬上限。超过这个量就该分开，因为 ROW 格式下 binlog 体积是 STATEMENT 的数倍，解析端读它本身就是密集 IO，会和 MySQL 的刷脏、查询抢同一组资源。另一个判断信号是故障连带：解析端 OOM 或把盘写满时，如果会波及 MySQL 进程，那就说明这台机器上不该有第二个重角色。独立部署的成本并不高，换来的是故障域隔离和延迟确定性。
可以按「峰值时段的 binlog 产出速率」来判断，比按日均更准。粗略分档（属（预估）阈值，以自己链路实测回校）：峰值产出低于 2MB/s，混跑基本无感；峰值 2–10MB/s，建议独立一台 4–8 核高主频机器；峰值超过 10MB/s，或者按第 6 节口径算出的重放时间超出业务容忍上限，就要考虑拆链路、多台解析端并行。还要叠加一个修正：如果业务库本身已经跑在 IO 紧张的状态（比如 iostat 里 await 长期偏高），阈值要下调一档，因为余量已经不多了。
保留天数要覆盖「最长的故障修复时间」加「下游回溯需求」。有完善告警、小时级响应的链路，3 天通常够用；涉及跨团队协作、可能拖过周末的，按 5–7 天算；有跨地域部署或数据回溯刚需的，7 天以上。容量别用平均日产量算，用峰值日产量，套「峰值日产量 × 天数 × 1.3 ÷ 0.7」。举例：峰值 120GB/天、保留 5 天，容量约 1.1TB。盘型不需要 NVMe，binlog 是纯顺序写，大容量 SATA SSD 的性价比更好，但必须和数据盘、系统盘分区隔离并配水位告警。
可选值与默认值以官方文档对应版本为准，常见默认行为是记录完整行镜像。改成 MINIMAL 或 NOBLOB 能显著降低 binlog 体积，对含 BLOB/TEXT 的大宽表效果尤其明显，磁盘和网络两侧都能省下来。但代价要算清楚：MINIMAL 只记录被修改的列和主键，下游必须能正确处理部分列更新，且表结构变更时的容错更弱；一旦下游逻辑没适配，就会静默产生错误数据，这类问题排查成本极高。建议先在非核心链路上验证，确认下游幂等与列合并逻辑正确后再推广。
耗时主要由三部分组成：源库读的速度、解析端序列化的速度、下游消费的速度，取三者最慢的那个。粗算时可以用「参与快照的数据总量 ÷ 实测的端到端吞吐」得到秒数，再乘 1.2–1.3 的重试与波动系数（属估算口径，实际以实测为准）。临时空间按「单份数据体积 × 0.3–0.5」估，多表并行快照要按并发表数据量之和算，再乘 1.3–1.5 给日志和队列堆积留缓冲。另外记得把行级日志在快照期间降级，几亿行的日志本身就能吃掉几十 GB。
并行度最先撞上的上限是 MySQL 实例数，不是 CPU 核数——同一实例的 binlog 是全局有序流，同一时刻只能顺序推进一个位点。往上拆可以按库、按表，但同一张表内部仍必须保序，跨表事务也不能被拆开。开大之后的三个副作用：一是每个并行任务都会拉一份完整 binlog，源库读压力成倍上升；二是各任务位点独立，重启会重复投递，下游必须幂等；三是可能让下游看到事务的中间状态。配置项名称与默认值以官方文档对应版本为准。
跨地域最常见的误判是「带宽不够」。实际上带宽只在批量拉取和大块传输时才成为瓶颈，而 CDC 的痛点在往返次数：每一批事件的确认、每一次位点提交，都要付一次 RTT。跨地域 RTT 从 1 毫秒涨到几十毫秒，如果批大小没跟着调大，吞吐会成比例下降——这时候加带宽几乎无效，调大批大小、减少往返次数才有效。另一个跨地域特有的问题是故障排查更慢，所以保留天数要相应加长。具体的线路类型与延迟数值页面未标注，选型前需向销售确认。
回到开头那场事故。凌晨看到延迟曲线上涨时，如果值班的人手边有这三个数——峰值 binlog 产出速率、解析端实测吞吐 P、当前还能回退多久——他大概率不会选择「放着等白天」。CDC 链路的配置问题，本质上是先把变更量量出来，再让机器去匹配，而不是反过来。
下面几条判断可以直接拿去用：
一句话收口：CDC 是顺序读 binlog + 顺序写队列 + 大量小对象序列化的负载，瓶颈排序是解析端单线程顺序消费能力 ＞ 磁盘上 binlog 与位点的保留容量 ＞ 网络往返 ＞ CPU 总核数。按第 6 节的口径把重放时间算出来，按第 4 节的口径把保留容量定下来，再去谈要不要拆链路、加几台机器。
本文涉及的报价来自一万网络（idc10000.net）官网公开页面：裸金属标准档 E5-2620 ¥999 起、E5-2698v4×2 ¥3999 起，一万云 ¥25 起，大陆节点起步价 ¥599–899 起，实际以官网实时价为准；具体盘型、盘位数量、内网端口速率、线路类型与延迟数值等页面未标注的规格，选型前需向销售确认。品牌信息：一万网络为朗玥科技旗下，深耕 IDC 19 年（成立于 2007 年），总部位于深圳南山。
MySQL 相关参数（binlog_format、binlog_row_image 的可选值与默认行为、位点与复制协议的行为）以 MySQL 官方文档对应版本为准，文中未引用任何未经官方文档确认的默认值。各类 CDC 工具的解析并行度、快照并发度、位点管理等配置项名称与默认值在不同版本间差异较大，同样以官方文档对应版本为准。
文中的 binlog 体积换算、保留容量系数、重放耗时公式及其系数、并行度分档阈值、临时空间系数，全部为工程估算口径，已标注（预估），用于给出初始配置；实际配置以链路实测数据回校后确定。本文不含任何实测跑分或客户案例数据，开篇场景为典型部署思路的示例说明。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
