我查了一下你就发了信息 . 但为什么？为什么不使用数据库？必须有功能ActiveMQ有数据库不？
ActiveMQ，或者通常所有面向消息的中间件（MOM）实现都是为了在两个应用程序或一个应用程序内的两个组件之间发送消息而设计的 .
从本质上讲，MOM和数据库共享一个共同的基础，因为它们提供了可以读写的事务和持久数据存储 . 最大的区别在于使用模式 - 数据库非常通用，并针对多个表的复杂搜索进行了优化，MOM针对以类似FIFO的方式一次一个地读取消息进行了优化 .
JMS是API ActiveMQ实现的API，是Java Enterprise应用程序中的重要基石 . 这使得消息共享相当普通的格式和语义，这使得不同应用程序之间的集成更容易 .
当然，还有很多更详细的功能，只有在ActiveMQ，有线协议，如OpenWire，STOMP和MQTT，JMS，EIP和Apache Camel，消息模式，如“请求/回复”和“发布/订阅”，JMS桥接，聚类（“经纪人网络”），允许扩展和分发等 . 如果您感兴趣，您应该仔细阅读这些主题，因为它们相当大 .
它用于在两个分布式进程之间可靠地通信 . 是的，您可以将消息存储在数据库中以在两个进程之间进行通信，但是，一旦收到消息，您就必须删除该消息 . 这意味着每个消息的行插入和删除 . 当您尝试扩展每秒传输数千条消息时，数据库往往会倒下 .
另一方面，像ActiveMQ这样的面向消息的中间件是为处理这些用例而构建的 . 他们假设 Health 系统中的消息将被非常快速地删除，并且可以进行优化以避免开销 . 它还可以将消息推送到消费者，而不是消费者必须通过执行SQL查询来轮询新消息 . 这进一步减少了处理发送到系统中的新消息所涉及的延迟 .
我想强调以下几点：
Decoupled ：系统无需连接即可进行通信 . 队列位于系统之间，一个系统故障永远不会影响其他系统，因为通过队列进行通信 . 这些系统在启动时继续工作 .
Recovery support ：队列中的消息本身仍然存在 . 如果队列失败，可以稍后恢复消息 .
Reliable Communication ：考虑处理客户端请求的系统 . 在正常情况下，系统每分钟接收100个请求 . 当请求数超过平均值时，该系统不可靠 . 在这种情况下，Queue可以管理请求，它可以根据系统吞吐量定期推送消息，而不会破坏它 .
Asynchronous ：客户端服务器通信是非阻塞的 . 客户端向服务器发送请求后，无需等待响应即可执行其他操作 . 当收到响应时，客户端可以随时处理它 .
假设您有一个同时在多个位置使用的应用程序 . 还假设您的应用程序必须每分钟处理1000个请求或类似的事情，因此正常的数据库操作无法处理此类操作，Activemq充当消息处理它将所有消息带入队列，因此即使您的某个应用程序在一个位置崩溃其他位置不会受到影响 .
使用RDBMS，当您处理一行数据时，通常会更新一个标志，指示该行已被处理，以便不再重复处理 .
但是，使用Message Queue，您只需要确认一条消息，下一个消费者将处理下一个消息 .
不同之处在于，与activemeq中的 acknowlege 相比，RDBMS中的 UPDATE 状态是一个非常慢的操作 .
acknowlege
UPDATE
来自Wikipedia
Apache ActiveMQ是一个用Java编写的开源消息代理以及完整的Java消息服务（JMS）客户端 . 它提供“企业功能”，在这种情况下，它意味着促进来自多个客户端或服务器的通信
关于你的疑问：
为什么不使用数据库？
您应该将数据库用于持久数据而不是临时数据 . 假设您必须从发件人向Receiver发送消息 . 在接收消息时，Receiver执行一个操作（接收，处理和忘记） . 处理完该消息后，您根本不需要该消息 . 在这种情况下，将消息存储在持久数据库中不是一个正确的解决方案 .
如果您使用数据库而不是消息系统，我完全同意@Hiram Chirino关于在数据库中插入和删除消息的答案 .
这个article和article的好处
Enterprise integration ：允许使用不同语言和不同操作系统构建的应用程序与之集成彼此
Location transparency ：客户端应用程序不需要知道服务应用程序的位置
Reliable communication - 消息的 生产环境 者/消费者不必同时可用
Scaling - 可以通过添加更多服务进行水平扩展
Asynchronous communication - 客户端可以触发消息并继续其他处理而不是阻塞，直到服务发送响应为止;
Reduced coupling - 由于之前的5项好处，客户和服务所做的假设大大减少 . 服务可以更改有关自身的详细信息，包括其位置，协议和可用性，而不会影响或中断客户端 .
必须有功能ActiveMQ有数据库不？
有许多 . 有关详细信息，请查看documentation页面 . 看看use-cases也是如此 .
看看这个presentation，了解ActiveMQ的内部结构 .
Active MQ具有出色的调度程序支持，这意味着您可以安排在特定时间传递邮件 . 我们使用此功能向患者发送药物提醒，以便在医疗保健方案中上传他们的药物详细信息 .
7 回答
ActiveMQ，或者通常所有面向消息的中间件（MOM）实现都是为了在两个应用程序或一个应用程序内的两个组件之间发送消息而设计的 .
从本质上讲，MOM和数据库共享一个共同的基础，因为它们提供了可以读写的事务和持久数据存储 . 最大的区别在于使用模式 - 数据库非常通用，并针对多个表的复杂搜索进行了优化，MOM针对以类似FIFO的方式一次一个地读取消息进行了优化 .
JMS是API ActiveMQ实现的API，是Java Enterprise应用程序中的重要基石 . 这使得消息共享相当普通的格式和语义，这使得不同应用程序之间的集成更容易 .
当然，还有很多更详细的功能，只有在ActiveMQ，有线协议，如OpenWire，STOMP和MQTT，JMS，EIP和Apache Camel，消息模式，如“请求/回复”和“发布/订阅”，JMS桥接，聚类（“经纪人网络”），允许扩展和分发等 . 如果您感兴趣，您应该仔细阅读这些主题，因为它们相当大 .
它用于在两个分布式进程之间可靠地通信 . 是的，您可以将消息存储在数据库中以在两个进程之间进行通信，但是，一旦收到消息，您就必须删除该消息 . 这意味着每个消息的行插入和删除 . 当您尝试扩展每秒传输数千条消息时，数据库往往会倒下 .
另一方面，像ActiveMQ这样的面向消息的中间件是为处理这些用例而构建的 . 他们假设 Health 系统中的消息将被非常快速地删除，并且可以进行优化以避免开销 . 它还可以将消息推送到消费者，而不是消费者必须通过执行SQL查询来轮询新消息 . 这进一步减少了处理发送到系统中的新消息所涉及的延迟 .
我想强调以下几点：
Decoupled ：系统无需连接即可进行通信 . 队列位于系统之间，一个系统故障永远不会影响其他系统，因为通过队列进行通信 . 这些系统在启动时继续工作 .
Recovery support ：队列中的消息本身仍然存在 . 如果队列失败，可以稍后恢复消息 .
Reliable Communication ：考虑处理客户端请求的系统 . 在正常情况下，系统每分钟接收100个请求 . 当请求数超过平均值时，该系统不可靠 . 在这种情况下，Queue可以管理请求，它可以根据系统吞吐量定期推送消息，而不会破坏它 .
Asynchronous ：客户端服务器通信是非阻塞的 . 客户端向服务器发送请求后，无需等待响应即可执行其他操作 . 当收到响应时，客户端可以随时处理它 .
假设您有一个同时在多个位置使用的应用程序 . 还假设您的应用程序必须每分钟处理1000个请求或类似的事情，因此正常的数据库操作无法处理此类操作，Activemq充当消息处理它将所有消息带入队列，因此即使您的某个应用程序在一个位置崩溃其他位置不会受到影响 .
使用RDBMS，当您处理一行数据时，通常会更新一个标志，指示该行已被处理，以便不再重复处理 .
但是，使用Message Queue，您只需要确认一条消息，下一个消费者将处理下一个消息 .
不同之处在于，与activemeq中的
acknowlege相比，RDBMS中的UPDATE状态是一个非常慢的操作 .来自Wikipedia
关于你的疑问：
您应该将数据库用于持久数据而不是临时数据 . 假设您必须从发件人向Receiver发送消息 . 在接收消息时，Receiver执行一个操作（接收，处理和忘记） . 处理完该消息后，您根本不需要该消息 . 在这种情况下，将消息存储在持久数据库中不是一个正确的解决方案 .
如果您使用数据库而不是消息系统，我完全同意@Hiram Chirino关于在数据库中插入和删除消息的答案 .
这个article和article的好处
Enterprise integration ：允许使用不同语言和不同操作系统构建的应用程序与之集成彼此
Location transparency ：客户端应用程序不需要知道服务应用程序的位置
Reliable communication - 消息的 生产环境 者/消费者不必同时可用
Scaling - 可以通过添加更多服务进行水平扩展
Asynchronous communication - 客户端可以触发消息并继续其他处理而不是阻塞，直到服务发送响应为止;
Reduced coupling - 由于之前的5项好处，客户和服务所做的假设大大减少 . 服务可以更改有关自身的详细信息，包括其位置，协议和可用性，而不会影响或中断客户端 .
有许多 . 有关详细信息，请查看documentation页面 . 看看use-cases也是如此 .
看看这个presentation，了解ActiveMQ的内部结构 .
Active MQ具有出色的调度程序支持，这意味着您可以安排在特定时间传递邮件 . 我们使用此功能向患者发送药物提醒，以便在医疗保健方案中上传他们的药物详细信息 .