java - JMS(或任何消息传递解决方案)是否适合追随者/追随者模型

Question

为简单起见，假设我正在克隆 Twitter(我不是)。所以每个用户都可以关注其他用户，也可以被其他用户关注。对于您关注的每个用户，您都会收到他发送的所有推文。一切都存储在数据存储中(无论是 NoSQL 解决方案还是分片关系数据库)。

但是，当用户在线时，您认为让他们通过 JMS 接收推文而不是轮询数据库并检索新推文是否合适:

• 当用户注册(或登录)时，将创建一个以他(或他的 ID)命名的 JMS 主题
• 当用户登录时，他订阅了他关注的每个用户的 JMS 主题
• 一个 session 范围的对象(每个用户)充当 JMS 消息监听器
• 所有收到的消息都存储在 session 中(内存中)
• UI 通过 session 范围对象的 ajax 轮询更新
• 当用户注销，或者他的 session 超时时，消息监听器被销毁

这背后的想法据称是为了提高性能——即不要过于频繁地查询数据存储，而是将即时事物缓存在内存中。

当然，整个事情都希望在集群中运行，并且是可扩展的。

不过我不确定:

• 这是否真的值得(就性能和可扩展性 yield 而言)
• JMS 是否不增加不必要的开销，这等于查询数据存储(并因此使整个复杂化变得无用)

在某些时候(当事情正常运行时)我会做一些基准测试，但我想听听一些初步的评论。

Answer 1

听起来很合理。您需要确保您选择的 JMS 实现支持可能非常大量的主题 - 并非所有主题都能优雅地做到这一点。

我的主要设计问题是，当用户首次登录时，他的消息 session 存储将为空，您必须等待它填满。无论如何您都不必访问数据库，或者这不是问题。

另外，您在这里并没有真正利用 JMS 的事件驱动特性。从主题收到的消息只是转储到 session 存储中供以后检索。

由于它不是真正的事件驱动，您或许可以考虑使用分布式内存数据存储，例如 EhCache+JGroups 或 JBossCache3(我强烈推荐)。新的推文将被放入这个分布式存储中，读者只需要搜索感兴趣的内容即可。这可能会更节省内存，因为每个推文只会存储一个副本在每个节点上。您还可以在系统启动时预加载缓存。