【发布时间】：2021-04-28 16:53:30
【问题描述】：
我只是为了练习而实现 WebSockets，但遇到了架构问题。
拥有 WebSockets 很好，但我想不出一个简单的可扩展场景。
可能的场景：
浏览器用户在前端开始一些计算困难的任务。它通过 API 服务器，API 将任务放入队列，其他一些带有 celery 的 GPU 服务器拉取任务并开始处理它。在途中的某个地方，可能有一个保存状态的数据库。所以我会说 API 和 celery 服务器在数据库中写入有关正在发生的事情的特定任务信息。
现在是重要的部分。有一个 WebSocket 服务器连接到浏览器客户端。如果 WebSockets 是单工的，并且只向浏览器客户端发送有关任务进度的消息（状态、进度条百分比等），那就太好了。 WebSocket 很聪明，不需要定期轮询，但可以根据触发的事件（由 API 和 celery）向浏览器客户端发送数据。显然，WebSocket 服务器需要监听这个任务状态（Redis 什么的，当然不是和 WebSocket 服务器在同一个地方的东西）。这意味着在 WebSocket 循环中必须有该状态的侦听器。但这最终会返回到 WebSocket 服务器轮询这个 redis 或其他东西以查看任务的状态 -> 如果有很多用户，这肯定是连接杀手，因为会有很多 WebSocket 连接轮询同一个数据库。
那么问题来了：如何在架构上解决这个问题（没有轮询，WebSockets 只在某些 DB 中某个值的状态变化时才发送消息）？
【问题讨论】：
标签： database events websocket triggers architecture