JMS 队列的替代方案
我们有一个 REST Web 服务，可以接收来自外部系统的请求并相应地更新我们的数据库。我正在寻求为传入的请求实现一个缓存/排队解决方案，因为我们最近遇到了一些数据库服务器挑战，并且当数据库服务器出现故障时丢失了一些消息。
在开始构建一个简单的基于文件的持久队列之前，我想看看是否有 JMS 的任何好的替代方案，因为它的使用在我们的环境中受到限制。
当前平台： 乔老板4.3 富脸3.3 春季3.0.5 RESTEasy
** 更新 **
根据下面 skaffman 的问题，我对集群、事务等的要求。
集群：我们的 Web 和应用程序服务器都是集群的，因此队列需要能够处理来自所有集群的项目集群节点。然而，我们的提交本质上是原子的，因此排序和同步问题极少。线程和集群安全并不是真正的因素。每个集群上单独/独立的队列就足够了。
事务：同样，由于我们数据的原子性质，事务需求是最小的/在每个单独的请求之外不需要。
安全性：中等关注，但我预计这将由我们在 Web 服务上的常规安全性来处理。除了网络应用程序本身之外，我预计不会对队列进行任何读取或写入操作。仅在高容量或数据库不可用的情况下才需要这样做。
谢谢，
迈克
We have a REST web service that receives requests from external systems and makes updates to our DB accordingly. I'm looking to implement a caching/queuing solution for the requests that come in, as we've had some DB server challenges lately, and have lost some messages when the DB server went down.
Before I start putting together a simple persistent file-based queue, I'm wanting to see if there are any good alternatives to JMS as it's use is restricted in our environment.
Current platforms:
Jboss 4.3
Richfaces 3.3
Spring 3.0.5
RESTEasy
** UPDATES **
Per skaffman's question below, my requirements for clustering, transactions, etc.
Clustering: Our web and app servers are all clustered, so the queue(s) will need to be able to process items from all cluster nodes. However, our commits are essentially atomic, so ordering and synchronization issues are extremely minimal. Thread and cluster-safety is not really a factor. Separate/Independent queues on each cluster would be sufficient.
Transactions: Again, due to the atomic nature of our data, transactional needs are minmal/not required outside of each individual request.
Security: Moderate concern, but I would anticipate that to be handled by our regular security on the Web Service. I wouldn't anticipate anything reading or writing to the queue(s) other than the web-app itself. That would only be necessary in instances of high volume or when the DB is unavailable.
Thanks,
Mike
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于一个项目，我们确实使用了队列（HornetQ），但被集成到战争中并可部署在 Tomcat 上，因为客户不需要 Weblogic 或 JBoss 应用程序服务器，但如果您的限制策略也适用于您的应用程序架构，那么这样的解决方案将是禁止。
对于另一个项目，我们没有使用任何 JMS 实现，而是通过使用消息数据库和 spring-integration 框架的服务激活器 a> 用于消费事件。
这样，任何消息发布者只需在数据库表中插入一行，服务激活器就会触发事件并调用任何其他服务（Spring、Web 服务等）。
For one project we did use a queue (HornetQ) but was integrated in the war and deployable on a Tomcat because the customer did not want Weblogic or JBoss application servers, but if your restricting policy goes to your application architecture as well such solution would be forbidden.
For another project we did not use any JMS implementation and we make the asynchronous implementation by using a message database and the Service Activator of the spring-integration framework for consuming the events.
That way any message publisher just insert a row in a DB table and the Service Activator trigs the event and call any other service (Spring, Web-service, etc...).