EliseeAlex.me

Шаг 1

Первый взгляд на Akka

Зачем скале акка? Кто такие акторы? Зачем они нужны? Как акка делает многопоточность проще?

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

Scala и Akka

  • В Scala преобладает парадигма функционального программирования (курс от создателя скалы). Она накладывает ограничение немутабельности на код. Это значит, что объекты не должны менять своё содержимое после создания. Если нужно изменить состояние объекта, создаём новый объект и дальше использовуем его.
  • В реальной жизни, это ограничение слишком строгое. Реальные программы работают с данными, которые постоянно изменяются. Они зависят от внешних источников информации и в наших процессах присутствует «память».
  • Эта «реальность» несёт за собой много проблем. Из-за них в обычных многопоточных программах появляется большое количество ошибок. Но этой реальности не избежать. Поэтому в функциональных языках программирования (эрланг, скала) появились акторы.

Что такое актор?

  • Актор — это абстракция, которую легче всего представить как «однопоточное» приложение, которое выполняет список задач. На практике, это обозначает, что внутри актора можно использовать изменяющееся состояние и почти что забыть о многопточности. Однопоточность взята в кавычки, потому что актор не занимает поток JVM полностью и вообще, он может перемещаться между разными потоками. Подробнее об этом можно узнать из описания акторов в документации.
  • В однопоточном приложении могут одновременно существовать тысячи таких акторов.
  • Актор может иметь изменяемое состояние, независимое от внешнего мира. И пользоваться им, не заботясь о проблемах, которые обычно присущи многопоточным системам.
  • Тем не менее, такой подход требует использование лучших практик. Если использовать акторы бездумно, то они не дадут никакой пользы.

Особенности работы с акторами (выдержки из лучших практик)

  • В основе акторов лежит философия «let it crash». Это значит, что не стоит писать обработку ошибок там же, где они возникают. Ошибки нужно обрабатывать на том уровне бизнес логики, на котором известно, что с ними делать. Это может быть реализовано с помощью иерархической структуры акторов. Можно забыть о бесконечных траях и кетчах.
  • Блокирующие ресурсы (база данных, файлы на жёстком диске, синхронные http запросы и т.д.) требуют внимательного управления. Нельзя бездумно вызывать их в акторе (актор заблокируется и все запросы встанут в очередь), так же нельзя бездумно создавать футуры и исполнять запросы (их может стать слишком много и на сервере кончится память). Для этого есть особые подходы.
  • Изменяющееся состояние не должно выходить за рамки актора. Только немутабельные сообщения, не забываем, что это ФП. Не стоит забывать, что состояние можно передать случайно, если передавать в сообщении поведение (с помощью замыканий).