ActiveMQ 是用来做什么的? 我们可以使用数据库来应用消息传递的概念吗？

一般来说，所有面向消息的中间件(MOM)实现都是为一个应用程序内部的 在两个应用程序或两个组件之间发送消息而设计的。

从本质上讲，MOM 和数据库共享一个共同的基础，即它们提供事务性和持久性数据存储，可以从中进行读写。
最大的区别在于使用模式——其中数据库非常通用，并且针对多个表的复杂搜索进行了优化，而 MOM 针对读取消息进行了优化，一次读取一条消息，类似于 FIFO [ Queue ]。

JMS是 API ActiveMQ 实现的，是 Java 企业应用程序的重要基石。这使得消息共享相当通用的格式和语义，这使得不同应用程序之间的集成更加容易。

Of course, there are a lot of more detailed features that are only in ActiveMQ, wire protocols like OpenWire, STOMP and MQTT, JMS, EIP together with Apache Camel, message patterns like "request/reply" and "publish/subscribe", JMS Bridging, clustering ("network of brokers"), which allow scaling and distributions, etc.
如果你对这些主题感兴趣，你应该多读一点，因为它们相当大。

它用于两个分布式进程之间的可靠通信。

是的，您可以将消息存储在 数据库中，以便在两个进程之间进行通信，但是，一旦收到消息，您就必须将消息 DELETE，即 这意味着每条消息都有一行 ABC1和 DELETE。
When you try to 规模 that up communicating thousands of messages per second, 数据库容易崩溃.

另一方面，像 ActiveMQ这样的面向消息的中间件[ MOM ]是为处理这些用例而构建的。
它们假设健康系统中的消息将是 删除非常快，可以做优化，以避免开销。

它还可以将消息推送给消费者，而不必让消费者通过执行 SQL 查询来轮询新消息。
这进一步减少了处理发送到系统中的新消息所涉及的延迟。

ActiveMQ有很好的 scheduler支持，这意味着你可以 schedule sending your message to be delivered at a particular time。

我们已经使用这个特性向患者发送药物提醒，上传他们在医疗保健场景中的药物详细信息。

对于 RDBMS，当处理一行数据时，通常会更新一个标志，指示该行已被处理，因此不会重复处理。

但是，使用消息队列，您只需确认一条消息，下一个使用者将处理下一条消息。

区别在于，与 activmeq 中的 acknowledge相比，RDBMS 中的 UPDATE语句是一个非常慢的操作。

来自 维基百科

Apache ActiveMQ is an open source message broker written in Java together with a full Java Message Service (JMS) client. It provides "Enterprise Features" which in this case means fostering the communication from more than one client or server

关于你的问题:

你为什么不用数据库？

应该将数据库用于持久数据，而不是用于临时数据。假设您必须将消息从发送方发送到接收方。在接收消息时，Receiver 执行一个操作(接收、处理和忘记)。处理完该消息后，您根本不需要该消息。在这种情况下，将消息存储在持久性数据库中不是正确的解决方案。

我完全同意 @ Hiram Chirino的回答关于在数据库中插入和删除消息，如果你使用数据库而不是消息系统。

从这个 article和这个 文章的好处

1. 企业集成 : 允许使用不同语言和不同操作系统构建的应用程序相互集成
2. 位置透明度 : 客户端应用程序不需要知道服务应用程序的位置
3. 可靠的通信 ——消息的生产者/消费者不必同时可用
4. Scaling -可以通过添加更多的服务进行水平伸缩
5. 异步通信 -客户端可以触发消息并继续其他处理，而不是阻塞，直到服务发送响应;
6. 减少耦合 -由于前面的5个好处，客户端和服务做出的假设大大减少。服务可以更改自身的详细信息，包括其位置、协议和可用性，而不会影响或干扰客户端。

ActiveMQ 必须有数据库没有的特性？

有很多。看看 文件页了解更多细节。也看看 用例。

看一下这个 presentation，了解 ActiveMQ 的内部结构。

i would like to emphasize the following:

解耦 : 系统能够在没有连接的情况下进行通信。队列位于系统之间，一个系统故障不会影响其他系统，因为通信是通过队列完成的。系统启动后仍能正常工作。

恢复支持 : 队列中的消息本身保持不变。如果队列失败，稍后可以恢复这些消息。

Reliable Communication : Consider a system that process client requests. In normal cases the system receives 100 requests per minute. This system is unreliable when number of request goes beyond average. In such case Queue can manage requests and it can push messages periodically based on system throughput without breaking it.

异步 : 客户端服务器通信是非阻塞的。一旦客户端向服务器发送请求，它就可以执行其他操作，而无需等待响应。当客户端接收到响应时，可以随时处理。

假设您有一个同时在多个位置使用的应用程序。 另外，假设您的应用程序必须每分钟处理1000个请求或类似的操作，因此普通的 db 操作无法处理这样的操作，Activemq 充当消息处理，它将所有消息放入队列，所以即使您的应用程序在一个位置崩溃，另一个位置也不会受到影响。

Consider the following generic user scenario

用户场景

• 客户上传文本文档
• 应用程序将文本文档转换为 PDF
• Your application emails the PDF back to the 顾客

基于队列的系统的数据库 在这种情况下，可以考虑为 PDF 作业行使用数据库。通常，您会创建一个数据库表，其中包含一行与 PDF 需求对话的记录。在这一点上，您可以在表中放置一个冰雹，以说明任务处于哪种状态，以及任务是否已完成。

INSERT INTO pdf_job_queue (name, status, email) VALUES ("White paper", "NEW", "myemail@example.com");


SELECT * FROM pdf_job_queue WHERE queue = 'resize_queue' AND handled = false ORDER BY date_recived limit 1;

您需要编写代码将新请求插入到数据库中。从数据库获取输入的代码，可能会更改状态列，其值为“ NEW”和“ PROCESSING”，处理请求的代码，再次将数据库状态字段更新为“ FINISHED”的代码，以及从队列中删除请求的代码。

update pdf_job_queue set Status="FINISHED" where Id = 'SomeId';

为了有效地操作，可能需要快速和频繁地轮询数据库。当然，这会给数据库和应用程序增加很大的负载。

消息队列 当您尝试通过使用消息队列来实现相同的目标时。

实时推送 来自消息行的消息是实时推送的，而不是偶尔从数据库中调查。使用消息行可以熟练地支持更大量的并发消息。消息行中的消息在获取后自然会被清除。

谢谢 从工作线程发送回一个确认，告诉消息队列某个特定消息已经被接收和处理，并且消息队列可以自由地删除它。如果一个工作者没有发送确认消息而死亡，消息队列将理解消息没有被完全处理，并将其重新发送到队列和另一个工作者。这样您就可以确保没有消息丢失。

对于消息队列系统，我总是推荐使用 ActiveMQ，因为它易于安装、配置和扩展。