最高效 - 性能明智 - 用于JVM间通信

Question

我有一个Java应用程序，需要在不同进程之间进行通信。进程可以在相同的JVM或不同的JVM中运行，但可以在同一台机器上运行。

我的应用程序需要将“消息”提交给另一个进程（相同或不同的JVM）并忘记它。类似于IBM“MQ”之类的消息传递队列，但是简单，只使用内存，没有IO到硬盘以获得性能提升。

我不确定Performance prescriptive的最佳方法是什么。

• 我想知道RMI在性能方面是否有效，我认为它需要一些开销。
• 使用本地主机的TCP / IP套接字怎么样？

还有其他想法吗？

Answer 1

  

我想知道RMI在性能方面是否有效，我认为它需要一些开销。

RMI对其功能有效。它比大多数人需要的更多，但通常更快。您应该能够获得每秒1-3 K消息的顺序，延迟大约为1毫秒。

  

使用本地主机的TCP / IP套接字怎么样？

这总是一个选项，但使用普通的Java Serialization，这不会比使用RMI快得多。如何进行序列化和反序列化对于高性能至关重要。

---

一个重要的注意事项是，大部分时间都花在序列化和消息化消息上，大多数传输都无法帮助您，因此如果您想获得最佳性能，则必须考虑有效的编组策略。大多数传输协议仅对原始字节进行基准测试。

具有讽刺意味的是，如果您愿意使用磁盘，它可能比TCP或UDP（如ZeroMQ）更快，而且您可以获得“免费”的持久性。

这个库（我是作者）可以在进程间每秒执行数百万条消息，延迟低至100纳秒（比ZeroMQ低350倍）https://github.com/peter-lawrey/Java-Chronicle优点是< / p>

• 超快速序列化和反序列化，大多数传输基准都避免包括这一点，因为它通常需要比传输成本更长的时间。
• 是您可以在发送邮件后随时监控队列之间发生的情况。
• 重播所有消息。
• 生产者可以是您的消费者之前的任何数据量，可以优雅地处理微爆，最大可达磁盘空间大小。例如消费者可能落后于结核病。
• 支持通过TCP进行复制。
• 重新启动消费者或生产者很大程度上是透明的。

Answer 2

如果您正在开发服务器应用程序，请尝试考虑ZeroMQ。它具有很好的性能，允许更容易地构建进程间通信，允许构建异步API。

ZeroMQ通过InterProcess通信声明出色的表现。 Even better比TCP听起来很棒。我们正在考虑针对我们的集群架构的此解决方案。

Pieter Hintjens给出great answer以便在不同的Message Broker之间进行性能比较。