我被问了很多关于ActiveMQ如何存储消息（或在某些情况下不存储）的基本知识。 这是它的高级解释。 注意，上下文在JMS中。 如果您使用ActiveMQ的非JMS客户端（即STOMP，AMQP，MQTT等），则在某些情况下行为可能有所不同。

ActiveMQ

在不丢失标记为“持久”的消息方面，JMS持久性保证非常强大。 让我们看看它如何适用于ActiveMQ

主题

主题是一种广播机制。 它们使我们能够在JMS领域中实现发布-订阅语义。 但是，如果我们将消息标记为“持久”并且没有订阅者，会发生什么情况？ 在任何普通广播中（即，我去市区并开始大喊ActiveMQ的出色表现），如果没有订阅者（3a，周围没有人听到我的声音……）如果我不在，一定是一个美好的夜晚在3a）会发生什么？ 没有。 没有人听到。 然后我们继续前进。 如果您发布消息（持久的或非持久的），并且没有订阅者（没有活动的订阅者和持久的订阅者），ActiveMQ不会对其进行任何处理。

ActiveMQ仅在持久订户（活动或不活动）的情况下存储消息。 对于非活动的持久订阅，ActiveMQ会将标记为“持久”的消息存储到非易失性存储中，并等待订阅者重新加入订阅。 届时它将尝试传递消息。

Queue列

对于队列，ActiveMQ使用简单的默认协议来处理“持久”消息。 我们基本上阻止了主要生产者线程，并等待确认经纪人实际上已收到消息：

制片人：

• 生产者发送消息
• 生产者阻止，等待来自代理的ACK
  • 如果成功确认，生产者继续

经纪人：

• 收到消息
• 将消息存储到磁盘
• 发回ACK

对于“非持久”发送，流程是不同的。 我们以“即发即弃”模式发送邮件。 主生产者线程不会被阻塞，并且在ActiveMQ连接传输线程上异步发生任何ACK或其他响应：

• 生产者发送消息
• 生产者继续其线程并且不阻塞
• 生产者最终在与主生产者线程不同的单独线程上获得ACK
  • 如果失败，则客户端可以订阅JMS ExceptionListener以获得通知

交易发送？

通过批量处理多个消息以一次发送，我们可以提高发送给代理的性能。 这样可以更有效地利用网络以及代理存储。 发送交易时，您必须意识到一个重要的区别。 TX会话的打开和关闭（回滚/提交）都是与代理的同步交互， 但是 ，TX窗口中每个消息的发送都是异步发送的。 如果一切正常，这是可以的，因为代理将这些消息分批处理。 但是，如果有运输错误怎么办？ 还是代理用完了空间来保存这些消息？

我们需要设置一个ExceptionListener来监视这些发送期间的错误。 我们还需要（或应该）设置一个客户端发送“生产者窗口”，以允许我们在经纪人资源耗尽时实施生产者流控制。 有关更多信息，请参见ActiveMQ生产者流控制 。

更改默认值

生产者上有趣的设置，可以更改以下行为：

• useAsyncSend –始终异步等待ACK，即使在持久发送和提交中也是如此
• alwaysSyncSend –强制所有发送（包括非持久性或事务性发送）始终等待来自代理的ACK

人们通常想要使用默认值。

存储

对于ActiveMQ的生产用途，我目前建议使用共享存储方法 。 在这种情况下，我们需要了解存储层正在发生的事情，以了解ActiveMQ的保证。

默认情况下，ActiveMQ将实现JMS持久性要求，该要求基本上规定了所存储的消息必须在崩溃后幸免。 为此，默认情况下，我们将在文件系统上执行“ fsync”。 现在，每个系统上发生的情况将取决于您使用的操作系统，网络，存储控制器，存储设备等。 对于需要持久存储消息并且不是特定于ActiveMQ的任何类型的数据库，这都是您期望的。

当我们写入ActiveMQ事务日志时，我们需要让OperatingSystem通过调用fsync将日志刷新到磁盘。 基本上发生的是，我们迫使操作系统回写用于将文件更改缓存到存储介质的页面文件缓存。 它还鼓励存储介质执行将数据“存储”到磁盘所需的操作（取决于实现）：

一些存储控制器具有自己的缓存，需要刷新。 磁盘驱动器具有自己的缓存，等等。其中某些缓存由电池支持，并且可能以自己的时间间隔写回，等等。为了使您了解通过ActiveMQ运行的消息的持久性，您应该了解您的存储层。

消费者

最后，难题的最后一部分是我们如何向消费者传递/分发消息以及他们如何确认。 ActiveMQ JMS库可以为您处理所有这些操作，因此您不必担心是否会丢失消息。

消息将被分发到消费者，直到达到驻留在消费者身上的某个“预取”缓冲区为止。 这可以通过使使用者上的可用消息缓存准备好进行处理，然后在使用者使用它们时重新填充此缓存，来帮助加速消息处理。 在ActiveMQ中，这些预取的消息在控制台中表示为“运行中”。 这一点取决于消费者来处理这些消息并对其进行确认。 （这将取决于确认模式。默认的自动确认将在使用者获取消息时发送ACK。对于更重要的消息处理，您可能希望使用“客户端”确认，其中客户端明确说明何时确认消息，也就是说，在完成某些处理后）。

如果使用者由于某种原因失败，则任何未确认的消息将重新发送到另一个使用者（如果有），并按照上述相同的处理过程进行。 代理在收到ACK之前不会从其索引中删除该消息。 因此，这包括使用者级别和网络级别的故障。 如果即使在消费者被“成功处理”之后，在这两个级别上都存在错误（请注意，这是非常用例的特定含义，即“成功处理”的意思），并且经纪人未收到确认，则可能是经纪人将重新发送消息。 在这种情况下，您最终可能会在使用者方面产生重复，并且可能会希望实现一个幂等的使用者。 为了扩大消息传递的生产者/消费者，无论如何，您都需要有幂等的消费者。

最后要注意的一点：不使用XA事务，JMS不会一次保证消息，也只能一次处理消息。 JMS在一次就可以保证一次传递的范围内，可以将消息标记为“已重新传递”，并让消费者检查该消息，但是消费者应负责处理多少次（或与幂等的消费者过滤掉）。

翻译自: https://www.javacodegeeks.com/2016/05/message-durability-activemq-5-x.html