我想知道有没有经验丰富的Java消息传递大师可以在这里加权,并澄清一些技术性：
>使用Spring JMS而不是纯粹的JMS,是否存在性能开销？如果是这样,它如何和在哪里引入？有什么办法吗？
>有什么实际证据支持P2P比pub-sub模型更快,如果是,有没有任何情况下您想要通过P2P进行公布(即为什么要慢一些？)？
解决方法
>创建连接
>创建会话
>创建生产者
>创建消息
>发送消息
>关闭会话
>关闭连接
这可以与您重复使用的手动代码进行比较：
>创建连接
>创建会话
>创建生产者
>创建消息
>发送消息
>创建消息
>发送消息
>创建消息
>发送消息
>关闭会话
>关闭连接
由于创建连接,会话和生产者需要您的客户端和JMS提供商之间的通信,当然还有资源分配,它将为许多小型消息创建相当大的开销.
您可以通过缓存JMS资源来轻松解决这个问题.例如使用弹簧CachingConnectionFactory或ActiveMQs PooledConnectionFactory(如果您使用ActiveMQ标记了此问题).
如果您正在运行完整的JavaEE容器,则在检索JNDI连接工厂时,池/缓存通常会内置并隐式.
当收到时,使用弹簧默认消息侦听容器,春天有一个薄层可能会增加少量开销,但主要方面是可以根据并发性来调整性能.This article很好地解释了这一点.
2)
PubSub是一种使用模式,发布者不需要知道存在哪些订阅者.你不能简单地用p2p模拟.而且,没有手头的任何证据,我会认为,如果你想从一个应用程序发送相同的消息到另外十个应用程序,pub-sub设置将比发送消息十倍p2p更快.
另一方面,如果只有一个生产者和一个消费者,则选择具有队列的P2P模式,因为在某些方面更易于管理. P2P(队列)允许负载平衡,哪个pub / sub不(很容易).
ActiveMQ还有一个混合版本VirtualDestinations – 这主要是负载平衡的主题.
不同供应商的实际执行情况有所不同,但是主题和队列并没有完全不同,应该表现得相似.你应该检查的是：
坚持？ (=慢)消息选择器(=慢)>并发？耐用订阅者(=慢)>请求/回复“同步”与临时队列(=开销=较慢)>队列预取(=影响某些方面的绩效)>缓存
原文地址：https://www.jb51.cc/java/125485.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
