GKE多Pod部署Pub/Sub订阅：重复处理风险与架构选型咨询

• Pub/Sub的消息分发机制默认是单实例独占：每个消息只会被分配给一个Pod，直到该Pod调用ack()确认处理完成，或者超过订阅配置的确认超时时间才会重新分发。正常情况下，不会出现多个Pod同时处理同一文件的情况。
• 重复风险仅出现在异常场景：比如Pod处理过程中崩溃、ack()调用失败，或者处理耗时超过确认超时，这时候消息会被重新发给其他Pod，可能导致重复写入BigQuery。
• 规避重复的实用方案：
  • 务必在BigQuery写入完全成功后再调用ack()，不要提前确认；
  • 给BigQuery表加幂等约束（比如主键、唯一键），即使收到重复消息，也不会生成重复记录；
  • 根据GB级文件的实际处理耗时，调整Pub/Sub订阅的确认超时时间，避免无故重发。

现有if-else架构的成本与效率优势 #

• 成本更低：只需要维护一套Deployment、HPA和代码库，减少K8s运维、镜像构建的重复开销；
• 资源利用率更高：HPA扩容的Pod可以处理所有ID类型的消息，避免某类ID的应用闲置、另一类ID的应用资源不足的浪费；
• 迭代更灵活：新增ID类型时，只需修改代码分支，无需重新部署多个应用。

独立过滤订阅架构的适用场景 #

• 当不同ID的处理逻辑差异极大（比如不同数据格式、不同写入规则），拆分后代码更易维护；
• 业务要求不同ID的处理必须完全隔离（比如某类ID的处理失败不能影响其他类型）；
• 某类ID的流量占比极高，独立部署可以针对性配置资源，避免抢占其他类型的处理资源。

综合建议 #

目前只有6类ID，且核心逻辑都是路径解析+BigQuery写入，优先保留现有if-else架构更划算。后续如果出现处理逻辑分化、流量极端不均或强隔离需求，再考虑拆分独立应用。

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