Java - распределенное программирование, RMI?

Question

У меня тут куча проблем. Я стремлюсь создать структуру, позволяющую интегрировать различные модели симуляции трафика. Эта интеграция основана на совместном использовании соединений, затрат на соединение и транспортных средств между симуляциями.

Чтобы выполнить распределенное моделирование, я планирую иметь «координатора» (звездная топология). Все участвующие симуляции просто регистрируются в нем и общаются только с координатором. Координатор затем координирует выполнение различных задач между каждой имитацией.

Быстрый пример проблемы распределения, когда одна симуляция «отвечает» за определенные объекты, такие как дорога. А другой «отвечает» за другие дороги. Однако эти дороги взаимосвязаны (и, следовательно, нам необходима синхронизация между этими симуляциями, и мы должны иметь возможность обмениваться данными / вызывать методы удаленно).

Я посмотрел на RMI и думаю, что он может подойти для этой задачи. (Чтобы абстрагироваться от необходимости создания дисциплины сигнализации по проводам).

Это нормально? Проблема здесь заключается в том, что участники моделирования должны централизовать некоторые своего хранилища данных в «координаторе», чтобы обеспечить явную синхронизацию между моделированиями. Кроме того, для некоторых симуляций могут потребоваться компоненты или методы других симуляций. (Отсюда и идея использования RMI).

Мой основной подход заключается в том, чтобы «координатор» управлял гигантским реестром RMI. И каждое моделирование просто просматривает все в реестре, гарантируя, что правильные объекты используются на каждом этапе.

У кого-нибудь есть советы, как идти по этому пути?

Answer 1

Вы можете также проверить Hazelcast . Hazelcast - это транзакция с открытым исходным кодом, распределенная / секционированная реализация службы очереди, темы, карты, набора, списка, блокировки и исполнителя. С ним очень легко работать; просто добавьте hazelcast.jar в ваш путь к классам и начните кодировать. Почти не требуется настройка.

Если вы заинтересованы в выполнении задач Runnable, Callable в распределенном режиме, пожалуйста, ознакомьтесь с документацией службы распределенного исполнителя по адресу http://code.google.com/docreader/#p=hazelcast

Hazelcast выпущен под лицензией Apache, также доступна поддержка уровня предприятия.

Answer 2

Это нормально? ИМХО нет. И я скажу тебе почему. Но сначала я добавлю заявление об отказе от ответственности, что это сложная тема, поэтому любой ответ следует рассматривать как едва царапающий поверхность.

Во-первых, вместо того, чтобы повторяться, я укажу вам краткое изложение Java Grid / кластерных технологий , которое я написал некоторое время назад. Это в основном полный список.

Звездная топология является "естественной" для "наивной" (я не имею в виду это плохой способ) реализации, потому что точка-точка проста, а централизация логики контроллера ключа также проста. Однако он не отказоустойчив. Это приводит к проблемам с масштабируемостью и одним узким местом. Он вводит неэффективность связи (а именно точки взаимодействуют через двухступенчатый процесс через центр).

Что вам действительно нужно для этого, так это, вероятно, кластерное (а не сетка данных / вычислений) решение, и я бы посоветовал вам взглянуть на Терракота . В идеале вы бы посмотрели на Oracle Coherence , но это, без сомнения, дорого (по сравнению с бесплатным). Это фантастический продукт.

Эти два продукта можно использовать несколькими способами, но суть обоих заключается в том, чтобы рассматривать кэш как распределенную карту. Вы помещаете вещи, вынимаете вещи и запускаете код, который изменяет кэш. Согласованность (с которой я более знакома) в этом отношении фантастически хорошо масштабируется. Это более «серверные» продукты, хотя для настоящего кластера.

Если вы смотрите на более распределенную модель, то, возможно, вам стоит взглянуть на более основанный на SOA подход.

Answer 3

Посмотрите на http://www.terracotta.org/

это распределенная Java VM, поэтому ее преимущество в том, что кластеризованное приложение выглядит не иначе, чем стандартное приложение Java.

Я использовал его в приложениях, и скорость пока впечатляет.

Пол

Answer 4

Рассматривали ли вы использование подхода очереди сообщений? Вы можете использовать JMS для связи / координации задач и результатов среди набора серверов / узлов. Вы даже можете использовать Amazon SQS (Simple Queue Service: aws.amazon.com/sqs), и ваши серверы будут работать на EC2, что позволит вам увеличивать и уменьшать масштаб по мере необходимости.

Только мои 2 цента.

Answer 5

Так же, как дополнение к другим ответам, которые, насколько я видел, сосредоточены на грид и облачных вычислениях, вы должны заметить, что имитационные модели имеют одну уникальную характеристику: время симуляции.

При параллельном и синхронном запуске распределенных имитационных моделей я вижу два варианта:

• Когда каждая имитационная модель имеет свои собственные часы симуляции и список событий, они должны быть синхронизированы по сети.
• В качестве альтернативы могут быть единые часы симуляции и список событий, которые будут "отмечать время" для всех распределенных (под) моделей.

Первый вариант был тщательно исследован для архитектуры высокого уровня (HLA), см., Например, http://en.wikipedia.org/wiki/IEEE_1516 в качестве стартера.

Однако второй вариант кажется мне более простым и с меньшими накладными расходами.

Answer 6

GridGain - хорошая альтернатива. У них есть реализация map / lower с «прямой поддержкой API для разделения и агрегирования» и «сеанс распределенной задачи». Вы можете просмотреть их примеры и посмотреть, соответствуют ли некоторые из них вашим потребностям.

Answer 7

Ну, Jini, или, точнее, Javaspaces - хорошее место для простого подхода к проблеме. Javaspaces позволяет вам реализовать модель мастер-работник, где ваш мастер (координатор в вашем случае) записывает задачи в Javaspace, а рабочие запрашивают и обрабатывают эти задачи, записывая результаты обратно для мастера. Поскольку ваша проблема не смущает параллель, и ваши сотрудники должны синхронизировать / обмениваться данными, это добавит сложности вашему решению.

Использование Javaspaces добавит в вашу реализацию намного больше абстракции, чем при использовании обычного RMI (который используется платформой Jini внутри как проводной протокол по умолчанию).

Взгляните на эту статью от Солнца для вступления.

И Учебное пособие Джини Ньюмарха - довольно хорошее место для начала изучения Джини

Answer 8

Взгляните на JINI, он может быть вам полезен.