千万级数据同步与 ETL 实战（六）：CDC、事件时间与真正的流式处理

mumu — Sun, 19 Jul 2026 01:00:00 +0800

系列导航：1 | 2 | 3 | 4 | 5 | 6

前五篇使用高频 Micro Batch 处理权限受限的数据源。它能做到分钟级同步和故障重放，但事件仍由调度器分批查询。真正的流式链路持续消费无界事件，数据一旦进入日志或消息通道便可推动计算，系统还要处理分区顺序、事件时间、乱序、长时间状态、Barrier 快照和下游事务。

这套架构适合秒级或亚秒级延迟、持续高变化率、窗口聚合、复杂乱序以及需要按日志位置精确恢复的场景。源端只有分页查询、文件投递或低频 API 时，部署 Flink 并不会凭空生成事件流，输入端仍受轮询边界约束。

一、流式输入需要可持续的位置

数据库 CDC 读取提交日志。MySQL 以 Binlog 文件与位置或 GTID 标识进度，PostgreSQL 通过逻辑复制槽和 LSN 暴露变化，Oracle 常使用 SCN 关联日志顺序。连接器将底层记录转换为统一事件，同时保留源端位置：

        
        
        
    
{
  "source": "orders",
  "partition": "mysql-cluster-a",
  "position": {"gtid": "synthetic:1-84321"},
  "transactionId": "tx-1057",
  "operation": "UPDATE",
  "key": {"orderId": 10086},
  "before": {"status": "PAID"},
  "after": {"status": "SHIPPED"},
  "sourceTime": "2026-07-19T10:01:03.126Z",
  "schemaId": "orders-v9"
}

日志位置承担恢复游标，事务 ID 和事务边界承担一致性语义。数据库事务修改 100 行时，连接器需要保留它们的相对顺序，并明确下游是否按整笔事务可见。将每行直接发往不同分区，吞吐会提高，却可能让下游在短时间内观察到部分事务结果。

flowchart LR DB["数据库提交日志"] --> CDC["CDC Connector"] CDC --> TX["事务边界与 Schema 解析"] TX --> MQ["分区事件日志"] MQ --> ST["有状态流计算"] ST --> SNK["事务或幂等 Sink"] ST <--> CP["Checkpoint Coordinator"] CP --> OFF["Source Position + State + Sink Commit"]

日志保留时间必须覆盖停机和恢复窗口。消费任务离线 12 小时，而源端日志只保留 6 小时，旧位置已不可用，只能重新做快照并建立新起点。复制槽也不是免费保险：消费者停滞时，PostgreSQL 可能长期保留 WAL，造成磁盘增长。监控应同时展示消费延迟和源端日志保留压力。

流处理 - tag - 沐木

千万级数据同步与 ETL 实战（六）：CDC、事件时间与真正的流式处理

一、流式输入需要可持续的位置