首页/数据/NoSQL 速查/CDC 与双写:把变更同步到派生存储
本包目录(322 条)
MongoDB99 条Elasticsearch89 条ClickHouse56 条时序与列式28 条
选型与架构50 条

CDC 与双写:把变更同步到派生存储

同步主库变更到搜索/缓存/分析库有两条主路:应用双写(实现直接,一致性靠补偿)与 CDC(消费 binlog/oplog/WAL 异步投递)。CDC 不侵入写路径且天然按变更顺序投递,代价是链路组件更多、重复投递要幂等消费。

NoSQL 速查数据更新于 2026-10-12

MongoDB change stream 消费(结构示意)

MongoDB change stream 消费(结构示意)
const cs = db.orders.watch();
while (cs.hasNext()) {
  const e = cs.next();
  // 幂等写入下游:以 documentKey._id + 版本号去重
  upsertIntoSearch(e.documentKey._id, e.fullDocument);
  saveResumeToken(e._id);   // 断点续传,进程重启从 token 继续
}

// 只订阅关心的变更
// db.orders.watch([{ $match: { operationType: { $in: ["insert", "update", "replace"] } } }])
双写写主库成功后写派生存储;失败进补偿队列,靠定时对账兜底
CDCDebezium 等工具把 MySQL binlog / PostgreSQL 逻辑复制 / MongoDB change stream 转成 Kafka 事件
消费要求至少一次投递:按主键做幂等 upsert,删除事件同样要传递
选择逻辑:无法改动写代码或变更量大时用 CDC;链路要极简、延迟要求高时双写加对账更直接。两者都建议保留全量重建能力以修复历史漂移。

易错点

  • 双写不能假设两边同时成功,必须有补偿或对账,否则搜索库与主库会长期不一致
  • CDC 消费者不做幂等时,重放与重复投递会造成重复计数或数据放大

数据来源与参考

  • MongoDB Manual: Change streams
  • Debezium Documentation: Connectors
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌