Twitter 喜欢推文订阅 + sse 与订阅的推文/缩放

问：

我有一个基于fastify（https://fastify.dev）+ sse（https://www.npmjs.com/package/fastify-sse-v2）的实时服务。

每个客户端都与实时服务（事件流）建立连接。

实时服务监听 Redis Pub/Sub 并将信息推送到客户端。

现在，我的目标是为项目而不是推文完成类似 Twitter 的实现。

如果用户滚动浏览时间线，则可见的推文将被订阅，不可见的推文将在单独的请求中取消订阅。现在，用户只能获得订阅推文的实时信息。

我现在想为我的用例实现相同的方法，因为这似乎很合适。

用户不是在我的应用程序中发布推文，而是使用项目。根据选择，我只想通过 SSE 将实时信息推送给用户，这是相关的。

所以基本上，我想订阅/取消订阅项目，如果某个特定项目收到发布/订阅消息，用户应该只收到订阅项目的消息。

我不是在要求具体的实施;我对基础设施/设计更感兴趣。

如果用户连接到实时服务，我会将所选项目保存在内存中。如果用户取消订阅项目，我会将其从订阅项目列表中删除。如果收到 redis 消息，我会检查传入的消息是否属于订阅的项目。如果是这种情况，我会将消息推送给用户。

我现在担心的是，如果实时服务扩大规模会发生什么？该应用程序现在已连接到实时服务 A，但我订阅/取消订阅项目的请求可能会转到实时服务 B。由于内存不是共享的，因此此解决方案在缩放时不起作用。

我考虑过使用 redis / dragonflydb 并将此信息集中保存。但我不确定钥匙。我想设置一个 TTL 来保持 redis 清晰，但我不确定用户在页面上停留了多长时间。因此，使用 Redis 似乎不太适合这种情况。我也可以省略 TTL 并清除 connection.close（） 上的 redis 键。但我不能100%确定这种方法的可靠性。

我还考虑过使用粘性会话来确保客户端始终在实时服务的同一实例上工作。在这种情况下，我可以使用内存并降低复杂性，避免这里的 redis。但我不是 100% 确定粘性会话是否可靠。

这里应该使用其他方法吗？

谢谢。