什么是ActiveMQ用于？
我查了一下，然后发送消息给它。 但为什么？ 为什么不使用数据库？ 必须有ActiveMQ有这个数据库不要？
它用于在两个分布式进程之间可靠地进行通信。 是的，您可以将消息存储在数据库中，以便在两个进程之间进行通信，但只要收到消息，就必须删除该消息。 这意味着一个行插入和删除每个消息。 当您试图扩展每秒传达数千条消息时，数据库往往会翻倒。
另一方面，面向消息的中间件如ActiveMQ被构build来处理这些用例。 他们认为，健康系统中的消息将被快速删除，并可以进行优化以避免开销。 它也可以将消息推送给消费者，而不是消费者通过执行SQL查询来轮询新消息。 这进一步减less了处理发送到系统中的新消息所涉及的等待时间。
ActiveMQ或通常所有面向消息的中间件（MOM）实现都是为了在两个应用程序之间发送消息，或者在一个应用程序内部发送两个组件而devise的。
从本质上讲，MOM和数据库共享一个共同的基础，因为它们提供事务性和持久性数据存储以便读写。 最大的区别在于使用模式 – 数据库非常通用，针对多个表的复杂search进行了优化，MOM针对阅读消息进行了优化，一次一个，像FIFO一样以FIFO的forms进行读取。
JMS，这是一个API的ActiveMQ实现，是Java企业应用程序中的一个重要angular落。 这使得消息共享一种相当常见的格式和语义，这使得不同应用程序之间的集成更容易。
当然，还有很多更详细的function，只有在ActiveMQ中，像OpenWire，STOMP和MQTT，JMS，EIP和Apache Camel一样的有线协议，诸如“请求/回复”和“发布/订阅”的消息模式，JMS桥接，集群（“经纪人networking”），允许缩放和分布等。如果您感兴趣，您应该仔细阅读这些主题，因为它们相当大。
Active MQ具有很好的调度程序支持，这意味着您可以安排您的消息在特定时间交付。 我们已经使用这个function发送药物提醒病人上传他们的医疗保健情况下的药物细节。
对于RDBMS，当处理一行数据时，通常会更新一个标志，指示该行已被处理，以便不重复处理。
但是，使用Message Queue，您只需确认一条消息，下一位消费者将处理下一条消息。
不同之处在于RDBMS中的UPDATE语句与activmeq中的acknowlege语句相比是非常慢的操作。
从维基百科
Apache ActiveMQ是一个用Java编写的开源消息代理以及一个完整的Java消息服务（JMS）客户端。 它提供了“企业function”，在这种情况下意味着培养来自多个客户端或服务器的通信
关于你的查询：
为什么不使用数据库？
您应该将数据库用于持久性数据，而不是用于临时数据。 假设您必须从发件人向Receiver发送消息。 收到消息后，接收方执行一个操作（接收，处理和忘记）。 处理完该消息后，根本不需要该消息。 在这种情况下，将消息存储在永久性数据库中不是一个正确的解决scheme。
我完全同意@Hiram Chirino有关在数据库中插入和删除消息的答案，如果您使用数据库而不是消息系统。
这篇文章和这篇文章的好处
- 企业集成 ：允许用不同语言和不同操作系统构build的应用程序相互集成
- 位置透明度 ：客户端应用程序不需要知道服务应用程序的位置
- 可靠的沟通 – 消息的生产者/消费者不必同时可用
- 缩放 – 可以通过添加更多服务来进行水平缩放
- asynchronous通信 – 客户端可以触发消息并继续其他处理，而不是阻塞，直到服务发送响应;
- 减less的耦合 – 客户和服务的假设由于前面的5个好处而大大减less。 服务可以改变有关自身的细节，包括其位置，协议和可用性，而不会影响或中断客户端。
必须有ActiveMQ有这个数据库不要？
有许多。 有关更多详细信息，请参阅文档页面。 看看用例 。
看看这个演示 ，了解ActiveMQ的内部。
我想强调以下几点：
解耦 ：系统能够在没有连接的情况下进行通信。 队列位于系统之间，一个系统故障不会因为通过队列完成通信而影响其他系统故障。 这些系统在启动时继续工作。
恢复支持 ：队列中的消息本身持续存在。 如果队列失败，邮件可以稍后恢复。
可靠的沟通 ：考虑处理客户请求的系统。 在正常情况下，系统每分钟收到100个请求。 当请求数量超出平均水平时，这个系统是不可靠的。 在这种情况下，Queue可以pipe理请求，并且可以基于系统吞吐量周期性地推送消息而不会破坏消息。
asynchronous ：客户端服务器通信是非阻塞的。 一旦客户端发送请求到服务器，它可以做其他操作，而不用等待响应。 当收到响应时，客户端可以随时处理它。
