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



我查找了它,它曾经在两个系统之间发送消息
但为什么?为什么不直接使用Database
ActiveMQ一定有Databases没有的某些功能?

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

是的,您可以将消息存储在数据库中,以便在两个进程之间进行通信,但是,一旦收到消息,您就必须将消息DELETE这意味着每条消息都有一行INSERTDELETE
当您试图扩展以提高每秒数千条消息的通信量时,数据库往往会崩溃

另一方面,像ActiveMQ这样的面向消息的中间件[MOM]是为处理这些用例而构建的
他们认为健康系统中的消息将被很快删除,并且可以进行优化以避免开销

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

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

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

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

当然,还有许多更详细的功能仅在ActiveMQ中,有线协议(如OpenWireSTOMPMQTT)、JMSEIP以及Apache Camel中,消息模式(如"请求/回复"one_answers"发布/订阅")、JMS桥接、集群("代理网络")允许扩展和分发,等等。
如果你感兴趣的话,你应该读一读这些主题,因为它们相当大。

ActiveMQ具有强大的调度程序支持,这意味着您可以安排在特定时间发送消息

我们使用此功能向在医疗保健场景中上传药物详细信息的患者发送药物提醒。

使用RDBMS,当处理一行数据时,通常会更新一个标志,指示该行已被处理,这样处理就不会重复。

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

不同之处在于,与activmeq中的acknowledge相比,RDBMS中的UPDATE语句是一个非常慢的操作。

来自维基百科

Apache ActiveMQ是一个用Java编写的开源消息代理,它与一个完整的Java消息服务(JMS)客户端一起使用。它提供了"企业功能",在这种情况下,这意味着促进来自多个客户端或服务器的通信

关于您的查询:

为什么不使用数据库?

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

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

本文和本文的好处

  1. 企业集成:允许使用不同语言和不同操作系统构建的应用程序相互集成
  2. 位置透明度:客户端应用程序不需要知道服务应用程序的位置
  3. 可靠的通信–消息的生产者/消费者不必同时可用
  4. 扩展–可以通过添加更多服务进行横向扩展
  5. 异步通信–客户端可以激发消息并继续其他处理,而不是阻止,直到服务发送响应为止
  6. 减少耦合–由于前面的5个优点,客户和服务所做的假设大大减少。服务可以更改自身的详细信息,包括位置、协议和可用性,而不会影响或中断客户端

ActiveMQ一定有数据库没有的功能?

有很多。查看文档页面了解更多详细信息。也可以看看用例。

看看这个演示文稿,了解一下ActiveMQ的内部结构。

我想强调以下几点:

解耦:系统可以在不连接的情况下进行通信。队列位于系统之间,一个系统故障永远不会影响另一个系统,因为通信是通过队列完成的。系统在启动时继续工作。

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

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

异步:客户端-服务器通信是非阻塞的。一旦客户端将请求发送到服务器,它就可以在不等待响应的情况下执行其他操作。当收到响应时,客户端可以随时处理。

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

考虑以下通用用户场景

用户场景

  • 客户上传文本文档
  • 您的应用程序将文本文档转换为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;

您需要编写代码将新请求插入数据库。从数据库中获取输入的代码,可能会更改状态列,其值为";CCD_ 18";以及";CCD_ 19";,处理请求的代码、再次将数据库状态字段更新为"0"的更多代码;CCD_ 20";,以及从队列中删除请求的更多代码。

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

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

消息队列当您试图通过使用消息队列来实现这一点时。

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

确认工作进程发回确认,告知消息队列已接收和处理特定消息,消息队列可以自由删除该消息。如果工作进程在未发送确认的情况下死亡,消息队列将理解消息未完全处理,并将其重新传递给队列和另一个工作进程。这样你就可以确保不会丢失任何信息。

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

相关内容

最新更新