基于Cloud Firestore的在线状态通知系统Google Cloud架构设计咨询

你不需要修改现有数据库结构，也不需要复制冗余的状态数据到观察者节点，可通过以下逻辑实现：

• 保留现有Watchers/{用户ID}/{客户端ID}下的Presence_reference列表，可将列表内的被观察对象ID替换为Firestore原生的Reference类型（值为/Users/{被观察者ID}），服务端可直接通过引用批量查询对应状态，无需手动拼接路径，也不需要存储冗余的状态副本
• 你的IoT客户端仅支持Curl调用，无需配置多个Firestore资源监控路径，换用单节点聚合通知方案：为每个客户端分配唯一的通知队列节点Notifications/{客户端ID}，客户端仅需要监听/拉取这一个节点的内容即可获取所有关注对象的变更通知
• 所有状态变更的匹配和分发逻辑全部在服务端完成，客户端不需要维护任何被观察者的路径信息，仅需要在首次上线时上报自身需要关注的对象列表更新到Presence_reference即可

完整的高效实现流程如下：

2.1 配置Firestore触发器 #

给Users/{userId}文档配置onUpdate触发器，添加触发过滤条件：仅当文档的presence或Time字段发生变更时才触发Cloud Functions运行，过滤其他无关字段变更的无效触发，降低云资源消耗。

2.2 服务端变更分发逻辑 #

触发器触发后按以下步骤执行：

• 读取变更后的被观察者最新状态（状态值、更新时间），以及该被观察者Users/{userId}下的Watchers列表
• 批量查询所有观察者对应的Watchers/{watcherId}下绑定的所有客户端ID，校验每个客户端的Presence_reference是否包含本次变更的被观察者，过滤不需要接收通知的客户端
• 给每个符合条件的客户端的Notifications/{客户端ID}节点写入一条变更事件，事件仅包含被观察者ID、最新状态、更新时间三个核心字段，数据量极小，不存在冗余存储问题

2.3 客户端对接方案 #

针对仅支持Curl的IoT客户端，可按需选择两种对接模式：

• 轮询模式：客户端按业务需要的实时性要求，固定间隔用Curl调用Firestore REST API拉取自身通知队列的最新未读事件，拉取后标记事件为已读即可，示例Curl请求格式为：
  curl "https://firestore.googleapis.com/v1/projects/{你的项目ID}/databases/(default)/documents/Notifications/{客户端ID}?pageSize=10&orderBy=createTime%20desc"
• 回调模式：如果IoT客户端有公网可访问的HTTP回调地址，Cloud Functions生成事件时直接向回调地址POST通知内容，客户端无需主动发起请求，通知延迟更低

2.4 性能优化建议 #

• 用Cloud Memorystore缓存观察者与绑定客户端的对应关系，不需要每次触发都查询Firestore，降低读写成本
• 给Notifications集合的文档配置TTL自动删除规则，定期清理7天以上的历史通知，避免无效存储占用
• 对短时间内同一被观察者的多次状态变更做合并处理，仅向客户端推送最新状态，减少客户端处理压力

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