基于Java有什么好的主从通信机制？
我正在创建一个 Java 应用程序，该应用程序需要 JVM 之间的主从通信，这些 JVM 可能驻留在同一台物理机器上。将有一个“主”服务器在 Java EE 应用程序服务器（即 JBoss）内运行，该服务器将有“从”客户端连接到它并动态注册自身以进行通信（即主服务器不会知道该服务器的 IP 地址/端口）。从站，因此无法提前配置）。主服务器充当控制器，向从服务器分配工作，从服务器将定期响应通知，因此将存在双向通信。
我最初考虑的是基于 RPC 的系统，其中每一端都是一个服务器，但它可能会变得复杂，所以我更喜欢一种有开放套接字并且它们来回通信的机制。
我正在寻找一种低延迟的通信机制，其中消息主要是原始类型，因此不需要严格的序列化。以下是我所看到的内容：
- RMI
- JMS：内置于 Java，“从属”客户端将连接到应用程序服务器中现有的 ConnectionFactory。
- JAX-WS/RS：主服务器和从服务器都是公开 RPC 接口以进行双向通信的服务器。
- JGroups/Hazelcast：使用共享的分布式数据结构来促进通信。
- Memcached/MongoDB：使用它们作为“队列”来促进通信，尽管客户端必须进行轮询，因此会出现一些延迟。
- Thrift：这似乎确实保持了持久连接，但不确定如何将 Thrift 服务器集成/嵌入到 JBoss
- WebSocket/Raw Socket 中：这可以工作，但需要比我想要的更多的自定义代码。
我还缺少什么技术吗？
编辑：还查看：
- JMX：让客户端连接到 JBoss 的 JMX 服务器并接收双向通信的 JMX 通知。
I'm creating a Java application that requires master-slave communication between JVMs, possibly residing on the same physical machine. There will be a "master" server running inside a Java EE application server (i.e. JBoss) that will have "slave" clients connect to it and dynamically register itself for communication (that is the master will not know the IP addresses/ports of the slaves so cannot be configured in advance). The master server acts as a controller that will dole work out to the slaves and the slaves will periodically respond with notifications, so there would be bi-directional communication.
I was originally thinking of RPC-based systems where each side would be a server, but it could get complicated, so I'd prefer a mechanism where there's an open socket and they talk back and forth.
I'm looking for a communication mechanism that would be low-latency where the messages would be mostly primitive types, so no serious serialization is necessary. Here's what I've looked at:
- RMI
- JMS: Built-in to Java, the "slave" clients would connect to the existing ConnectionFactory in the application server.
- JAX-WS/RS: Both master and slave would be servers exposing an RPC interface for bi-directional communication.
- JGroups/Hazelcast: Use shared distributed data structures to facilitate communication.
- Memcached/MongoDB: Use these as "queues" to facilitate communication, though the clients would have to poll so there would be some latency.
- Thrift: This does seem to keep a persistent connection, but not sure how to integrate/embed a Thrift server into JBoss
- WebSocket/Raw Socket: This would work, but require a lot more custom code than I'd like.
Is there any technology I'm missing?
Edit: Also looked at:
- JMX: Have the client connect to JBoss' JMX server and receive JMX notifications for bidirectional comms.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
好吧，如果您正在寻找基于 Java 的东西，我建议 JMS。它具有您正在寻找的所有功能以及强大的应用程序服务器（例如 JBoss）。然而，另一种不完全基于 java 且不使用队列的选项是使用 HTTP 协议和 JAXB（RESTful Web 服务）。这是双方之间一种非常轻松的沟通方式。您的对象将使用 JAXB 转换为 XML，并传输到另一端，然后在收到它后将其转换回对象。
Well, I suggest JMS if you are looking for something which is based on Java. It has all the features that you are looking for plus a strong application server such as JBoss. However, another option which is not completely java based and is not using Queues would be using using HTTP protocol and JAXB (RESTful Web services). This is a very light way of communicating between two sides. Your objects would be transformed to XML by using JAXB, and would be transferred to the other side, and then you cast it back to object once you receive it.
另外两个选项：
Zookeeper (http://hadoop.apache.org/zookeeper/) Haven'没用过，但在这里听起来很合适。
RabbitMQ (http://www.rabbitmq.com/) 低延迟消息队列。这里有很大的灵活性。
Two more options:
Zookeeper (http://hadoop.apache.org/zookeeper/) Haven't used it, but sounds appropriate here.
RabbitMQ (http://www.rabbitmq.com/) Low latency message queueing. Lots of flexibility here.
老实说，我会坚持使用 JMS。您有一个队列，您的从属设备可以从中取出消息，并有一个队列可以将消息放回其中。您可以直接在信封上设置有关谁处理每条消息（用于记帐）的属性。您可以通过许多 J2EE 提供商（glassfish、jboss）获得持久性。
另外，您可以使用它轻松迁移到多服务器分布式 JVM，无需额外编程。
然而，在某些情况下，它可能不符合“低延迟”的定义。
Honestly, I would just stick with JMS. You have one queue your slaves can take messages out of, and one queue that they put them back into. You can set properties about who processed each message (for accounting) right on the envelope. You get persistence with many J2EE providers (glassfish, jboss).
Plus, you can easily move to multiple-server distributed JVM with it with no extra programming.
However, it may not fit the definition of "low-latency" in some cases.
如果您正在寻求性能并且您的两个应用程序都是 java，并且中间没有防火墙，那么您可以立即排除所有基于 XML 的协议。
如果通信是同步的（主站等待从站完成作业），则使用 RMI，否则使用 JMS。
您还可以直接使用 TCP 以获得最大性能。
如果有许多从站接收到相同的消息，您可以查看组通信工具包，例如 JGroups 或 Spread（更快，但不是 100% java）。
最终，您可能会发现其他人已经构建了您想要构建的内容。看看Gridgain。
If you're looking for performance and both of your applications are java, without a firewall in between, then you can immediately exclude all the XML based protocols.
If the communication is synchronous (master waits for the slave to complete the job), then use RMI, otherwise JMS.
You can also use TCP directly for maximum performance.
If there are many slaves that receive the same message, you could look into group communication toolkits like JGroups or Spread (faster but not 100% java).
Ultimately, you might find that other people have already build what you're trying to build. Take a look at Gridgain.
您还可以检查骡子。我觉得它是您问题的完美解决方案。
You can also check Mule. I feel that It is perfect solution for your problem.
我们有一个类似的应用程序，我们只是在 JBoss 上使用 Servlet，“从属”以计时器驱动的方式命中它。这没问题，但对于低延迟来说并不是最佳选择。
我们现在正在研究 Netty。您可以使用任何您想使用的协议。我们可能会使用 HTTP 和 JAXB。我想这可以归类为“WebSocket/Raw Socket”，但它比使用原始套接字要好得多。
We have a similar application, and we just used Servlet on JBoss with "slaves" hitting it in a timer driven manner. This is okay, but not optimal for low latency.
We are now looking into Netty. You can use whatever protocol you want to use.. We'll probably use HTTP and JAXB. I guess this could be categorized as "WebSocket/Raw Socket", but it's much better than using a raw one..
您可能想看看 Activatable。如果工作完成时从站做出响应，那么在这种情况下 rmi 和 Activatable 可能是一个很好的解决方案。如果您在控制器上使用 rmiregistry，则所有从站都可以轻松地向控制器注册自己，并且可以在需要时激活这些从站。
You might want to have a look at Activatable. If the slaves are responding when the work is complete then rmi and Activatable could be a good solution in this instance. If you use the rmiregistry on the controller, then all of the slaves can register themselves with the controller easily, and these can be activated when required.
根据您的要求，您可能会发现原始套接字比其他方法具有更少的代码。它肯定会有最低的延迟。您可以将环回时间缩短至大约 20 微秒。
您的要求越多，您就越有可能需要高级解决方案。然而，如果您想要的只是轻量级的东西，原始套接字可能是最简单的。
Depending on your requirements you might find that Raw Socket has less code than other approaches. It will certainly have the lowest latency. You can get it down to about 20 micro-seconds over loop back.
The more requirements you have the more likely you want a high level solution. However if all you want is something lightweight, raw sockets can be the simplest.
对于 Thrift，您可以使用 TServlet 作为 Thrift 服务的入口点。不过，您所描述的听起来更像是一个需要使用 activemq 或 Zookeeper 解决的问题。
For thrift you can use TServlet as the entry point for your Thrift service. What you described though sounds like more of a problem to be solved with activemq or zookeeper.
WebSockets 将帮助您在 Web 服务器和客户端之间进行通信，而不是在两个 JVM 之间进行通信。如果这确实是您想要的，http://fermiframework.org 提供了 java 到 JavaScript（服务器到客户端）RMI。
WebSockets will help you with communication between Web server and client, not between two JVMs. If that's in fact what you want, http://fermiframework.org provides a java to JavaScript (server to client) RMI.
您还可以查看 Redisson 项目，它具有发布/订阅和其他满足您需求的共享分布式数据结构。
You can also take a look at Redisson project it has publish/subscribe and other shared distributed data structures for you needs.