我有一个基本的Java Messaging应用程序，它将JAVA对象发送到远程服务器进行处理。我在线路的两端利用Spring支持，并使用ActiveMQ作为我的JMS提供者。它工作得很好 - 我们没有遇到10个同时发送消息的客户端的实际问题。
但是，我们现在真的想扩展。客户数量可能会增加到大约500个。此外，每个客户端使用的带宽比最初声明的问题更多。
我想知道是否有人认为ActiveMQ是这项工作的正确工具 - 或者基于套接字的TCP / UDP是否有助于我们更好地扩展。我们并不精通AMQ的某些“高级”功能，因为我们在Spring JMS模板的基本支持下使用它。
任何评论/想法都将不胜感激。
由于
答案 0 :(得分：3)
在不知道您尝试实现什么样的服务质量和SLA的情况下，我在评估任何应用程序的消息传递服务实现时遵循的基本规则如下......
性能超过可靠性
在这种情况下，像ZeroMq（以及其他类似产品）这样的产品就足够了，因为它在套接字级工作，分散，提供极低的延迟并在大型分布式系统中很好地扩展，并且是开源的，因此成本可以忽略不计。如果某些用例需要持久性和可靠性，请准备好实现传统消息传递中间件提供的自定义解决方案（持久性，持久性，复制等）。
平衡性能和可靠性
以下是ActiveMQ，RabbitMq等产品的用武之地。基于代理的中间件解决了可靠性和持久性问题，同时提供了良好的性能和可伸缩性。对于中小型公司来说，支持成本通常足够低，而且不会破坏银行。可以肯定地说，大多数消息传递需求属于这一类，因为它提供了对性能和可靠性的可访问性，并且随着应用程序的成熟，您可以根据未来需求牺牲一个消息，而不会因为选择错误而更换整个消息传递基础结构几年前。
可靠性优于绩效
金融公司，交易系统，银行应用程序等通常都有这样的要求，即消息系统可靠性附加了美元价值，当事情不起作用时，资金就会丢失。因此，消息持久性，HA /容错，故障转移都非常重要。如果成本不是问题，那么看看WebLogic，Websphere，SonicMQ或TIBCO等产品......它们价格昂贵，但都提供可靠的可靠性，企业支持并且在负载下表现良好。我使用过SonicMQ，它是一款非常棒的产品，速度快，性能可靠，但需要花费一条腿和一条腿。
希望它有所帮助...