CQRS与事件溯源场景下跨聚合投影实现方案咨询

AI 小北

2026-7-10

CQRS与事件溯源在HR招聘服务中的推荐实现方案

针对你在HR服务中遇到的跨聚合投影及推荐功能实现疑问，逐一解答如下：

核心澄清：无需全量重建投影表

事件溯源架构下的投影并非每次聚合变更都要重建整张表，而是增量更新——仅针对事件影响的部分数据进行修改。比如候选人更新Elixir技能时，只需要更新该候选人对应的投影记录；职位新增Elixir技能需求时，也仅更新该职位的投影记录，完全不需要全量重建。

这不属于正常预期，你的核心认知遗漏是事件溯源投影的增量更新特性。事件溯源的核心价值之一就是通过事件流驱动读侧视图的增量维护，而非全量重算。全量重建只在特殊场景下才会用到（比如投影表损坏需要修复），日常业务更新都是基于事件的增量同步。

完全符合CQRS的概念设计。CQRS的读侧就是要为不同查询需求构建专用优化视图：

候选人技能投影、职位技能需求投影都是为基础查询场景设计的独立视图，职责单一，便于维护和性能优化；
即使后续引入机器学习模型，这两个投影也可以作为ML服务的数据源：要么直接从投影表提取特征，要么将投影数据同步到ML专用的特征存储中，ML生成的推荐结果还可以再构建一个独立的推荐结果投影表，供前端查询使用，完全不影响写侧的聚合逻辑。

这是CQRS+事件溯源架构中跨聚合查询的典型场景，成熟解决方案包括：

增量投影维护：通过事件监听器（Event Handler）监听写侧产生的事件，实时或准实时更新读侧投影；
分层读视图：分为基础视图（如候选人技能、职位需求）和聚合视图（如预计算的技能匹配结果），聚合视图可定时或事件触发更新；
专用读存储选型：如果数据量较大或需要复杂关联查询，可选用Elasticsearch这类支持全文检索和关联分析的存储，替代PostgreSQL的JOIN，提升查询性能；
事件驱动的推荐触发：当候选人技能或职位需求变更时，触发推荐计算任务（比如调用ML模型），将结果写入推荐投影表，避免实时JOIN的性能损耗。

写侧聚合设计：
- 定义Candidate聚合，产生CandidateSkillsUpdated、ProfileSubmitted等事件；
- 定义JobPost聚合，产生JobSkillRequirementsUpdated、JobPublished等事件；
读侧投影构建：
- 构建candidate_skills表：存储candidate_id、skills（数组类型）、updated_at；
- 构建job_skill_requirements表：存储job_id、required_skills（数组类型）、updated_at；
- 编写事件处理器，监听对应事件，仅更新受影响的投影记录（比如收到CandidateSkillsUpdated时，用新技能覆盖该候选人的skills字段）；
推荐查询实现：
- 初期用PostgreSQL的数组匹配+JOIN实现基础推荐：
```
SELECT c.candidate_id, j.job_id
FROM candidate_skills c
JOIN job_skill_requirements j ON c.skills && j.required_skills
WHERE 'elixir' = ANY(c.skills) AND 'elixir' = ANY(j.required_skills);
```
- 当数据量增大或需要更复杂推荐时，引入ML模型：
  - 将candidate_skills和job_skill_requirements的数据同步到ML特征库；
  - 定时或事件触发ML模型计算，将推荐结果写入candidate_job_recommendations投影表；
  - 业务查询直接读取candidate_job_recommendations表，提升响应速度；
容错与修复：
- 保留事件流的完整性，当投影表出现问题时，可通过重放事件流重新构建投影，无需依赖备份。

内容的提问来源于stack exchange，提问作者Artem