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

Question

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

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

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

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

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

Answer 1

我使用竞争消费者模式和租用模式的组合，对集群中的消息进行了相当大规模的顺序处理- 1.5 million+消息/天。

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

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

这对我们来说很有效，这个过程在生产中生活了大约4年，然后由于公司合并而被替换。

编辑：

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

编辑：

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

我不认为你需要放弃你现在已经拥有的MDB机制。本质上，我们在这里讨论的是对分布式锁机制的要求，不能用太花哨的话来形容它。

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

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

我认为，这应该是非常简单的。现在，您希望让休眠的MDB偶尔检查锁，看看它是否被释放。

因此，活动的MDB和休眠的MDB都必须周期性地做一些事情。你可以让他们产生一个单独的线程来做这件事。如果您这样做，许多应用程序引擎供应商都不会高兴，但添加一个线程没什么大不了的，特别是因为它大部分时间都在休眠。另一种选择是绑定到许多引擎提供的计时器机制中，并让它定期唤醒您的MDB以检查租约。

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

Answer 2

第一点:这是一个非常糟糕的设计，一次只能处理一条消息会严重限制性能。我假设你集群仅仅是为了容错，因为你不会得到性能提升？

您是在OC4J中使用默认的JMS实现，还是在使用其他实现？

我过去使用过IBM的MQ，它有一个特性，队列可以被标记为独占，这意味着只有一个客户端可以连接到它。这似乎提供了你想要的东西。

另一种方法是引入序列ID (与递增计数器一样简单)，处理消息的客户端将检查序列ID是否为下一个期望值，如果不是，则将消息放回原处。这种方法要求不同的客户端持久化它们在一些集中共享的数据存储中看到的最后一个有效的序列ID。

Answer 3

我同意stevendick的观点:也许你偏离了设计的轨道。关于sequence ID或类似的方法，我建议您使用Enterprise Integration Pattern: Designing，Building，and Deploying messaging Solutions (作者: Gregor Hohpe y Bobby Woolf)深入了解消息传递架构。这是一本很棒的书，有很多有用的模式。我相信你所面临的力量和问题在那里都描述得很好。