构建应用内通知服务的正确方法？

Question

背景

我有一个单体 Node.js + PostgreSQL 应用程序，除此之外，它还需要向最终用户提供实时应用程序内通知。

目前是通过以下方式实现的：

• 有一个数据库表notifications ，其中包含state （待处理/已发送）、 userid （通知接收者的 ID）、 isRead （用户是否阅读了通知）、 type和body - 通知数据。

• 一旦特定资源被创建或特定事件发生，不同数量的用户应该会收到应用内通知。 创建通知后，它会持久保存到数据库并使用 WebSockets 发送给用户。 通知也可以由 cron 作业创建。

• 当用户收到 N 个相同类型的通知时，它们会合并为一个通知。 这是通过数据库触发器通过删除重复通知并插入新通知来完成的。

• 通常它工作正常。 但是，当接收者的数量超过数千时，应用程序会延迟或其他请求被阻止，或者并非所有通知都通过 WebSockets 发送。

通知示例

• 文章发表

• 用户获得积分

• 用户多次登录但未执行某些操作

• 一个用户向另一个用户发送好友请求

• 一位用户向另一位用户发送了一条消息

• 如果用户收到 3+ Article published通知，他们将折叠到N articles published通知中（如果收到新的相同通知， N会更新）。

---

我目前拥有的似乎效果不佳。 例如，对于Article created事件，处理创建的 api 端点还处理通知发送（这可能不是一个好方法 - 它创建 ~5-6k 通知并通过 websockets 将它们发送给用户）。

---

问题

如何正确设计这样的功能？

我应该继续使用 node.js + db 方法还是添加排队服务？ Redis 发布/订阅？ RabbitMQ？

我们部署到k8s集群，所以再添加一个服务是没有问题的。 更重要的问题 - 我的情况真的需要吗？

我希望阅读有关此主题的一些一般性建议或资源。

我已经阅读了几篇关于消息传递/队列/通知系统设计的文章，但仍然不太明白这是否适合我的情况。

队列应该存储通知还是应该在数据库中？ 实时通知成千上万用户的正确方法是什么（websockets？SSE？）？

此外，我对队列和消息代理了解得越多，就越觉得自己把事情复杂化了，变得更加困惑。

Answer 1

考虑使用Temporal 开源项目。 它将允许将每个用户生命周期建模为一个单独的程序。 Temporal 使代码完全容错并在进程重新启动时保留其完整的 state（包括局部变量和阻塞等待调用）。