实时索引系统：架构和设计目标

1.1 项目背景

该项目是一套已经支持实时更新的搜索索引构建系统，目标是解决现有离线构建链路中常见的三类问题：

数据不一致：实时链路与离线链路逻辑割裂，容易出现索引结果与业务事实不一致，开发需要维护两套系统，开发难度大。

源系统压力过大：实时处理直接反查上游数据库，会带来明显的读放大和链路不稳定风险。

数据丢失/数据同步实时性不高: 现有系统手动控制并发度，为保护源数据库，当出现流量峰值时，kafka lag过高，消息发生丢失。

通过 MySQL Binlog -> CDC -> Kafka -> Flink -> Elasticsearch 的实时链路，配合 HBase Mirror 宽表镜像，实现低延迟、高一致、可恢复的实时索引构建能力。

1.2 建设目标

系统设计目标如下：

低延迟：事实数据变更后，索引可在秒级完成更新。

高一致性：通过 Flink Checkpoint、状态后端和幂等写入策略保障端到端一致性。

高吞吐：支持高并发事实流写入，并通过 ES Bulk Sink 控制写入效率。

高稳定性：通过 Mirror DB 解耦、Async I/O、超时重试、降级机制提升整体鲁棒性。

流批一体：离线任务负责初始化基线，实时任务负责持续增量更新，统一服务于同一索引模型。

1.3 核心价值

Puxian 的核心价值可以概括为三点：

实时更新：索引不是批量重建，而是由事实流持续驱动更新。

单一事实来源：HBase Mirror 作为在线构建阶段的主事实层，减少源库反查。

工程可控：通过 Watermark、Checkpoint、状态恢复、监控治理，让实时索引链路具备可运维性。

2. 总体架构

2.1 系统架构图

2.2 架构解读

这套架构由三条关键路径组成：

维度构建路径：Dim Topics -> Job A -> HBase Mirror Job A 持续消费维度变更流，并将其 Upsert 到 Merchant_Mirror_Wide 与 Item_Mirror_Wide。这条链路的目标是保证镜像宽表尽可能接近最新业务事实。

实时索引路径：Fact Topics -> Watermark -> Job B -> Freshness Guard -> Async Enrichment -> ES Job B 是实时更新的主链路，由事实流直接驱动索引更新。

离线初始化路径：Spark Batch Init -> HBase Mirror 离线任务只承担全量初始化和基线重建职责，不参与主实时更新逻辑。

2.3 设计哲学

Puxian 的设计哲学不是“所有数据都实时直查源库”，而是：

先把稳定事实沉淀到 Mirror DB

再由实时事实事件触发索引构建

在构建时通过异步增强补齐热点与富内容

通过新鲜度控制确保读取的是合理版本的镜像数据

这种方式在性能、一致性和系统可控性之间取得了平衡。