4. 同步方案总体架构：事件驱动架构（EDA）与变更数据捕获（CDC）模式介绍
在领域建模驱动搜索索引与业务数据库数据同步方案中，事件驱动架构（EDA）与变更数据捕获（CDC）是两大核心支撑模式。EDA 提供了松耦合、异步、可扩展的通信范式；CDC 则解决了如何可靠、低延迟地捕获业务数据库中的增量变更。两者结合，构成了现代数据同步基础设施的基石。
4.1 事件驱动架构（EDA）核心概念
EDA 是一种基于事件进行通信的软件架构风格。在数据同步场景中，业务数据库的每一次数据变更（如订单创建、用户信息更新）都被视为一个领域事件，通过事件总线（如 Apache Kafka、RabbitMQ）发布，下游的搜索索引构建器、缓存更新器等消费者异步订阅并处理。
| 特性 | 说明 | 在同步方案中的价值 |
|---|---|---|
| 松耦合 | 事件生产者与消费者不直接依赖，只依赖事件契约 | 搜索索引变更不影响业务数据库写入性能 |
| 异步非阻塞 | 生产者发布事件后立即返回，消费者异步处理 | 业务请求无需等待索引更新完成，降低延迟 |
| 可扩展性 | 消费者可独立水平扩展，处理能力随事件量增长 | 支持搜索索引从单分片到多分片的平滑扩展 |
| 事件持久化 | 事件在消息中间件中持久化存储，支持回溯消费 | 索引重建时可重放历史事件，无需全量扫描数据库 |
实践建议：在领域驱动设计中，事件应使用业务语义命名（如
OrderPlaced、CustomerAddressChanged），而非技术实现细节（如 DatabaseRowUpdated）。这有助于保持事件契约的稳定性和可理解性。
4.2 变更数据捕获（CDC）模式详解
CDC 是一种从数据库事务日志（如 MySQL binlog、PostgreSQL WAL、MongoDB oplog）中实时捕获数据变更的技术模式。它避免了业务代码中显式发送事件带来的侵入性和一致性问题，是实现可靠事件溯源的关键手段。
4.2.1 CDC 工作原理
- 日志读取器：连接数据库，持续读取事务日志中的变更记录。
- 变更解析器：将日志记录解析为结构化变更事件（INSERT、UPDATE、DELETE），包含前镜像（旧值）和后镜像（新值）。
- 事件发布器：将解析后的变更事件写入消息中间件（如 Kafka Topic），供下游消费者使用。
关键指标：CDC 的端到端延迟通常在毫秒级（100ms-1s），远优于基于定时任务的批量同步方案（分钟级甚至小时级）。在搜索索引同步场景中，CDC 能保证业务数据变更在秒级内反映到搜索结果中。
4.2.2 CDC 实现方式对比
| 实现方式 | 代表工具 | 优点 | 缺点 |
|---|---|---|---|
| 基于日志解析 | Debezium、Canal、Maxwell | 无侵入、低延迟、支持全量+增量 | 需数据库开启 binlog/WAL，运维复杂度较高 |
| 基于触发器 | 自定义触发器+变更表 | 实现简单，不依赖日志格式 | 对业务表有性能影响，维护成本高 |
| 基于时间戳轮询 | 自定义轮询脚本 | 技术门槛低，兼容所有数据库 | 延迟高、无法捕获删除、存在数据不一致窗口 |
注意：基于日志解析的 CDC 工具（如 Debezium）在捕获 DELETE 操作时，通常只提供主键值，不包含完整的前镜像。在搜索索引同步中，需要根据主键从搜索服务中删除对应文档，或使用软删除标记。
4.3 EDA + CDC 融合架构
将 EDA 与 CDC 结合，形成事件驱动的数据同步管道。CDC 作为事件源，将数据库变更转化为领域事件；EDA 提供事件路由、缓冲和分发能力；搜索索引构建器作为事件消费者，将变更应用到搜索引擎。
4.4 关键设计决策
- 事件顺序保证：对于同一主键的变更，必须保证消费顺序与数据库写入顺序一致。Kafka 通过分区键（如主键 hash）将同一实体的所有事件路由到同一分区，实现分区内有序。
- 幂等消费：搜索索引构建器应实现幂等处理，避免因重复消费导致索引数据错误。例如，使用事件 ID 去重，或采用最终一致性的覆盖写入。
- 全量+增量协同：首次同步或索引重建时，先进行全量快照，再切换到 CDC 增量同步。Debezium 的 Snapshot + Streaming 模式原生支持此流程。
- 死信队列：对于无法处理的事件（如格式错误、关联数据缺失），应路由到死信队列进行人工或自动重试，避免阻塞整个管道。
领域驱动设计视角：在 DDD 中，CDC 捕获的原始数据库变更（如
UPDATE user SET name='张三'）应被转换为领域事件（如 CustomerNameChanged）。这层转换通常在 CDC 连接器与事件总线之间，或由轻量级的事件转换器完成。转换后的领域事件携带业务含义，便于搜索索引构建器理解并构建合适的索引结构。
4.5 模式选择矩阵
| 场景 | 推荐模式 | 理由 |
|---|---|---|
| 实时性要求高（秒级） | CDC + Kafka | 日志解析延迟低，Kafka 提供高吞吐 |
| 业务代码需参与事件生成 | EDA（应用层发布事件） | 可携带丰富业务上下文，但需处理事务性发件 |
| 数据库无法开启 binlog | 定时轮询 + 增量标记 | 兼容性最好，但延迟高、无法捕获删除 |
| 需要索引重建能力 | CDC + 事件持久化 | 可重放历史事件，避免全量扫描 |
| 多数据源聚合索引 | EDA + 事件聚合器 | 各数据源独立发布事件，聚合器做关联和转换 |