使用消息队列的Web应用程序的体系结构 [英] Architecture of a web application using message queues

问题描述

我有一个Java Web应用程序，该应用程序通过数据库表(EmailQueue)使用某种形式的自定义消息队列来对电子邮件的传递进行排队.该应用程序已部署在Tomcat上，并使用 Quartz 作业来轮询EmailQueue表中要发送的新条目. /p>

我现在需要添加一些其他类型的作业和消息(通知，短信等)的排队，因此正在考虑使用适当的消息队列( ActiveMQ 等)，而不是数据库.这是由很少 和解决方案

1.在Web应用程序的上下文中，消息队列代理通常像数据库一样以其自己的进程运行吗?在服务器重新启动的情况下，我需要消息是持久的.

消息队列代理通常作为其自己的进程运行.使用RabbitMQ，您的生产者可以将消息定义为持久的.

2.消息队列使用者应该在Tomcat中部署为servlet还是在独立的Java应用程序中?我对所有内容的可管理性(即启动/停止实例，配置，监视)以及相关问题和电子邮件线程特别感兴趣.

关于类似主题的问题Quartz jobs which polls for new entries in the EmailQueue table to send.

I now need to add queuing of a few other types of jobs and messages (notifications, sms, etc.) and am therefore looking into using a proper message queue (RabbitMQ, ActiveMQ, etc.) instead of the database. This is motivated by a few articles on the matter which argue a database should not be used as a queue.

I haven't completely gotten my mind wrapped around the whole ecosystem however and would appreciate some guidance. Specifically:

• In the context of web applications, does the message queue broker usually run as its own process, like the database does? I need the messages to be persistent in case of server restarts.
• Should the message queue consumers be deployed as servlets in Tomcat or as standalone java applications? I'm especially interested in the manageability of it all (i.e. start/stop instances, configuration, monitoring) Related question and email thread.

解决方案

1. In the context of web applications, does the message queue broker usually run as its own process, like the database does? I need the messages to be persistent in case of server restarts.

The message queue broker typically runs as its own process. With RabbitMQ, your producers can define the messages to be persistent.

2. Should the message queue consumers be deployed as servlets in Tomcat or as standalone java applications? I'm especially interested in the manageability of it all (i.e. start/stop instances, configuration, monitoring) Related question and email thread.

Regarding my question on a similar topic here, I ultimately deployed my consumers as Tomcat applications, which did provide me with the manageability that I too was looking for. This allowed me to write servlets for monitoring and managing the queues.

This solution works for scalability, also, which is important with messaging & queuing. I was also able to easily scale the number of consumers on the fly by taking a snapshot of the server running Tomcat (I was using Amazon EC2 instances) and deploying that snapshot onto a new instance. I had configured Tomcat to start automatically as a service so that when the new instance started, the consumer .war files would deploy and automatically start consuming.

Be careful with the threading, however, as discussed in my question. I had initially run into problems with stopping Tomcat.

You can also achieve manageability with consumers as standalone Java applications using JMX, however. Using JConsole, you can remote into your Java applications and query/update parameters during runtime. Many monitoring programs, such as Zabbix, can connect to applications using JMX.

If you enjoy web development and building your own web applications, I would go the Tomcat route. Hope that helps.

这篇关于使用消息队列的Web应用程序的体系结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！