用Hazelcast替换JMS？

Question

我们目前正在运行由一组JMS队列(无主题)连接的分布式Java应用程序.Java应用程序大量使用Apache Camel框架,该框架也用于通过JMS进行通信.作为JMS提供商,我们正在使用ActiveMQ.我们对排队解决方案的要求在功能方面非常基础 - 在某种程度上可与本地Java队列和Camel SEDA队列相媲美:

1. 队列需要高度可用
2. 平均而言,消息非常小(几KB),但不得对大小进行限制(即,传输的消息的一小部分有几个MB)
3. 交付必须"恰好一次"(例如,亚马逊SQS,仅保证"至少一次",这对我们来说是不可接受的)

我们不需要持久队列,因为消息在进入排队系统之前存储在数据库中.到目前为止,ActiveMQ在设置上花了一些时间后对我们来说效果很好.但是,有两个问题因为我们正在寻找不同的解决方案:

• 我们目前通过在JDBC Master-Slave-Mode中运行AMQ来实现高可用性.故障转移工作正常,但不如所希望的那样透明.
• JDBC存储对性能有负面影响,特别是如果我们在几个(> 6)队列上传输更大的消息(> = 2-3 MB).此外,我们有不必要地打扰我们的数据库的感觉.

我们知道AMQ从版本5.9开始支持使用Zookeeper的HA.不过,不久前,我们开始考虑/评估Hazelcast作为AMQ的替代品.很长一段时间,Hazelcast看起来非常迷人,因为它似乎满足了我们所有的要求,并且似乎比使用Zookeeper的AMQ更简单.此外,Camel通过其Hazelcast SEDA功能为使用Hazelcast作为排队解决方案提供了很好的支持.鉴于Hazelcast似乎是我们完美替代AMQ的事实,我们不知道网上没有太多可用的信息讨论Hazelcast作为JMS的(严重)替代品.因此,我们想知道:

• 用Hazelcast替换JMS有什么缺点(性能,可靠性......)？
• 是否有人在Hazelcast中遇到过多MB消息的问题？
• 有没有人遇到过Hazelcast的任何可靠性问题？我们目前仍在使用2.6(因为Camel组件当前正在使用该版本)并且已经在Ubuntu上进行了守护.到目前为止它似乎运行得很完美,但是一些额外的经验会很好听.