JMS（或任何消息传递解决方案）是否适合追随者/追随者模型答案

【问题标题】：Is JMS (or any messaging solution) appropriate for a follower/following modelJMS（或任何消息传递解决方案）是否适合追随者/追随者模型
【发布时间】：2014-09-22 15:18:53
【问题描述】：

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

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

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

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

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

但我不确定：

这是否真的值得（在性能和可扩展性方面）
JMS 是否不会增加不必要的开销，这等于查询数据存储（从而使整个复杂性变得无用）

在某个时间点（当它功能正常时）我会做一些基准测试，但我想听听一些初步意见。

【问题讨论】：

标签： java architecture jms scalability messaging

【解决方案1】：

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

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

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

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

【讨论】：

是的，登录时数据库会被点击一次，但整个会话就是这样（当然，除非您想检索较旧的“推文”）。分布式缓存建议非常好 - 我将轮询缓存（相同的 cpu 负载），而不是轮询 JMS 提供程序，但每个节点将存在一次消息。实际上，只有一个轮询——ajax，每个请求都会在缓存中查找（而不是ajax pools pojo，pojo polls jms）
@Bozho：如果您希望它能够很好地扩展，那么尝试将会话活动与数据库完全分离可能是值得的。

【解决方案2】：

注意：我对你在问题中描述的系统设置没有实际经验，所以以下是真正的理论考虑。

一个因素是问题，您的用户在下次登录时会看到什么：

在用户之前的会话中尚未发送给用户的所有推文。或者
过去 x 小时内发布的所有推文。

案例 1：JMS 很好，因为队列可以记住哪些消息已经被传递。但是等等：这意味着，每条消息receiver必须有一个队列。

案例 2：在这里，您可以真正处理每条消息发件人的主题，并使超过 x 小时的消息过期。再次重申，JMS 可能是一个不错的选择。

性能

JMS 实现通常可以将消息保存在内存中，并且要访问队列/主题中的消息，您不必在大型索引中搜索 - 所以我认为这应该比数据库更快，可能仍然比内存数据库快。当一个节点发生故障时，您可以从后备数据库重新创建队列，也可以使用一些 JMS 实现中内置的 high-availability 和 persistence。

但我完全同意 skaffman 的观点：与分布式内存数据存储相比，您将使用更多内存。 JMS 的优势在于，它简化了消息（以及其他一些事情）的自动过期，我不知道重新实现该功能是否是个好主意。

所以也许我会做的只是将 ID 保存在队列中，并将实际消息保存在 Java 对象缓存中。这样，您将不得不再次使用索引，但您可以从 JMS 获得便利，并获得对象缓存的大部分内存效率。当缓存仅在发送方一侧时，它甚至不必分发，假设来自一个发送方的所有消息都驻留在一个（复制的）节点上 - 但这可能取决于许多其他架构决策。

【讨论】：