как делать актеров (erlang) в Java?

Я работаю над финансовыми приложениями на Java, и добиться правильного параллелизма очень сложно. Предполагается, что Erlang и модель акторов хорошо подходят для массово параллельных приложений, но я не могу понять, как это сделать на Java. Я знаю, что есть такие библиотеки, как Jetlang, FunctionalJava, kilim и т. Д., Но обычно они не выходят за рамки упрощенных примеров.

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

Я создаю обычный объект Java с методами, которые изменяют состояние. Вместо того, чтобы позволять этим методам напрямую изменять состояние, я помещаю их параметры (путем преобразования их в командный объект) в очередь fifo (почтовый ящик erlang) и в метод response (), который обрабатывает эту очередь. Таким образом, все обновления должны проходить через одну очередь, а к методу response () можно обращаться только по одному обновлению за раз. Теоретически это должно избавить меня от необходимости блокировать или синхронизировать этот метод.

Однако эта очередь в основном является очередью производителя / потребителя, что означает, что это очередь блокировки. Блокирование очень плохо сказывается на масштабируемости. Кроме того, наличие единой очереди означает, что все мои объекты команд обновления (разных типов) выходят из очереди с каким-то чрезмерно универсальным супертипом (например, Object), и я должен вернуть их к правильному типу и позволить response () обрабатывать их .

Как только этот акторизованный объект производит вывод, который будет потреблен другим таким объектом, я прохожу через тот же процесс. Другими словами, я изменил модель программирования с объектно-ориентированной модели с методами, возвращающими результаты, на своего рода продолжение, передающее кошмар, когда все мои методы становятся асинхронными.

Есть идеи, как я могу подойти к этому?


person Shahbaz    schedule 27.04.2009    source источник


Ответы (6)


Воспользуйтесь одной из замечательных библиотек Actors, появившихся недавно. Алекс Миллер написал хорошую статью из двух частей для Javaworld об Актерах.

Мне также очень нравится Гильдия актеров.

person GaryF    schedule 27.04.2009
comment
К вашему сведению, согласно веб-сайту Гильдии актеров, похоже, что проект больше не поддерживается. - person Garrett Bluma; 04.04.2013

Совсем недавно akka предоставляет структуру акторов для Scala и основывается на Erlang.

person manku    schedule 25.06.2011
comment
Спасибо. Это именно то, что я искал. Это особенность Erlang в Java. - person comonad; 04.08.2014

Вы также можете изучить акторов Scala (вы можете рассматривать их как своего рода библиотеку Java), см., Например: Наполненное руководство Java-разработчика по Scala: погрузитесь глубже в параллелизм Scala.

person Fabian Steeg    schedule 27.04.2009

Вы также можете взглянуть на esper, который не настолько низкоуровневый, как структуры акторов, являющиеся Как уже упоминалось, это больше похоже на обобщенную систему обработки событий, которую вы построили бы на основе структуры акторов. Очень зрелый, полный и, как мне кажется, разработанный для обработки сложных событий в финансовых транзакциях.

person Steve B.    schedule 27.12.2011

Kontraktor - это новая библиотека актеров, разработанная для java 8. https://github.com/RuedigerMoeller/kontraktor

person R.Moeller    schedule 30.07.2015

Вы можете рассмотреть другой вариант, а именно Netty вместе с LMAX Disruptor, оба они написаны на чистом java. Netty - это асинхронная среда сетевых приложений, управляемая событиями, для быстрой разработки обслуживаемых высокопроизводительных протокольных серверов и клиентов.

введите описание изображения здесь

Что такое Disruptor?

LMAX стремится стать самой быстрой торговой платформой в мире. Ясно, что для этого нам нужно было сделать что-то особенное, чтобы добиться очень низкой задержки и высокой пропускной способности с нашей платформой Java. Тестирование производительности показало, что использование очередей для передачи данных между этапами системы приводит к задержкам, поэтому мы сосредоточились на оптимизации этой области.

Disruptor - это результат наших исследований и испытаний. Мы обнаружили, что пропуски кеша на уровне ЦП и блокировки, требующие арбитража ядра, являются чрезвычайно дорогостоящими, поэтому мы создали фреймворк, который имеет «механическое сочувствие» к оборудованию, на котором он работает, и который не требует блокировок ...

(взято из https://lmax-exchange.github.io/disruptor/)

person Humoyun Ahmad    schedule 31.07.2015