Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Есть проект на гитхабе?
Русский для вас не родной, я угадал? Сколько лет занимаетесь?
Думаю это будет для меня толчком начать писать на Scala ;)
На akka.io/docs кстати отлично разобраны и некоторые моменты самой Scala. Я по ней изучал и язык, и фреймворк.
Читал с мыслью, что эти Scala+Akka вместе весьма напоминают Go с его goroutines и chanels.
Правда, там всё нужно делать вручную (это я про ваш пример с разруливанием нагрузки через конфиг).
Что, впрочем, не так уж сложно, если вспомнить о средствах стандартной библиотеки.
Правда, там всё нужно делать вручную (это я про ваш пример с разруливанием нагрузки через конфиг).
Что, впрочем, не так уж сложно, если вспомнить о средствах стандартной библиотеки.
Сейчас на Go пишу (переписываю=) подобие игрового сервера, довольно просто решаются задачи, которые в Java требовали держать в голове большую кучу информации вместе.
Да, в этом плане у Go есть как плюсы, так и минусы.
Напишу, если доведу до вменяемого состояния.
Использовать Circuit для того, что я сейчас делаю — это как стрелять из пушки по воробьям, внушительно, но затратно (в плане времени, которое мне будет нужно чтобы с ним разобраться).
Мне почти хватает стандартной библиотеки, а насчет нагрузок — текущий сервер на java вполне себе работает на минимальном виртуальном сервере.
С вопросом вам в личку отписал.
Использовать Circuit для того, что я сейчас делаю — это как стрелять из пушки по воробьям, внушительно, но затратно (в плане времени, которое мне будет нужно чтобы с ним разобраться).
Мне почти хватает стандартной библиотеки, а насчет нагрузок — текущий сервер на java вполне себе работает на минимальном виртуальном сервере.
С вопросом вам в личку отписал.
Спасибо ;)
На самом деле, акторная модель и модель CSP (которая как раз используется в Go) в некотором роде противоположны :)
В акторной модели основные объекты — это акторы, которые посылают друг другу сообщения с данными. Сообщения могут отправляться от любого актора любому, главное — знать его идентификатор. Акторы «работают» только тогда, когда обрабатывают очередное сообщение.
В CSP основной объект — это легковесный процесс. Процессы обмениваются данными с помощью каналов, которые заранее устанавливаются между теми процессами, которым нужно будет общаться. Данные пересылаются только через каналы, процессу неизвестно, что находится по другую его сторону. Процессы работают всегда, за исключением того времени, которое они проводят в ожидании сообщений из каналов.
В акторной модели основные объекты — это акторы, которые посылают друг другу сообщения с данными. Сообщения могут отправляться от любого актора любому, главное — знать его идентификатор. Акторы «работают» только тогда, когда обрабатывают очередное сообщение.
В CSP основной объект — это легковесный процесс. Процессы обмениваются данными с помощью каналов, которые заранее устанавливаются между теми процессами, которым нужно будет общаться. Данные пересылаются только через каналы, процессу неизвестно, что находится по другую его сторону. Процессы работают всегда, за исключением того времени, которое они проводят в ожидании сообщений из каналов.
В теории я не силен, но согласитесь, сходство присутствует.
Ежели желаете — через один chan можно передавать сообщения разных типов, проверяя тип при получении при помощи type asserting.
Может я не до конца проникся концепцией акторов, но противоположностью к горутинам как-то сложно их обозвать.
Акторы «работают» только тогда, когда обрабатывают очередное сообщение.Точно так же будет себя вести, например, такая горутина:
Скрытый текст
go func () {
select {
case recv:=<-someChan: //do something
case recv:=<-someOther: //do something else
}
}()
Ежели желаете — через один chan можно передавать сообщения разных типов, проверяя тип при получении при помощи type asserting.
Может я не до конца проникся концепцией акторов, но противоположностью к горутинам как-то сложно их обозвать.
По-моему, на CSP вполне можно реализовать модель акторов, так что я тоже бы не называл эти понятия противоположными.
Поэтому я и сказал — в некотором смысле. А именно — модель обмена сообщениями у них различна.
Но в целом, конечно, и то и другое — это модели concurrency, и акторы в некотором роде находятся на более высоком уровне абстракции (действительно, акторов можно сделать через CSP, а наоборот — я сомневаюсь), поэтому различие довольно расплывчато.
Но в целом, конечно, и то и другое — это модели concurrency, и акторы в некотором роде находятся на более высоком уровне абстракции (действительно, акторов можно сделать через CSP, а наоборот — я сомневаюсь), поэтому различие довольно расплывчато.
думаю написать веб сервер для приема сообщений и отправки их в kafka. пока смотрю в сторону spray, может у кого-нибудь есть опыт? есть смысл?
Я со spray столкнулся со стороны клиента, сейчас активно разглядываю.
Мне пока не хватает двух вещей:
— нормальной поддержки cookies (как я понял pipeline неизменяемый), но этот state можно попытаться раскидать по отдельным акторам, в одном идет авторизация (получение авторизационной куки), во втором — уже pipeline с
— пока не нашел нормального способа подсунуть
Может кто-нибудь ещё расскажет о подводных камнях? ,)
Мне пока не хватает двух вещей:
— нормальной поддержки cookies (как я понял pipeline неизменяемый), но этот state можно попытаться раскидать по отдельным акторам, в одном идет авторизация (получение авторизационной куки), во втором — уже pipeline с
addHeader;— пока не нашел нормального способа подсунуть
SSLSocketFactory, но, может, удастся подсунуть через SSLContext (мне это нужно для расширения TLS SNI, оно же server_name extension, RFC3546#3.1).Может кто-нибудь ещё расскажет о подводных камнях? ,)
Я что-то не понял рисунка. Сессии являются инстансами FrontActor, или сессии коммуницируют с Location-ами через единый FrontActor?
Все связи на картинке являются условными. Мы же говорим про Акка, а это значит, что любой актор может послать сообщение любому актору.
Поэтому фраза «коммуницируют с Location-ами через» имеет мало смысла.
Задача FrontActor только обработка соединений, он принимает новый коннект, создает для его обработки новый актор (сессию) и все. Жестких связей нет. Location может просто послать сообщение сессии безо всяких посредников.
Поэтому фраза «коммуницируют с Location-ами через» имеет мало смысла.
Задача FrontActor только обработка соединений, он принимает новый коннект, создает для его обработки новый актор (сессию) и все. Жестких связей нет. Location может просто послать сообщение сессии безо всяких посредников.
Я хотел бы вбросить немного о недостатках Akka, если позволите.
Главная проблема Akka (впрочем, может уже пофиксили с помощью макросов или еще как?) заключается в том, что внутри актора ты не можешь блокировать поток. Поэтому приходится делать всякие извращения типа передачи стейта в сообщении и потом передачи стейта обратно снова в сообщении (то есть нельзя сделать аналог gen_server:call как в Erlang, без блокирования, только gen_server:cast или с блокированием треда), поднимать отдельные шедулеры и крутить на них акторы с блокирующими вызовами и так далее. В уже упомянутом Erlang такой проблемы нет, обо все позаботиться ВМ. В Cloud Haskell тоже, потому что у Haskell встроенные легковесные процессы (еще легче чем в Erlang, кстати), и встроенный неблокирующий IO. Ну и как в Haskell, так и в Erlang данные немутабельные, в Scala это не всегда так, соответственно есть пространство для простреливания ног.
Но учитывая, что под JVM, по всей видимости, ничего лучше нет, в целом, нормальное решение, несмотря на названные шороховатости.
Алсо — про Akka мне кажется всем кому интересно все уже знают. Вы лучше конкретно про сервер раскажите и (!) проблемы, с которыми вы столкнулись при его реализации.
Главная проблема Akka (впрочем, может уже пофиксили с помощью макросов или еще как?) заключается в том, что внутри актора ты не можешь блокировать поток. Поэтому приходится делать всякие извращения типа передачи стейта в сообщении и потом передачи стейта обратно снова в сообщении (то есть нельзя сделать аналог gen_server:call как в Erlang, без блокирования, только gen_server:cast или с блокированием треда), поднимать отдельные шедулеры и крутить на них акторы с блокирующими вызовами и так далее. В уже упомянутом Erlang такой проблемы нет, обо все позаботиться ВМ. В Cloud Haskell тоже, потому что у Haskell встроенные легковесные процессы (еще легче чем в Erlang, кстати), и встроенный неблокирующий IO. Ну и как в Haskell, так и в Erlang данные немутабельные, в Scala это не всегда так, соответственно есть пространство для простреливания ног.
Но учитывая, что под JVM, по всей видимости, ничего лучше нет, в целом, нормальное решение, несмотря на названные шороховатости.
Алсо — про Akka мне кажется всем кому интересно все уже знают. Вы лучше конкретно про сервер раскажите и (!) проблемы, с которыми вы столкнулись при его реализации.
Есть такая проблема. В Akka ее не пофиксят ничем. Это ограничение JVM. Да, там нет честных green threads.
И по сути, под капотом все это крутится на пуле потоков, откуда и следуют эти особенности.
Но Akka это лучшее что я видел для JVM.
Кто-то знает, а многие нет. Да и статей по ней, на хабре, практически нет.
И по сути, под капотом все это крутится на пуле потоков, откуда и следуют эти особенности.
Но Akka это лучшее что я видел для JVM.
Алсо — про Akka мне кажется всем кому интересно все уже знают.
Кто-то знает, а многие нет. Да и статей по ней, на хабре, практически нет.
Ну и как в Haskell, так и в Erlang данные немутабельные, в Scala это не всегда так, соответственно есть пространство для простреливания ног.Это уже не относится к акка, да и нельзя это назвать недостатком. Явных подталкиваний к использованию изменчивых структур в скале нет, скорее наоборот. То что программист пойдет стряхнет пыль с опасного инструмента и покалечится, это уж его личная неуклюжесть. Эти структуры существуют специально, потому что иногда с ними либо можно сделать проще, либо можно сделать более быстрое решение.
С возвращением, solver
Скажи, а как лучше реализовать взаимодействие между «комнатами»?
Любой может послать сообщение любому. То есть, проблемы общих ресурсов в данной модели нет?
Скажи, а как лучше реализовать взаимодействие между «комнатами»?
Любой может послать сообщение любому. То есть, проблемы общих ресурсов в данной модели нет?
Взаимодействие между комнатами стандартное, через сообщения.
Да, проблемы общих ресурсов тут нет. Хотя ее можно создать искусственно, выстрелы по ногам никуда не денутся).
Да, проблемы общих ресурсов тут нет. Хотя ее можно создать искусственно, выстрелы по ногам никуда не денутся).
То есть, у нас есть актор отвечающий за коллекцию. И если два других актора обращаются к коллекции одновременно (например, удалить элемент), их взаимодействие определено на уровне системы?
Что значит «их взаимодействие определено на уровне системы»?
Как в Akka не знаю, в Erlang: Пусть есть акторы A B и C. Коллекцию хранит C. A и B отправят каждый по сообщению C «измени что то», сообщения попадут в мейлбокс C. C прочитает первое сообщение — изменит коллекцию, потом прочитает второе сообщение — ещё раз изменит коллекцию.
Возможно после изменения отправит в ответ сообщение «я изменил, вот новое значение» — тут уж как запрограммируешь.
Возможно после изменения отправит в ответ сообщение «я изменил, вот новое значение» — тут уж как запрограммируешь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Игровой сервер на Scala + Akka