使用AWS WebSocket向百万级群组成员推送消息的最优方案咨询

当前方案的风险说明 #

你当前的架构存在非常高的Lambda提前终止风险，核心原因如下：

• Lambda最大运行时长仅为15分钟，百万级连接的全量拉取+逐个推送的链路耗时极容易触达时长上限：仅全量Scan百万条DynamoDB连接记录就需要数分钟到十余分钟不等，若遇到DynamoDB读限流、API Gateway推送接口限流，整个流程耗时会进一步拉长，远超过Lambda的运行时间限制。
• 单Lambda处理全量推送没有容错机制，只要运行过程中出现网络波动、依赖服务限流、代码异常等问题，整个推送任务就会中断，未推送的消息会直接丢失，没有重试补偿机制。

可扩展的群聊实现方案推荐 #

方案1：基于消息队列扇出的轻量化改造（对现有架构改动最小） #

• 入口Lambda仅做两步核心操作：将群消息持久化到DynamoDB，将推送任务发送到SQS/SNS主题，直接结束运行，不处理实际推送逻辑。
• 提前对连接表做分片设计：给所有连接记录加上分片前缀（比如取连接ID的前2位作为分片键，共256个分片），给每个分片分配独立的推送子Lambda，每个子Lambda仅拉取对应分片下的目标群在线连接并完成推送，单Lambda仅需要处理数千到数万条连接，完全不会触达运行时长上限。
• 新增死信队列承接推送失败的任务，对于API Gateway返回410状态码的失效连接，直接从连接表中删除，避免无效推送浪费资源。

方案2：基于AppSync的托管实时订阅方案（长期迭代更优） #

直接替换现有WebSocket链路为AWS AppSync服务，不需要自行维护连接管理、消息推送逻辑：

• 客户端建立连接后直接订阅对应群组的实时更新事件，AppSync会自动维护所有订阅连接。
• 有新消息发送时只需触发AppSync的Mutation操作，AppSync会自动将消息推送给所有订阅了对应群组的客户端，不需要自行实现拉取连接、批量推送的逻辑，天然支持百万级连接的并发推送。
• 该方案可以省掉连接表维护、推送逻辑开发的工作量，可用性和扩展性都远高于自研方案。

通用优化建议 #

不管选用哪种方案，都建议调整连接表的存储结构，新增GSI以群组ID为索引键，需要推送时直接查询对应群组的在线连接即可，不需要全表扫描，大幅降低数据拉取的耗时和DynamoDB的读消耗。

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