Question

我查了一下，然后向你发送信息。但为什么？为什么不使用数据库？必须有功能ActiveMQ有数据库不？

Answer 1

它用于在两个分布式进程之间可靠地通信。是的，您可以将消息存储在数据库中以在两个进程之间进行通信，但是，一旦收到消息，您就必须删除该消息。这意味着每个消息的行插入和删除。当您尝试扩展每秒传输数千条消息时，数据库往往会失败。

另一方面，像ActiveMQ这样的面向消息的中间件是为了处理这些用例而构建的。他们假设健康系统中的消息将被非常快速地删除，并且可以进行优化以避免开销。它还可以将消息推送到消费者，而不是消费者必须通过执行SQL查询来轮询新消息。这进一步减少了处理发送到系统中的新消息所涉及的延迟。

Answer 2

ActiveMQ，或者通常所有面向消息的中间件（MOM）实现都是为了在两个应用程序之间或一个应用程序内的两个组件之间发送消息而设计的。

基本上，MOM和数据库共享一个共同的基础，因为它们提供了可以读写的事务和持久数据存储。最大的区别在于使用模式 - 数据库非常通用，并针对多个表的复杂搜索进行了优化，MOM针对读取消息进行了优化，一次一个地，以类似FIFO的方式进行读取。

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

当然，还有很多更详细的功能，只有在ActiveMQ，有线协议如OpenWire，STOMP和MQTT，JMS，EIP和Apache Camel，消息模式如“请求/回复”和“发布/订阅” “，JMS桥接，群集（”经纪人网络“），允许扩展和分发等。如果您感兴趣，您应该仔细阅读这些主题，因为它们相当大。

Answer 3

Active MQ具有出色的调度程序支持，这意味着您可以安排在特定时间传递邮件。我们使用此功能向患者发送药物提醒，以便在医疗保健方案中上传他们的药物详细信息。

Answer 4

使用RDBMS，当您处理一行数据时，通常会更新一个标志，指示该行已被处理，以便不再重复处理。

但是，使用Message Queue，您只需要确认一条消息，下一个消费者将处理下一个消息。

不同之处在于，与激活中的UPDATE相比，RDBMS中的acknowlege语句操作非常慢。

Answer 5

我想强调以下内容：

解耦：系统无需连接即可进行通信。队列位于系统之间，一个系统故障永远不会影响其他系统，因为通过队列进行通信。这些系统在启动时继续工作。

恢复支持：队列中的消息本身仍然存在。如果队列失败，可以稍后恢复消息。

可靠的通信：考虑一个处理客户端请求的系统。在正常情况下，系统每分钟接收100个请求。当请求数超过平均值时，该系统不可靠。在这种情况下，Queue可以管理请求，它可以根据系统吞吐量定期推送消息，而不会破坏它。

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

Answer 6

来自Wikipedia

Apache ActiveMQ是一个用Java编写的开源消息代理以及完整的Java消息服务（JMS）客户端。它提供“企业功能”，在这种情况下意味着促进来自多个客户端或服务器的通信

关于您的查询：

为什么不使用数据库？

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

我完全同意 @Hiram Chirino 关于插入＆amp;如果使用数据库而不是消息传递系统，则删除数据库中的消息。

此article和此article

的好处

企业集成：允许使用不同语言和不同操作系统构建的应用程序相互集成
位置透明度：客户端应用程序无需知道服务应用程序的位置
可靠的沟通 - 消息的制作人/消费者不必同时可用
扩展 - 可以通过添加更多服务来横向扩展
异步通信 - 客户端可以触发消息并继续进行其他处理，而不是阻止，直到服务发送响应为止;
减少耦合 - 由于之前的5个好处，客户和服务所做的假设大大减少。服务可以更改有关自身的详细信息，包括其位置，协议和可用性，而不会影响或中断客户端。

ActiveMQ必须具备数据库不具备的功能吗？

有很多。有关详细信息，请查看documentation页面。也请查看use-cases。

请查看此presentation以了解ActiveMQ的内部信息。

Answer 7

假设您有一个同时在多个位置使用的应用程序。还假设您的应用程序必须每分钟处理1000个请求或类似的事情，因此正常的数据库操作无法处理此类操作，Activemq充当消息处理它将所有消息带入队列，因此即使您的某个应用程序在一个位置崩溃另一个地方不会受到影响。

Answer 8

考虑以下通用用户方案

用户场景

客户上传文本文档
您的应用程序将文本文档转换为PDF
您的应用程序将PDF通过电子邮件发送回给客户

基于队列的系统的数据库 在这种情况下，您可以考虑为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，因为它易于安装，配置并且非常易于扩展。

ActiveMQ用于什么？

8 个答案: