集群环境下结合Kafka使用Cassandra，如何跟踪写入成功并通知前端？

针对你描述的场景（单作业约100个结果、每日1000个作业，依赖Kafka+Cassandra的分布式链路），以下是几个可扩展、易维护的方案：

1. 作业状态追踪器（基于Cassandra） #

这是最直接且易落地的方案，需要在Cassandra中新增一个作业状态表，结构大概如下：

CREATE TABLE job_status (
    job_id UUID PRIMARY KEY,
    total_results INT,
    completed_results COUNTER,
    failed_results COUNTER,
    status TEXT // pending/running/completed/failed
);

• 流程：
  • 作业初始化时，写入一条job_status记录，total_results设为该作业的结果总数（比如100），status设为running。
  • 每个Cassandra写入器成功写入一个结果后，原子性递增completed_results（用Cassandra的计数器类型，天然支持分布式原子操作）；如果写入失败，递增failed_results。
  • 当completed_results等于total_results时，用LWT（轻量级事务）将status更新为completed；如果failed_results>0，可标记为failed。
  • 前端通过轮询（低频率，比如5秒一次）或WebSocket推送（实时性要求高时）获取job_status，直到状态变为completed再显示完成。
• 优势：
  • 复用现有Cassandra存储，无需引入新组件，扩展成本低；每日10万次左右的计数器更新，Cassandra完全能承载。
  • 状态与结果数据同库，天然保证最终一致性，避免跨组件的数据不一致问题。
• 注意点：
  • 作业初始化时必须明确total_results，如果结果数量动态变化，可先设为预估数，后续再更新。

2. Kafka流聚合方案（无额外数据库条目） #

如果不想新增数据库表，可以利用Kafka的流处理能力（比如Kafka Streams）实现结果计数与完成通知：

• 流程：
  • 所有结果消息需携带job_id和唯一的result_id（避免重复计数），同时作业启动时，向Kafka发送一条job_init消息，包含job_id和total_results。
  • 用Kafka Streams创建一个聚合流：按job_id分组，维护每个作业的已接收结果集合（去重）和已完成计数。
  • 当某个作业的已完成计数等于total_results时，向专门的job_completion主题发送一条完成事件。
  • 前端服务订阅job_completion主题，将完成状态缓存（比如用Redis），前端直接查询缓存或通过推送获取状态。
• 优势：
  • 无需额外数据库存储，完全基于Kafka生态，适合已经在使用Kafka Streams的场景。
  • 天然支持分布式扩展，Kafka Streams可横向扩容实例，处理更多作业。
• 注意点：
  • 要处理Kafka的至少一次投递特性，必须用result_id去重，避免重复计数导致提前触发完成事件。
  • 需确保job_init消息先于结果消息被流处理应用消费，否则会出现计数异常。

3. Cassandra物化视图聚合（轻量无额外表） #

如果不想新增独立的状态表，也可以用Cassandra的物化视图实现结果计数：

• 流程：
  • 假设你的结果表是job_results (job_id UUID, result_id UUID, data TEXT, PRIMARY KEY(job_id, result_id))，创建物化视图：

    CREATE MATERIALIZED VIEW job_result_count AS
    SELECT job_id, COUNT(result_id) AS result_count
    FROM job_results
    GROUP BY job_id;
    

  • 前端服务定期查询该物化视图，当某个job_id的result_count等于总结果数时，标记作业完成。
• 优势：
  • 无需额外写入逻辑，完全依赖Cassandra的物化视图自动聚合。
• 缺点：
  • 物化视图的更新是异步的，存在几秒到几十秒的延迟，实时性差。
  • 无法区分“写入中”和“写入失败”的情况，如果某个结果写入失败，计数会永远达不到总数，需要额外的失败检测逻辑。

方案选择建议 #

• 优先选作业状态追踪器：逻辑简单、一致性好，适合大多数场景，额外存储开销可以忽略（每日1000条状态记录，每条几字节）。
• 如果已经重度依赖Kafka生态，选Kafka流聚合方案：避免数据库额外操作，适合流式优先的架构。
• 物化视图方案只适合对实时性要求低、不需要失败检测的场景。

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