3. 同步方案总览：全量同步 vs 增量同步、实时同步 vs 准实时同步、推模式 vs 拉模式
在 Kubernetes 集群中设计搜索索引与业务数据库的数据同步方案时，首先需要从三个核心维度进行方案选型：同步范围（全量 vs 增量）、同步时效（实时 vs 准实时）、同步驱动方式（推模式 vs 拉模式）。这三个维度相互组合，决定了同步系统的吞吐能力、数据一致性、资源消耗和运维复杂度。
3.1 全量同步 vs 增量同步
全量同步与增量同步解决的是“同步哪些数据”的问题。全量同步将业务数据库中的全部数据重新加载到搜索索引中；增量同步则只捕获并同步自上次同步以来发生变化的数据。
| 对比维度 | 全量同步 | 增量同步 |
|---|---|---|
| 数据范围 | 整个表或整个索引的全部记录 | 仅变更记录（INSERT / UPDATE / DELETE） |
| 执行频率 | 低（每日/每周/按需触发） | 高（秒级/分钟级持续执行） |
| 资源消耗 | 高（大量 CPU、内存、网络 IO、数据库压力） | 低（仅处理变更数据） |
| 数据一致性 | 强一致性（重建索引后完全对齐） | 最终一致性（可能存在短暂延迟或遗漏） |
| 适用场景 | 初始建索引、数据修复、索引重建、大规模数据迁移 | 日常持续同步、实时搜索、变更追踪 |
| K8s 部署特点 | 通常以 Job 或 CronJob 形式运行，可配置资源配额和超时 | 以 Deployment + Sidecar 或 DaemonSet 形式常驻运行 |
实践建议：在 Kubernetes 集群中，全量同步与增量同步通常组合使用。全量同步作为“基线”定期执行（例如每天凌晨通过 CronJob 触发），增量同步作为“持续补丁”实时捕获变更。这种“基线 + 增量”模式兼顾了数据一致性与资源效率。
3.2 实时同步 vs 准实时同步
实时同步与准实时同步解决的是“同步多快”的问题。实时同步要求数据变更后毫秒级或秒级内反映到搜索索引；准实时同步则允许分钟级甚至小时级的延迟。
| 对比维度 | 实时同步 | 准实时同步 |
|---|---|---|
| 延迟目标 | 毫秒 ~ 秒级（通常 < 5s） | 分钟 ~ 小时级（通常 1min ~ 1h） |
| 技术栈 | CDC（Change Data Capture）+ 消息队列（Kafka / Pulsar）+ 流处理 | 定时批处理（CronJob）+ 批量 API 调用 |
| K8s 组件 | Deployment + Sidecar（Debezium / Canal）+ StatefulSet（Kafka） | CronJob + Job + ConfigMap（调度配置） |
| 数据一致性 | 最终一致性，可能出现短暂乱序 | 强一致性（批处理窗口内对齐） |
| 资源开销 | 高（常驻进程、消息队列持久化、流计算） | 低（周期性启动、释放资源） |
| 适用场景 | 电商库存、社交动态、即时搜索、竞价排名 | 内容管理、商品信息、知识库、非关键搜索 |
选型要点：在 Kubernetes 集群中，实时同步通常依赖 Debezium（部署为 Deployment）捕获数据库 Binlog，通过 Kafka（部署为 StatefulSet）缓冲事件，再由 Kafka Connect 或自定义消费者写入 Elasticsearch。准实时同步则直接使用 CronJob 定时执行 SQL 查询 + 批量写入索引，架构更简单。
3.3 推模式 vs 拉模式
推模式与拉模式解决的是“谁发起同步”的问题。推模式由数据源（业务数据库）主动将变更事件发送给搜索索引；拉模式由搜索索引端主动轮询数据源获取变更。
| 对比维度 | 推模式（Push） | 拉模式（Pull） |
|---|---|---|
| 数据流向 | 数据源 → 搜索索引（事件驱动） | 搜索索引 ← 数据源（轮询驱动） |
| 实现方式 | CDC + 消息队列 + 消费者 | 定时 SQL 查询 + 对比时间戳/版本号 |
| 实时性 | 高（事件产生即推送） | 低（取决于轮询间隔） |
| 对数据源压力 | 低（仅捕获变更事件） | 高（频繁查询数据库） |
| 数据丢失风险 | 低（消息队列持久化 + ACK 机制） | 中（轮询间隔内变更可能遗漏） |
| K8s 运维复杂度 | 高（需管理 CDC 组件、消息队列、消费者组） | 低（仅需 CronJob + 简单代码） |
| 典型组件 | Debezium + Kafka + Kafka Connect | CronJob + 自定义同步器 + 数据库驱动 |
避坑指南：推模式虽然实时性好，但在 Kubernetes 集群中需要额外管理消息队列的持久化存储（PVC）、消费者组的水平伸缩（HPA）、以及 CDC 组件的高可用（多副本 + Leader 选举）。拉模式虽然简单，但高频率轮询可能对业务数据库造成不必要的压力，建议配合 last_updated 时间戳索引 或 版本号字段 优化查询效率。
3.4 三维度组合选型矩阵
实际项目中，上述三个维度并非独立选择，而是需要组合决策。以下矩阵展示了常见的组合模式及其适用场景：
| 组合编号 | 同步范围 | 同步时效 | 驱动方式 | 典型场景 | K8s 部署方案 |
|---|---|---|---|---|---|
| 组合 A | 全量 | 准实时 | 拉模式 | 每日索引重建、数据修复 | CronJob + Job |
| 组合 B | 增量 | 实时 | 推模式 | 电商库存、社交动态搜索 | Debezium + Kafka + Deployment |
| 组合 C | 增量 | 准实时 | 拉模式 | 内容管理、知识库搜索 | CronJob + 时间戳轮询 |
| 组合 D | 全量 + 增量 | 实时 + 准实时 | 推 + 拉混合 | 大型电商平台、金融搜索 | CronJob（全量）+ CDC（增量） |
推荐实践：在 Kubernetes 集群中，组合 D（全量 + 增量混合模式） 是最稳健的选择。全量同步通过 CronJob 定期执行（例如每天凌晨 2 点），确保数据基线正确；增量同步通过 CDC + 消息队列实现实时推送，保证搜索结果的时效性。这种模式兼顾了数据一致性与搜索体验，也是本课程后续章节重点展开的方案。