简体   繁体   English

Java - 分布式编程,RMI?

[英]Java - Distributed Programming, RMI?

I've got a doozy of a problem here. 我在这里遇到了一个问题。 I'm aiming to build a framework to allow for the integration of different traffic simulation models. 我的目标是构建一个框架,以允许集成不同的流量模拟模型。 This integration is based upon the sharing of link connectivities, link costs, and vehicles between simulations. 这种集成基于链接连接,链接成本和模拟之间的车辆的共享。

To make a distributed simulation, I plan to have a 'coordinator' (star topology). 为了进行分布式仿真,我计划建立一个“协调器”(星形拓扑)。 All participating simulations simply register with it, and talk only to the coordinator. 所有参与的模拟只需注册,并只与协调员交谈。 The coordinator then coordinates the execution of various tasks between each simulation. 然后协调员协调每次模拟之间各种任务的执行。

A quick example of a distribution problem, is when one simulation is 'in charge' of certain objects, like a road. 分布问题的一个快速示例是,当一个模拟“负责”某些对象(如道路)时。 And another is 'in charge' of other roads. 另一个是其他道路的“负责人”。 However, these roads are interconnected (and hence, we need synchronisation between these simulations, and need to be able to exchange data / invoke methods remotely). 但是,这些道路是相互连接的(因此,我们需要在这些模拟之间进行同步,并且需要能够远程交换数据/调用方法)。

I've had a look at RMI and am thinking it may be suited for this task. 我已经看过RMI了,我认为它可能适合这项任务。 (To abstract out having to create an over-wire signalling discipline). (以抽象出必须创建一个线上信令规则)。

Is this sane? 这样理智吗? The issue here, is that simulation participants need to centralize some of their data storage in the 'coordinator' to ensure explicit synchronisation between simulations. 这里的问题是模拟参与者需要将他们的一些数据存储集中在“协调器”中,以确保模拟之间的显式同步。 Furthermore, some simulations may require components or methods from other simulations. 此外,一些模拟可能需要来自其他模拟的组件或方法。 (Hence the idea of using RMI). (因此使用RMI的想法)。

My basic approach is to have the 'coordinator' run a giant RMI registry. 我的基本方法是让'协调员'运行一个巨大的RMI注册表。 And every simulation simply looks up everything in the registry, ensuring that the correct objects are used at each step. 每个模拟只需查找注册表中的所有内容,确保在每个步骤中使用正确的对象。

Anyone have any tips for heading down this path? 任何人都有任何关于沿着这条道路前进的提示

You may want to check out Hazelcast also. 您可能还想查看Hazelcast Hazelcast is an open source transactional, distributed/partitioned implementation of queue, topic, map, set, list, lock and executor service. Hazelcast是队列,主题,映射,集合,列表,锁定和执行程序服务的开源事务,分布式/分区实现。 It is super easy to work with; 它非常容易使用; just add hazelcast.jar into your classpath and start coding. 只需将hazelcast.jar添加到您的类路径中并开始编码。 Almost no configuration is required. 几乎不需要配置。

If you are interested in executing your Runnable, Callable tasks in a distributed fashion, then please check out Distributed Executor Service documentation at http://code.google.com/docreader/#p=hazelcast 如果您有兴趣以分布式方式执行Runnable,Callable任务,请查看http://code.google.com/docreader/#p=hazelcast上的 Distributed Executor Service文档。

Hazelcast is released under Apache license and enterprise grade support is also available. Hazelcast是在Apache许可下发布的,并且还提供企业级支持。

Is this sane? 这样理智吗? IMHO no. 恕我直言 And I'll tell you why. 我会告诉你原因。 But first I'll add the disclaimer that this is a complicated topic so any answer has to be viewed as barely scratching the surface. 但首先我要添加免责声明,这是一个复杂的话题,所以任何答案都必须被视为几乎没有表面。

First instead of repeating myself I'll point you to a summary of Java grid/cluster technologies that I wrote awhile ago. 首先,我将向您简要介绍一下我之前写过的Java网格/集群技术 Its a mostly complete list. 它是一个基本完整的清单。

The star topology is "natural" for a "naive" (I don't mean that in a bad way) implementation because point-to-point is simple and centralizing key controller logic is also simple. 星型拓扑对于“天真”(我并不意味着以一种糟糕的方式)实现是“自然的”,因为点对点很简单并且集中关键控制器逻辑也很简单。 It is however not fault-tolerant. 但它不是容错的。 It introduces scalability problems and a single bottleneck. 它引入了可伸缩性问题和单一瓶颈。 It introduces communication inefficiences (namely the points communicate via a two-step process through the center). 它引入了通信效率低下(即通过中心通过两步过程进行通信)。

What you really want for this is probably a cluster (rather than a data/compute grid) solution and I'd suggest you look at Terracotta . 你真正想要的是一个集群(而不是数据/计算网格)解决方案,我建议你看看Terracotta Ideally you'd look at Oracle Coherence but it's no doubt expensive (compared to free). 理想情况下,你会看到Oracle Coherence,但毫无疑问它是昂贵的(与免费相比)。 It is a fantastic product though. 虽然这是一个很棒的产品。

These two products can be used a number of ways but the core of both is to treat a cache like a distributed map. 这两种产品可以通过多种方式使用,但两者的核心是将缓存视为分布式地图。 You put things in, you take things out and you fire off code that alters the cache. 你把东西放进去,你把东西拿出来然后你就会发现改变缓存的代码。 Coherence (with which I'm more familiar) in this regards scales fantastically well. 在这方面的连贯性(我更熟悉)可以很好地扩展。 These are more "server" based products though for a true cluster. 对于真正的集群,这些是更“基于服务器”的产品。

If you're looking at a more distributed model then perhaps you should be looking at more of an SOA based approach. 如果您正在研究更分散的模型,那么您可能应该考虑更多基于SOA的方法。

Have a look at http://www.terracotta.org/ 看看http://www.terracotta.org/

its a distributed Java VM, so it has the advantage of being clustered application looks no different than a standard Java application. 它是一个分布式Java VM,因此它具有群集应用程序外观与标准Java应用程序没有区别的优势。

I have used it in applications and the speed is very impressive so far. 我已经在应用程序中使用它,到目前为止速度非常令人印象深刻。

Paul 保罗

Have you considered using a message queue approach? 您是否考虑过使用消息队列方法? You could use JMS to communicate/coordinate tasks and results among a set of servers/nodes. 您可以使用JMS在一组服务器/节点之间通信/协调任务和结果。 You could even use Amazon's SQS (Simple Queue Service: aws.amazon.com/sqs) and have your servers running on EC2 to allow you to scale up and down as required. 您甚至可以使用Amazon的SQS(简单队列服务:aws.amazon.com/sqs)并让您的服务器在EC2上运行,以允许您根据需要进行扩展和缩小。

Just my 2 cents. 只需2美分。

看看JINI,它可能对你有用。

Well, Jini, or more specifically Javaspaces is a good place to start for a simple approach to the problem. 好吧,Jini,或者更具体地说Javaspaces是一个开始简单解决问题的好地方。 Javaspaces lets you implement a master-worker model, where your master (coordinator in your case) writes tasks to the Javaspace, and the workers query for and process those tasks, writing the results back for the master. Javaspaces允许您实现主工作者模型,其中主服务器(在您的情况下为协调器)将任务写入Javaspace,工作人员查询并处理这些任务,并为主服务器写回结果。 Since your problem is not embarrassingly parallel, and your workers need to synchronize/exchanging data, this will add some complexity to your solution. 由于您的问题不是令人尴尬的并行,并且您的工作人员需要同步/交换数据,这将为您的解决方案增加一些复杂性。

Using Javaspaces will add a whole lot more abstraction to your implementation that using plain RMI (which is used by the Jini framework internally as the default "wire protocol"). 使用Javaspaces将为您的实现添加更多的抽象,使用普通的RMI(Jini框架在内部使用它作为默认的“有线协议”)。

Have a look at this article from sun for an intro. 看一下sun的这篇文章介绍。

And Jan Newmarch's Jini Tutorial is a pretty good place to start learning Jini Jan Newmarch的Jini教程是开始学习Jini的好地方

GridGain is a good alternative. GridGain是一个不错的选择。 They have a map/reduce implementation with "direct API support for split and aggregation" and "distributed task session". 它们具有map / reduce实现,具有“对分离和聚合的直接API支持”和“分布式任务会话”。 You can browse their examples and see if some of them fits with your needs. 您可以浏览他们的示例 ,看看其中一些是否符合您的需求。

Just as an addition to the other answers which as far as I have seen all focus on grid and cloud computing, you should notice that simulation models have one unique characteristic: simulation time. 正如我所看到的所有关注于网格和云计算的其他答案的补充一样,您应该注意到仿真模型具有一个独特的特征:仿真时间。

When running distributed simulation models in parallel and synchronized then I see two options: 当并行运行分布式仿真模型并同步时,我看到两个选项:

  • When each simulation model has its own simulation clock and event list then these should be synchronized over the network. 当每个仿真模型都有自己的仿真时钟和事件列表时,这些应该通过网络进行同步。
  • Alternatively there could be a single simulation clock and event list which will "tick the time" for all distributed (sub) models. 或者,可以存在单个模拟时钟和事件列表,其将为所有分布式(子)模型“勾选时间”。

The first option has been extensively researched for the High Level Architecture (HLA) see for example http://en.wikipedia.org/wiki/IEEE_1516 as a starter. 第一个选项已经针对高级架构(HLA)进行了广泛研究,例如http://en.wikipedia.org/wiki/IEEE_1516作为入门者。

However the second option seems more simple and with less overhead to me. 然而,第二个选项看起来更简单,而且开销更少。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM