java - 使用 ThreadPool 和 JMS 时处理 JVM 崩溃

Question

我有一个独立的 Java 进程，它从 JMS 持久主题读取消息并将它们提交到线程池进行处理。我这样做是出于明显的并发原因，但保持这些消息的处理顺序，我仍然将它们提交到单个线程池。现在这是我对 JVM 崩溃的担忧..

--非事务性
我不会在事务上下文中读取和处理每条消息，我避免这样做，因为它会减慢我的流程。因此，我正在线程池的阻塞队列中累积消息。但是，如果 JVM 崩溃，而线程池中有 10 条消息等待处理，我将丢失该数据。

--事务性
我相信，如果我读取并处理事务中的每条消息，如果出现问题，该消息将在备份时重新传送到进程。

由于这是许多在低延迟系统中工作的人的常见问题，想知道有经验的人如何解决这个问题？谢谢。

Answer 1

彼得的据我所知是正确的。解决此问题的一种方法是，如果该模式适用于您，则使用某种划分来创建不同的队列来将消息分组到其中。也就是说，这一要求经常被分解为“一个帐户的所有消息必须按顺序处理”之类的意思。因此，如果您有类似的东西，您可以创建:

• 一个主题，有多个订阅者，每个订阅者使用一个独占选择器(或子主题模式)
• 多个主题，每个主题只有一个订阅者。

那么您的发布商必须确定:

• 已发布消息的 header ，以便订阅者可以使用正确的选择器，或者
• 要发布的正确子主题，或者
• 要发布的正确主题

执行此操作的一种易于维护的模式是使用您的业务字段之一(例如帐号)并对其计算 mod(x)，其中 x> 是您希望分担工作负载的订阅者数量。希望您的业务 key 是数字，并且会给您一个不错的分布，但是您始终可以使用其他一些确定性算法通过反转 key 和/或散列其非数字值来生成此数字。

顺便说一句，您的大纲更多地具有点对点/JMS 队列的感觉，而不是发布-订阅/JMS 主题的感觉。您确定要使用主题吗？

如果您绝对不能丢失数据，那么您应该使用事务性消息。如果您使用事务性消息，则无法委托(delegate)给线程池。 JMS 消息的事务上下文(即 session )绑定(bind)到接收消息的线程，因此除非您启用一些“有趣的业务”将此上下文传输到另一个线程......

我什至不知道如何结束这句话。

====更新====

现在我想了一下，如果您可以从并行处理消息中受益，您可以在一个事务中检索一批消息，并将它们全部委托(delegate)给 ExecutorService.invokeAll调用，等待完成并在全部完成后提交事务。如果 invokeAll 超时，或者其中一个任务引发异常，那么您将必须回滚事务或采取某种补偿操作。