Ранее в заметке Делаем метрики и мониторинг для Akka при помощи Kamon мы уже познакомились с некоторыми возможностями Kamon. Правда, нельзя сказать, что возможности эти были особо впечатляющими, так как метрики можно вполне успешно писать и безо всякого Kamon. Сегодня же мы познакомимся с некоторыми другими средствами, предоставляемыми этой несколько спорной, но определенно очень мощной библиотекой.

В холиварах на тему Erlang/OTP против Scala/Akka сторонники Erlang часто используют аргумент, что дескать в Akka нет интроспекции. Имеется ввиду, что нельзя получить текущее состояние актора, нет аналога etop или Observer, и вот это все. Это правда, сама по себе Akka таких инструментов не предоставляет. Но, оказывается, на практике их можно очень просто реализовать своими силами.

Akka HTTP — это такая штука для написания своих веб-сервисов и хождения по HTTP в чужие, являющаяся преемником популярного веб-фреймворка Spray. Сегодня с помощью Akka HTTP мы напишем пару простых примеров клиентского и серверного кода. Поскольку писать телефонные книги уже как-то поднадоело (раз, два), примеры эти будут работать с сервисом plivo.com. Данный сервис позволяет звонить на телефоны, слать SMS и делать прочие подобного рода вещи.

Во многих серверных приложениях часто возникает необходимость кэшировать какие-то данные, так как количество тактов процессора ограничено, хождение в базу по сети занимает ощутимое время, да и пулы коннектов не резиновые. Сделали кэши, все хорошо. Но как только ваше приложение начинает работать более, чем на одном сервере, возникает проблема инвалидации кэшей. Когда пользователь пишет какие-то данные через один сервер, требуется обновлять или сбрасывать кэши на всех остальных серверах. Отчасти проблему позволяет решить Memcached, но с ним другие проблемы — (1) неизбежные накладные расходы на хождение по сети и (2) не всегда понятно, как сделать так, чтобы данные в кэше не разъехались в граничных случаях типа нетсплитов и поднятия новых кэш-серверов. Оказывается, что Akka Cluster из коробки предлагает довольно интересное решение озвученных проблем.

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

Как ранее уже отмечалось, Akka позволяет не только создавать акторы, которые обмениваются между собой сообщениями, но и строить кластеры, состоящие из нескольких физических машин. При этом акторы, запущенные на разных машинах, все еще могут взаимодействовать друг с другом. Кроме того, Akka из коробки предоставляет ряд полезных при построении распределенных приложений примитивов. Например, возможность подписаться на события, происходящие с кластером, присваивать узлам роли или запустить актор-одиночку. Что, кстати, делает Akka намного интереснее других реализаций модели акторов (Erlang, Cloud Haskell). В этой заметке мы напишем очень простое приложение, использующее akka-cluster, а также ознакомимся с его поведением при различных условиях.

Когда вы работаете с Akka, и вообще акторами, очень многое может пойти не так. Очереди сообщений могут переполняться, актор может начать перемножать матрички, заняв собой трэд, или, наконец, где-то могут просто начать сыпаться эксепшены. Пока у вас одна нода и мало пользователей, можно, конечно, просто быть на телефоне 24/7 и разбираться в проблемах по логам, отладочным ручкам, ну или remsh, если вы пишите на Erlang. Как только нод становится больше и проект выходит из альфы, такой подход становится совершенно нерабочим. На помощь приходит Kamon.

Иногда требуется запланировать выполнение кода на определенное время после происшествия какого-то события. Или сказать, что некий код выполняется снова и снова с заданным интервалом времени. Если в вашем проекте используется Akka, то вы можете решать такие задачи просто элементарно… на самом деле нет. Как мы скоро убедимся, даже здесь есть определенные тонкости.

Как нам с вами известно из опыта программирования на Erlang, при работе с акторами иногда могут возникать дэдлоки. Актор А1 шлет запрос с помощью gen_server::call актору А2, тот в свою очередь спрашивает что-то у А1, но А1 ему не отвечает, так как сам еще ждет ответа от А2. Дэдлок, отваливаемся по таймауту. К счастью, когда вы сталкиваетесь с этой проблемой, в логах есть стектрейсы, позволяющие легко диагностировать и исправить ошибку. Так вот, а совсем недавно я узнал, что в Akka дэдлок в этом случае не произойдет… за исключением одного граничного случая, о котором будет рассказано далее.

Akka — это библиотека для языков Java и Scala, в которой реализованы агенты, акторы, взаимодействие между акторами по сети и многие другие удобняшки. В первом приближении это напоминает Erlang или Cloud Haskell, но на самом деле Akka куда мощнее. Например, с помощью Akka можно легко объединить несколько машин в кластер, в котором будет отслеживаться исчезновение и появление машин, а акторы будут автоматически перемещаться с машины на машину по мере изменения размеров кластера. И это только один из примеров. В этой заметке мы напишем очень простое приложение, использующее Akka, чтобы показать, насколько легко работать с этой библиотекой.