基于事件的实时状态更新实现方案咨询及合理性验证

背景与架构概述 #

近期接触了一个竞价服务的系统设计，核心用例之一是向客户端实时推送特定商品（或一组商品）的竞价更新。该设计仅给出抽象架构，未详述组件实现细节，因此我从技术层面梳理其落地方式：

• 竞价信息由bids service后端服务异步发送至事件队列（未指定具体队列服务）；
• real-time service后端服务消费该事件队列，并通过WebSocket连接向客户端推送实时更新。

多实例部署下的队列选型分析 #

假设real-time service部署了instance1和instance2两个实例，user1连接到instance1，user2连接到instance2，二者均订阅了item5的更新，针对不同队列服务的表现分析如下：

• AWS SQS：所有实例监听队列，但每个事件仅会被其中一个实例消费并确认（ACK）后移除，导致其他实例无法获取该事件，无法向其连接的用户推送更新（例如item5事件被instance2消费推送给user2，user1则无法收到）；
• AWS Kinesis：可解决SQS的推送问题，因为Kinesis会在指定保留窗口内持久化数据，所有实例均可消费事件并推送给对应用户，但缺点是每个实例需处理所有入队事件，即便其连接用户无需该事件（例如实例用户均订阅item5，仍需处理item3的事件并判断后丢弃）；
• Kafka/RabbitMQ（PubSub模式）：以itemID作为主题名，实例可仅订阅所需主题，忽略无关事件，减少无效处理。消费到事件后，实例根据内存中维护的订阅映射（itemId到客户端ID列表的映射），推送给对应客户端。

我假设每个服务实例维护的内存订阅映射示例如下：

item1 -> {client1}  
item2 -> {client1, client2}  
item3 -> {client2}

待解答的问题 #

1. 上述队列选型的分析是否合理？这是否是实时流场景下的常规实现方式？
2. 该方案是否可扩展至即时通讯场景（例如客户端订阅用户或群组，real-time service作为聊天服务）？
3. 在Web后端应用中使用队列/PubSub订阅是否属于最佳实践？

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