Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
А что такое «просто сервис»?
Мы же используем Akka. У нас «все актор».
Ну профит не в том, что можно в поток выделить. А в том, что этот момент очень гибко конфигурируется.
Можно поток, можно пул потоков, можно вообще отдельную машину по сети. Все через конфиг. Без изменения самого актора.
Мы же используем Akka. У нас «все актор».
Ну профит не в том, что можно в поток выделить. А в том, что этот момент очень гибко конфигурируется.
Можно поток, можно пул потоков, можно вообще отдельную машину по сети. Все через конфиг. Без изменения самого актора.
Ну собственно сейчас так и есть. Каждый сервис это просто класс с методами.
В простых случаях профит не всегда очевиден. Я об этом писал.
Надо просто написать приложение на Akka, что бы понять всю прелесть этого подхода.
Ибо «можно конфигурить во вне» всего лишь один маленький момент из всей Akka.
Как вы будете, например, пул потоков размещать прозрачно на соседней машине в сети?
В простых случаях профит не всегда очевиден. Я об этом писал.
Надо просто написать приложение на Akka, что бы понять всю прелесть этого подхода.
Ибо «можно конфигурить во вне» всего лишь один маленький момент из всей Akka.
Как вы будете, например, пул потоков размещать прозрачно на соседней машине в сети?
BTW, обычно под сервисом подразумевается не просто класс с методами, а класс, не имеющий своего внутреннего состояния.
Касательно баз данных в АККА. Можно использовать драйверы, которые полностью асинхронные. Тогда не будет проблем с блокировкой потоков. К примеру для MongoDB это ReactiveMongo.
А для всяких SQL что-нибудь посоветовать можете? Желательно, работающее поверх jdbc.
Есть postgreql-async и mysql-async, например: github.com/mauricio/postgresql-async
Также, если не хочется работать с ними напрямую, есть поддержка в ScalikeJDBC: github.com/scalikejdbc/scalikejdbc-async
Также, если не хочется работать с ними напрямую, есть поддержка в ScalikeJDBC: github.com/scalikejdbc/scalikejdbc-async
Сетевой стек в Akka, берет свои корни у Spray и работает более эффективно, чем например Netty
Голословно. Есть статьи, бенчмарки, какие-то пруфы?
Ну собственно не хотелось бы разводить тут холивар по поводу бенчмарков.
Каждый измеряет свое, и на своих попугаях.
Мне лично хватило того, что я заменил Netty на Akka.IO в сетевой части TCP сервера и получил трехкратный рост количества обработанных пакетов в сек. И это при том, что Netty тюнилась, а Akka работала «из коробки».
Без тюнинга разница больше.
Но тут я не претендую на истину в последней инстанции. Библиотеки ведь развиваются.
Я для себя выводы сделал.
Каждый измеряет свое, и на своих попугаях.
Мне лично хватило того, что я заменил Netty на Akka.IO в сетевой части TCP сервера и получил трехкратный рост количества обработанных пакетов в сек. И это при том, что Netty тюнилась, а Akka работала «из коробки».
Без тюнинга разница больше.
Но тут я не претендую на истину в последней инстанции. Библиотеки ведь развиваются.
Я для себя выводы сделал.
О какой нагрузке речь?
Особенно забавно выглядит Ваше заявление, учитывая тот факт что в распределнных акторах юзается нетти =).
Особенно забавно выглядит ваше заявление, учитывая тот факт, что при приеме сообщений от клиента, не используются распределенные акторы. Может подскажете, как их вообще можно там использовать?
Ммм, ну я вообще-то тут пишу в контексте «работает более эффективно, чем например Netty». Сам факт использования в акке нетти, как бы намекает. А по поводу конкретно вашего случая — надо смотреть код. Поэтому если уж пишите что-то пододбное то или давайте факты, или не преподностите это как истину.
Если уж начинаете читать текст, то читайте до конца. Не вырывая фразы из контекста.
В тексте говорится не в общем смысле быстрее, а конкретно про сетевой стек TCP, который используется в примере. И про истину там ни слова нет.
А сам факт использования нетти, говорит лишь о «так исторически сложилось». Изначально использовали его, потому что не было более эффективного решения. Сейчас оно есть и на него плавно переходят. Сначала в IO отказались, потом и в других местах заменят.
P.S. И заканчивайте уже это занудство… никому оно не нужно, словами баловаться.
В тексте говорится не в общем смысле быстрее, а конкретно про сетевой стек TCP, который используется в примере. И про истину там ни слова нет.
А сам факт использования нетти, говорит лишь о «так исторически сложилось». Изначально использовали его, потому что не было более эффективного решения. Сейчас оно есть и на него плавно переходят. Сначала в IO отказались, потом и в других местах заменят.
P.S. И заканчивайте уже это занудство… никому оно не нужно, словами баловаться.
И заканчивайте уже это занудство… никому оно не нужно, словами баловаться.
Вы написали статью, опубликовали, у меня к содержанию статьи вопросы. Вы написали, что цитирую «Сетевой стек в Akka, берет свои корни у Spray и работает более эффективно, чем например Netty». Хочу получить об этом информацию. Так как вы автор статьи и об этом пишите, следовательно я полагаю, что у вас есть определенные источники этой информации, помимо одного Вашего субъективного случая. Иначе, повторю, это утверждение голословно.
Чем конкретно сетевой стек акки лучше нетти?
Я не пытаюсь Вас троллить, я реально хочу узнать.
Если бы реально хотели знать, сразу именно так и спросили.
Без вырывания фраз из контекста и попыток притянуть за уши факты.
А по существу, в одном каменте не ответишь.
Смотрите например www.youtube.com/watch?v=rTW9_p6Db_4
Если коротко, Akka более технологична. За счет этого быстрее и удобнее в использовании.
Тут надо просто понимать, что любые тесты субъективны. Невозможно в ситуации постоянно драбатываемой среды, библиотек и подходов написать абсолютно истинный тест.
P.S. Но вы можете считать любы тексты, тесты и доклады голословными, вам никто не запрещает)
Проведите тестирование, напишите статью, может оно кому и надо, измерять этих попугаев.
Без вырывания фраз из контекста и попыток притянуть за уши факты.
А по существу, в одном каменте не ответишь.
Смотрите например www.youtube.com/watch?v=rTW9_p6Db_4
Если коротко, Akka более технологична. За счет этого быстрее и удобнее в использовании.
Тут надо просто понимать, что любые тесты субъективны. Невозможно в ситуации постоянно драбатываемой среды, библиотек и подходов написать абсолютно истинный тест.
P.S. Но вы можете считать любы тексты, тесты и доклады голословными, вам никто не запрещает)
Проведите тестирование, напишите статью, может оно кому и надо, измерять этих попугаев.
Почитать почему акка перешла на спрей
Вы тоже не правы. Вы бы хоть поинтересовались причинами, по которым акка перешла на спрей. И они вовсе не связаны с производительностью. У нетти никогда не было проблем с производительностью. И ваш прирост в тестах объясняется не переходом на акку(спрей), а совсем другими нюансами.
Вы товарищ не очень владеете вопросом, но больно агрессивно отстаиваете свои ничем не подкрепленные мысли.
Вы тоже не правы. Вы бы хоть поинтересовались причинами, по которым акка перешла на спрей. И они вовсе не связаны с производительностью. У нетти никогда не было проблем с производительностью. И ваш прирост в тестах объясняется не переходом на акку(спрей), а совсем другими нюансами.
Вы товарищ не очень владеете вопросом, но больно агрессивно отстаиваете свои ничем не подкрепленные мысли.
В вашей ссылке написано именно то о чем я писал, Spray технологичнее Netty.
Поэтому и перешли. Я нигде не писал, что единственной причиной перехода был вопрос производительности. Я нигде и никогда не говорил, что у Netty проблемы с производительностью. И прежде чем так по детски гнуть пальцы, разобрались бы о чем я здесь пишу вообще.
>И ваш прирост в тестах объясняется не переходом на акку(спрей), а совсем другими нюансами.
А вот тут у вас с логикой что-то проскальзывает. Замена библиотеки A на B дает прирост производительности, но этот прирост не обусловлен этой заменой. Не ощущаете странности в вашем высказывании? Может объясните, почему замена библиотеки дает прирост, не обусловленный этой библиотекой?
P.S. Прежде чем тыкать в кого-то пальцем, обвинять, неплохо бы самому разобраться в вопросе, что бы не позориться так.
Поэтому и перешли. Я нигде не писал, что единственной причиной перехода был вопрос производительности. Я нигде и никогда не говорил, что у Netty проблемы с производительностью. И прежде чем так по детски гнуть пальцы, разобрались бы о чем я здесь пишу вообще.
>И ваш прирост в тестах объясняется не переходом на акку(спрей), а совсем другими нюансами.
А вот тут у вас с логикой что-то проскальзывает. Замена библиотеки A на B дает прирост производительности, но этот прирост не обусловлен этой заменой. Не ощущаете странности в вашем высказывании? Может объясните, почему замена библиотеки дает прирост, не обусловленный этой библиотекой?
P.S. Прежде чем тыкать в кого-то пальцем, обвинять, неплохо бы самому разобраться в вопросе, что бы не позориться так.
Нагрузочное тестирование проводили? Сколько держит рек-сек сервак?
Очень интересно, спасибо.
Что произойдет, если два юзера подключатся с одинаковыми данными авторизации (один логин)?
У акторов Room и GmService должно быть общее состояние — кто в какой комнате находится. Например, чтобы клиент не мог дважды отправить JoinRoom и оказаться в двух комнатах одновременно. В Akka нет гарантии доставки сообщений, поэтому между Room и GmService может возникнуть рассинхронизация. Как это разруливать?
Что произойдет, если два юзера подключатся с одинаковыми данными авторизации (один логин)?
У акторов Room и GmService должно быть общее состояние — кто в какой комнате находится. Например, чтобы клиент не мог дважды отправить JoinRoom и оказаться в двух комнатах одновременно. В Akka нет гарантии доставки сообщений, поэтому между Room и GmService может возникнуть рассинхронизация. Как это разруливать?
В Akka нет гарантии доставки сообщений, поэтому между Room и GmService может возникнуть рассинхронизация. Как это разруливать?Можно воспользоваться фичей под названием At-Least-Once Delivery и сделать обработку сообщений идемпотентной. Таким образом мы получим гарантированную доставку.
Корень проблемы гарантированной достаки в том, что непонятно какие гарантии она должна давать, так как у нас есть несколько вариантов.
Единственный способ узнать, было ли сообщение обработано или нет — это ввести подтверждение доставки на уровне бизнес-логики. По этой причине разработчики Akka намеренно не стали включать такую дырявую абстракцию, как гарантированная доставка.
- Сообщение отправлено в сеть?
- Сообщение принято другим хостом?
- Сообщение получено мейлбоксом?
- Сообщение начато обрабатываться актором?
- Сообщение успешно обработано актором?
Единственный способ узнать, было ли сообщение обработано или нет — это ввести подтверждение доставки на уровне бизнес-логики. По этой причине разработчики Akka намеренно не стали включать такую дырявую абстракцию, как гарантированная доставка.
Вот на этом моменте, многие путают гарантию доставки с потерей сообщения вообще.
Внутри JVM сообщение не может быть потеряно.
Другое дело, что ссылка актора, которому отправляется сообщение может не существовать на момент отправки. Или у него мейлбокс переполнится. Или еще много моментов из-за которых сообщение не будет обработано. И сообщение попадет в deadLetters.
Внутри JVM сообщение не может быть потеряно.
Другое дело, что ссылка актора, которому отправляется сообщение может не существовать на момент отправки. Или у него мейлбокс переполнится. Или еще много моментов из-за которых сообщение не будет обработано. И сообщение попадет в deadLetters.
Ну сами подумайте. Кто может может что либо гарантировать при crash JVM?
Описать логику для креша всего JVM? Как именно это можно сделать?
В момент смерти жвм вы ничего сделать уже не можете. Событие пропадет. Создавайте транзакции для больших гарантий.
Что-то у меня ощущение, что говорим на разных языках или вы просто хотите гарантий за даром.
Только один вариант — отвечать Ack-сообщением. Один из базовых принципов в архитектуре Akka — это location transparency, что значит актор может физически находиться где угодно. Можно не заморачиваться если jvm одна (и то с нюансами, актор может быть мертв, а почта в спец-ящике), но для другого инстанса (особенно где-то на другом хосте или вообще в другом дц) нельзя получить гарантию в принципе. Магия пока не доступна. Если вы соседу через забор камень кините, то пока он вас не обматерит, вы не узнаете результат (соседа нет, камень улетел куда-то дальше, соседа вырубило камнем). Смотрите как на аналог UDP в сетевом стеке. Соорудить из UDP TCP можно, обратно нет.
Это специфичная вещь, упоминания о которой в последних доках не вижу вдобавок. Реализовать свой ящик один из вариантов (если хочется аналог редо логов в реляционках).
Durable mailbox — это про другое. Оно лишь гарантирует, что сообщение, успешно записанное в mailbox, переживёт перезапуск приложения.
Но сообщение может потеряться не дойдя до mailbox'а, может возникнуть проблема сохранения на надёжное хранилище (и сообщение не попадёт в mailbox).
Это даже не говоря о том, что актор может упасть при обработке этого сообщения и оно будет выкинуто согласно логике работы mailbox'а.
Но сообщение может потеряться не дойдя до mailbox'а, может возникнуть проблема сохранения на надёжное хранилище (и сообщение не попадёт в mailbox).
Это даже не говоря о том, что актор может упасть при обработке этого сообщения и оно будет выкинуто согласно логике работы mailbox'а.
durable-mailbox из старой версии, по умолчанию именно так и работает.
Но тут надо понимать, что это дефолтные установки и все в твоих руках.
Можно заменить обработку, как выше описал meln1k.
Можно вообще сделать свою версию мейлбокса с шахматами и поэтессами.
Но тут надо понимать, что это дефолтные установки и все в твоих руках.
Можно заменить обработку, как выше описал meln1k.
Можно вообще сделать свою версию мейлбокса с шахматами и поэтессами.
Дополню, что такое поведение по умолчанию (удаление сообщения из mailbox'а при обработке) является защитой от ситуации, когда именно это сообщение является причиной смерти актора.
В случае, когда нужно иметь возможность попробовать обработать сообщение повторно при падении актора есть два варианта:
— добавить перед ним супервизор, который попробует послать сообщение повторно (но необходимо самостоятельно сделать защиту от livelock'а, если это сообщение приводит к падению актора),
— использовать peek mailbox (который требует явного подтверждения удачной обработки сообщения (см. doc.akka.io/docs/akka/2.3.11/contrib/peek-mailbox.html, на реализацию можно посмотреть здесь: github.com/akka/akka/blob/v2.3.11/akka-contrib/src/main/scala/akka/contrib/mailbox/PeekMailbox.scala)
В случае, когда нужно иметь возможность попробовать обработать сообщение повторно при падении актора есть два варианта:
— добавить перед ним супервизор, который попробует послать сообщение повторно (но необходимо самостоятельно сделать защиту от livelock'а, если это сообщение приводит к падению актора),
— использовать peek mailbox (который требует явного подтверждения удачной обработки сообщения (см. doc.akka.io/docs/akka/2.3.11/contrib/peek-mailbox.html, на реализацию можно посмотреть здесь: github.com/akka/akka/blob/v2.3.11/akka-contrib/src/main/scala/akka/contrib/mailbox/PeekMailbox.scala)
Сообщение должно быть immutable. У него не может быть никакого стейта. Оно могло уйти по цепочке акторов, в другую jvm и т. п.
Кроме того, вы в общем случае не можете определить упал актор от того, что сообщение кривое или от того, что какой-то внешний ресурс не доступен. Если нужны повторные попытки — оно описывается в бизнес-логике (как AtLeastOnceDelivery, как PeekMailbox или ещё как-то).
Кроме того, вы в общем случае не можете определить упал актор от того, что сообщение кривое или от того, что какой-то внешний ресурс не доступен. Если нужны повторные попытки — оно описывается в бизнес-логике (как AtLeastOnceDelivery, как PeekMailbox или ещё как-то).
Не надо делать для разных акторов общее состояние, это зло.
Состояние описывающее кто в какой комнате находится, должно быть только у GM.
Комнате должно быть все равно, она не решает ничего по поводу подключения игроков.
По поводу гарантий доставки. Тут есть нюансы. Ниже есть интересная статья на эту тему.
Но если пояснять именно про Akka…
Фраза «В Akka нет гарантии доставки сообщений» работает только в общем случае. Т.к. подразумевается, что Akka это распределенная система работающая на неизвестном количестве узлов. А раз в системе присутствует сеть, то понятно, что это слабое звено, которое может сбоить и в этом случае такую ситуацию надо обрабатывать отдельно. Поэтому и говорят, что при использовании Ask Pattern нет гарантий доставки.
В случае, если вы можете разместить акторы в пределах одной JVM, то гарантируется, что сообщение не будет потеряно.
Что, в общем-то, вполне логично.
Если все же акторы разойдутся по разным машинам, то meln1k ниже верно описал подход с At-Least-Once Delivery.
Состояние описывающее кто в какой комнате находится, должно быть только у GM.
Комнате должно быть все равно, она не решает ничего по поводу подключения игроков.
По поводу гарантий доставки. Тут есть нюансы. Ниже есть интересная статья на эту тему.
Но если пояснять именно про Akka…
Фраза «В Akka нет гарантии доставки сообщений» работает только в общем случае. Т.к. подразумевается, что Akka это распределенная система работающая на неизвестном количестве узлов. А раз в системе присутствует сеть, то понятно, что это слабое звено, которое может сбоить и в этом случае такую ситуацию надо обрабатывать отдельно. Поэтому и говорят, что при использовании Ask Pattern нет гарантий доставки.
В случае, если вы можете разместить акторы в пределах одной JVM, то гарантируется, что сообщение не будет потеряно.
Что, в общем-то, вполне логично.
Если все же акторы разойдутся по разным машинам, то meln1k ниже верно описал подход с At-Least-Once Delivery.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Игровой сервер на Scala + Akka: Разбор примера