java - 确保在 OC4J 集群中串行处理 JMS 消息

Question

我们有一个使用消息驱动 bean 处理 JMS 消息的应用程序。此应用程序部署在 OC4J 应用程序服务器上。 (10.1.3)

我们计划在多个 OC4J 应用程序服务器上部署此应用程序，这些服务器将被配置为在集群中运行。

问题出在这个集群中的 JMS 消息处理上。我们必须确保在整个 OC4J 集群中一次只处理一条消息。这是必需的，因为必须按时间顺序处理消息。

您是否知道可以控制跨 OC4J 集群的消息处理的配置参数？

或者您认为我们必须实现自己的同步代码来同步集群中的消息驱动 bean？

Answer 1

我结合使用竞争消费者模式和租赁模式，在集群中对消息进行了大规模的顺序处理 - 每天 150 万多条消息。

不过，问题来了 - 您一次只能处理一个交易的要求将使您无法实现自己的目标。我们有相同的基本要求——必须按顺序处理消息。至少，我们认为我们做到了。然后我们有了一个顿悟——当我们对这个问题进行更多思考时，我们意识到我们不需要完全排序。我们实际上只需要在每个帐户内订购。因此，我们可以通过将帐户范围分配给集群中的不同服务器来在集群中的服务器之间分配负载。然后，每个服务器负责按顺序处理给定帐户的消息。

这是第二个聪明的部分 - 我们使用租用模式动态地将帐户范围分配给集群中的各个服务器。如果集群中的一台服务器出现故障，另一台将抢占租约并接管第一台服务器的责任。

这对我们很有效，并且该流程在生产中使用了大约 4 年，之后因公司合并而被替换。

编辑:

我在这里更详细地解释了这个解决方案:http://coders-log.blogspot.com/2008/12/favorite-projects-series-installment-2.html

编辑:

好的，明白了。您已经在您需要的级别进行处理，但是由于您正在部署到一个集群，您需要确保只有一个 MDB 实例正在主动从队列中拉取消息。另外，您需要最简单可行的解决方案。

我认为您不需要放弃现有的 MDB 机制。本质上我们在这里讨论的是对分布式锁机制的需求，而不是花言巧语。

所以，让我提出这个建议。在您的 MDB 注册接收来自队列的消息时，它应该检查分布式锁，看看它是否可以获取它。第一个获取锁的 MDB 获胜，只有它会注册接收消息。所以，现在你有了序列化。这个锁应该采用什么形式？有很多可能性。好吧，这个怎么样。如果您有权访问数据库，那么它的事务锁定已经提供了您所需要的一些功能。创建一个只有一行的表。该行是当前持有锁的服务器的标识符和过期时间。这是服务器的租约。每个服务器都需要有一种方法来生成其唯一标识符，例如，可能是服务器名称加上线程 ID。

如果服务器可以获得对该行的更新访问权，并且租约已过期，则它应该获取它。否则，它会放弃。如果它获得了租约，它需要在不久的将来更新该行，比如五分钟左右，然后提交更新。 Activity 服务器应在租期到期前更新租约。我建议在剩余一半时间时更新它，因此，如果租约在五天后到期，则每 2-1/2 分钟更新一次。这样，您现在就可以进行故障转移了。如果 Activity MDB 死亡，另一个 MDB(并且只有一个)将接管。

我认为这应该非常简单。现在，您想让 hibernate 的 MDB 偶尔检查锁以查看它是否已释放。

因此， Activity 的 MDB 和 hibernate 的 MDB 都必须定期执行某些操作。您可能让他们生成一个单独的线程来执行此操作。如果您这样做，许多应用程序引擎供应商会不高兴，但是添加一个线程没什么大不了的，尤其是因为它大部分时间都在 hibernate 。另一种选择是结合许多引擎提供的计时器机制，并让它定期唤醒您的 MDB 以检查租约。

哦，顺便说一句 - 确保服务器管理员使用 NTP 来保持时钟合理同步。