Firestore与Pub/Sub的区别及外卖实时场景下如何选型

一、核心差异 #

• 产品定位不同：Pub/Sub是异步消息队列服务，核心能力是解耦服务、可靠传递事件消息，本身不做长期数据持久化，仅暂存消息直到被消费或过期；Firestore是NoSQL文档型数据库，核心能力是结构化数据持久化存储，实时推送是附加能力，所有变更数据会永久留存（除非手动删除）。
• 数据/消息模型不同：Pub/Sub的传输单元是无结构的自定义消息体，支持设置消息过期时间，消费后默认删除；Firestore的存储单元是集合/文档，有结构化字段规则，全量变更历史可追溯。
• 实时推送逻辑不同：Pub/Sub是生产者发送消息到主题后，主动推送给订阅端/订阅端拉取消息，仅做事件透传不关联业务状态；Firestore的实时监听是客户端订阅特定文档/集合，只要存储的内容发生变更就主动推送给所有订阅端，推送内容包含完整的变更后数据。
• 消费机制不同：Pub/Sub支持至少一次交付，原生提供消费确认、死信队列、重试策略，适合后端服务间的事件流转；Firestore的实时推送无原生消费确认机制，更适合端侧（APP/网页）直接订阅数据状态。

二、各自适用场景 #

Pub/Sub适用场景 #

• 后端微服务之间的异步解耦，比如一个事件需要触发多个独立下游服务执行逻辑
• 海量高并发事件的缓冲削峰，比如大促期间的订单上报、行为日志收集
• 跨系统的事件广播，不需要持久化存储事件内容，仅需要通知下游执行对应操作

Firestore适用场景 #

• 端侧需要直接读写的结构化业务数据存储，比如用户信息、订单信息、骑手位置数据
• 多端需要同步同一份业务状态的场景，比如订单状态同步给消费者、骑手、商家三个端
• 轻量实时协作场景，不需要额外搭建后端服务即可实现端到端状态同步

三、外卖服务实时状态推送场景选型建议 #

你需要实现的餐品状态（待取、配送中、已送达等）多端同步场景，优先选择Firestore，原因如下：

• 订单状态本身是需要持久化存储的核心业务数据，你仅需将订单数据存在Firestore中，开启对应文档的实时监听，消费者端、骑手端、商家端都可以直接订阅，不需要额外开发消息推送的中转逻辑，研发成本更低。
• Firestore的实时推送天然支持多端同步，只要订单数据发生变更，所有订阅的端都会立刻收到通知，不需要自行维护订阅关系和消息分发逻辑。
• 你可以搭配Firebase云函数监听订单文档变更，触发额外业务逻辑，比如订单变为待取餐状态时给骑手发送短信通知；如果这类变更需要串联多个后端服务，可在云函数中将变更事件推到Pub/Sub，供其他后端服务消费。

如果你的场景满足以下特征，可以补充搭配Pub/Sub使用：

订单变更后需要触发派单计算、财务结算、用户推送、骑手推送等多个独立的后端服务，这类服务不需要直接给端侧返回结果，属于异步执行逻辑，用Pub/Sub做事件分发可以避免服务耦合。

四、最终选型参考 #

• 仅端侧状态同步需求：只用Firestore即可，直接监听订单文档变更实现实时推送
• 同时存在后端服务间异步事件流转需求：Firestore存储业务数据+实现端侧同步，搭配Pub/Sub做后端服务的事件解耦，二者配合使用效果最优

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