java – 高性能JMS消息传递

我从今年的UberConf中读到幻灯片,其中一位演讲者正在提出 Spring JMS为您的消息队列系统添加性能开销的论点,但是我没有看到任何证据支持幻灯片.扬声器还使得点对点比传统的“发布订阅”方法更快,因为每个消息只发送一次而不是被广播给每个消费者.

我想知道有没有经验丰富的Java消息传递大师可以在这里加权,并澄清一些技术性：

>使用Spring JMS而不是纯粹的JMS,是否存在性能开销？如果是这样,它如何和在哪里引入？有什么办法吗？
>有什么实际证据支持P2P比pub-sub模型更快,如果是,有没有任何情况下您想要通过P2P进行公布(即为什么要慢一些？)？

1)主要的是,Spring JMS的开销是使用JmsTemplate来发送消息,在其下方有一个缓存机制.基本上,JmsTemplate将为您发送的每条消息执行以下操作：

>创建连接
>创建会话
>创建生产者
>创建消息
>发送消息
>关闭会话
>关闭连接

这可以与您重复使用的手动代码进行比较：

>创建连接
>创建会话
>创建生产者
>创建消息
>发送消息
>创建消息
>发送消息
>创建消息
>发送消息
>关闭会话
>关闭连接

由于创建连接,会话和生产者需要您的客户端和JMS提供商之间的通信,当然还有资源分配,它将为许多小型消息创建相当大的开销.

您可以通过缓存JMS资源来轻松解决这个问题.例如使用弹簧CachingConnectionFactory或ActiveMQs PooledConnectionFactory(如果您使用ActiveMQ标记了此问题).

如果您正在运行完整的JavaEE容器,则在检索JNDI连接工厂时,池/缓存通常会内置并隐式.

当收到时,使用弹簧默认消息侦听容器,春天有一个薄层可能会增加少量开销,但主要方面是可以根据并发性来调整性能.This article很好地解释了这一点.

PubSub是一种使用模式,发布者不需要知道存在哪些订阅者.你不能简单地用p2p模拟.而且,没有手头的任何证据,我会认为,如果你想从一个应用程序发送相同的消息到另外十个应用程序,pub-sub设置将比发送消息十倍p2p更快.

另一方面,如果只有一个生产者和一个消费者,则选择具有队列的P2P模式,因为在某些方面更易于管理. P2P(队列)允许负载平衡,哪个pub / sub不(很容易).

ActiveMQ还有一个混合版本VirtualDestinations – 这主要是负载平衡的主题.

不同供应商的实际执行情况有所不同,但是主题和队列并没有完全不同,应该表现得相似.你应该检查的是：

坚持？ (=慢)消息选择器(=慢)>并发？耐用订阅者(=慢)>请求/回复“同步”与临时队列(=开销=较慢)>队列预取(=影响某些方面的绩效)>缓存

猜你在找的Java相关文章