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

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

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

当用户注册(或登录时)时，将创建一个以他(或他的ID)命名的JMS主题

当用户登录时，他订阅了他关注的每个用户的JMS主题

session 范围的对象(每个用户)充当JMS消息监听器

所有收到的消息都存储在 session 中(内存中)

通过 session 范围对象

的ajax轮询来更新UI

当用户注销或 session 超时时，消息监听器被破坏

据称，其背后的想法是提高性能-即，不要过于频繁地查询数据存储区，而是将即时的内容缓存在内存中。

整个过程当然可以在集群中运行，并且具有可伸缩性。

但是我不确定:

这实际上是否值得(就性能和可伸缩性方面而言)

JMS是否不会增加不希望的开销，这等于查询数据存储(因此使整个复杂性变得无用)

在某个时候(当事情正常时)，我将进行一些基准测试，但是我想听听一些初步的看法。

最佳答案

听起来足够合理。您需要确保您选择的JMS实现支持潜在的大量主题-并非所有主题都能做到这一点。

我的主要设计问题是，当用户首次登录时，他的消息 session 存储将为空，而您必须等待它填满。然后，您还是不必非要访问数据库，否则这不是问题。

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

由于它不是真正由事件驱动的，因此您也许可以考虑使用分布式内存数据存储，例如EhCache + JGroups或JBossCache3(我强烈建议)。新的推文将放入该分布式商店中，读者只需在其上进行搜寻以寻找感兴趣的物品。这可能会提高内存效率，因为每个推文的一个副本只能存储在每个节点上。您也可以在系统启动时预加载缓存。

关于java - JMS(或任何消息传递解决方案)是否适合关注者/关注模型，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/3606802/