Java — распределенное программирование, RMI?
https://stackoverflow.com/questions/506911
-
21-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
У меня тут чудная проблема.Я стремлюсь создать структуру, позволяющую интегрировать различные модели моделирования дорожного движения.Эта интеграция основана на совместном использовании соединений, затрат на соединение и транспортных средств между моделями.
Чтобы провести распределенное моделирование, я планирую иметь «координатора» (топология «звезда»).Все участвующие симуляции просто регистрируются в нем и общаются только с координатором.Затем координатор координирует выполнение различных задач между каждым моделированием.
Ярким примером проблемы распределения является ситуация, когда одна симуляция «отвечает» за определенные объекты, например за дорогу.А другой «отвечает» за другие дороги.Однако эти дороги взаимосвязаны (и, следовательно, нам нужна синхронизация между этими симуляциями и возможность удаленно обмениваться данными/вызывать методы).
Я посмотрел на RMI и думаю, что он подойдет для этой задачи.(Чтобы абстрагироваться от необходимости создания дисциплины беспроводной сигнализации).
Это разумно?Проблема здесь в том, что участникам моделирования необходимо централизовать некоторый хранения их данных в «координаторе», чтобы обеспечить явную синхронизацию между симуляциями.Более того, для некоторых симуляций могут потребоваться компоненты или методы из других симуляций.(Отсюда и идея использования RMI).
Мой основной подход заключается в том, чтобы «координатор» управлял огромным реестром RMI.И каждая симуляция просто просматривает все в реестре, гарантируя, что на каждом этапе используются правильные объекты.
У кого-нибудь есть какие-нибудь советы, как идти по этому пути?
Решение
Вы можете проверить Хейзелкаст также.Hazelcast — это транзакционная, распределенная/разделенная реализация с открытым исходным кодом службы очередей, тем, карт, наборов, списков, блокировок и исполнителей.С ним очень легко работать;просто добавьте hazelcast.jar в свой путь к классам и начните кодировать.Практически не требуется настройка.
Если вы заинтересованы в выполнении задач Runnable и Callable распределенным образом, ознакомьтесь с документацией по Distributed Executor Service по адресу http://code.google.com/docreader/#p=hazelcast
Хейзелкаст выпускается под лицензией Apache, также доступна поддержка корпоративного уровня.
Другие советы
Это разумно?ИМХО нет.И я скажу вам, почему.Но сначала я добавлю оговорку о том, что это сложная тема, поэтому любой ответ следует рассматривать как поверхностное.
Сначала вместо того, чтобы повторяться, я укажу вам на краткое изложение технологий сетки/кластера Java что я написал некоторое время назад.Это практически полный список.
Топология «звезда» является «естественной» для «наивной» (я не имею в виду это в плохом смысле) реализации, поскольку соединение «точка-точка» является простым, а централизация логики ключевого контроллера также проста.Однако он не является отказоустойчивым.Это создает проблемы масштабируемости и одно узкое место.Это приводит к неэффективности коммуникации (а именно, точки взаимодействуют через двухэтапный процесс через центр).
То, что вам действительно нужно для этого, вероятно, является кластерным решением (а не сеткой данных/вычислений), и я бы посоветовал вам посмотреть Терракота.В идеале вы бы посмотрели Когерентность Oracle но это, без сомнения, дорого (по сравнению с бесплатным).Однако это фантастический продукт.
Эти два продукта можно использовать разными способами, но суть обоих заключается в том, чтобы рассматривать кэш как распределенную карту.Вы кладете что-то, вынимаете что-то и запускаете код, который изменяет кеш.Согласованность (с которой я более знаком) в этом отношении фантастически хорошо масштабируется.Однако для настоящего кластера это скорее «серверные» продукты.
Если вы ищете более распределенную модель, возможно, вам следует обратить внимание на подход, основанный на SOA.
Посмотри на http://www.terracotta.org/
это распределенная виртуальная машина Java, поэтому ее преимущество состоит в том, что кластерное приложение ничем не отличается от стандартного приложения Java.
Я использовал его в приложениях, и скорость пока очень впечатляет.
Павел
Рассматривали ли вы возможность использования очереди сообщений?Вы можете использовать JMS для передачи/координации задач и результатов между набором серверов/узлов.Вы даже можете использовать Amazon SQS (Simple Queue Service:aws.amazon.com/sqs), и ваши серверы будут работать на EC2, чтобы вы могли увеличивать и уменьшать масштаб по мере необходимости.
Просто мои 2 цента.
Взгляните на JINI, возможно, он вам пригодится.
Что ж, Jini, или, точнее, Javaspaces, — хорошее место для начала простого подхода к проблеме.Javaspaces позволяет вам реализовать модель «главный-работник», где ваш мастер (в вашем случае координатор) записывает задачи в Javaspace, а рабочие запрашивают и обрабатывают эти задачи, записывая результаты обратно мастеру.Поскольку ваша проблема не является слишком параллельной, и вашим работникам необходимо синхронизировать/обменять данные, это добавит некоторую сложность вашему решению.
Использование Javaspaces добавит к вашей реализации гораздо больше абстракции, чем использование простого RMI (который используется внутри среды Jini как «проводной протокол» по умолчанию).
Посмотри на это статья от солнца для вступления.
И Ян Ньюмарч Джини Учебник это довольно хорошее место для начала изучения Джини
В дополнение к другим ответам, которые, насколько я видел, сосредоточены на сетевых и облачных вычислениях, вы должны заметить, что имитационные модели имеют одну уникальную характеристику:время моделирования.
При параллельном и синхронизированном запуске распределенных имитационных моделей я вижу два варианта:
- Если каждая имитационная модель имеет свои собственные часы и список событий, их следует синхронизировать по сети.
- В качестве альтернативы могут быть единые часы моделирования и список событий, которые будут «отсчитывать время» для всех распределенных (под)моделей.
Первый вариант был тщательно исследован для архитектуры высокого уровня (HLA), см., например. http://en.wikipedia.org/wiki/IEEE_1516 в качестве стартера.
Однако второй вариант мне кажется более простым и с меньшими накладными расходами.
GridGain это хорошая альтернатива.У них есть реализация карты/сокращения с «прямой поддержкой API для разделения и агрегации» и «сеансом распределенных задач».Вы можете просмотреть их примеры и посмотрите, соответствуют ли некоторые из них вашим потребностям.
