Socket.io与Google Cloud Pub Sub选型：是否适合协同编辑网站开发？

首先明确两个方案的延迟表现与适配性：

关于Google Cloud Pub/Sub的延迟表现 #

Google Cloud Pub/Sub同区域部署的端到端平均延迟在50ms以内，p95延迟约100ms，跨区域部署的平均延迟也可以控制在100ms左右，p95延迟不超过200ms。而多人实时协同编辑的可感知延迟阈值为200ms，超过这个数值用户才会明显感受到操作同步滞后，单从数值基准来看，同区域部署的Pub/Sub可以满足基础协同需求，但需要注意它的设计原生不适配协同编辑场景，落地存在几个明显问题：

• Pub/Sub的核心设计目标是高可靠、高吞吐、无限扩展，低延迟不是它的优先优化方向，流量高峰时段会出现偶发的延迟尖峰，可能突破200ms阈值，会提升操作冲突解决的复杂度
• Pub/Sub默认仅提供分区内的消息有序性，你需要额外开发逻辑保证同一份文档的所有操作消息进入同一个分区，否则会出现操作乱序，引发内容同步错误
• 小消息量场景下Pub/Sub的成本远高于自建Socket.io集群，按每输入一个字符就发送一条同步消息的逻辑计算，单用户每月的消息成本会是Socket.io的3~5倍

关于Socket.io的适配性 #

Socket.io是专门为实时双向通信场景设计的方案，同区域自建集群的端到端平均延迟可以控制在30ms以内，p99延迟基本不会超过100ms，完全匹配协同编辑的低延迟要求，原生支持消息顺序保证，不需要额外开发有序性校验逻辑，开发成本极低。它的扩展性上限确实弱于Pub/Sub，但常规场景下Socket.io集群可以轻松支撑十万级甚至百万级同时在线用户，绝大多数协作文档产品的用户规模都不会触碰到这个上限。

如果你的产品需要支持全球多区域用户协同，或是单文档十万级以上用户同时编辑的极端场景，可以考虑边缘层用Socket.io做用户接入、核心层用Pub/Sub做跨区域同步的混合架构，兼顾低延迟和扩展性。

最终选型建议 #

• 普通规模的协作文档产品，优先选择Socket.io，延迟更低、开发更简单、成本可控
• 明确有超大规模协同、跨全球区域同步需求的产品，再考虑选择Google Cloud Pub/Sub，同时需要提前做好业务侧的乱序处理、延迟容灾逻辑开发

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