akka: как я перестал бояться и полюбил асинхронный код

Как я перестал бояться и полюбил асинхронный код

JUG@VRN, 2014

Гребенников Роман,Sociohub

Содержание

● Модель акторов:o зачем она нужна;o что это такое;o Akka 2 и Scala;o какие возможности даёт.

● Пример системы:o система сбора и парсинга данных.

● Личный опыт:o типичные ошибки;o подводные камни;o производительность;o перспективы.

Free lunch is over

Одно ядро, один поток - путь в никуда:

[1]: http://www.gotw.ca/publications/concurrency-ddj.htm[2]: PassMark, http://www.cpubenchmark.net

Free lunch is over

Одно ядро, один поток - путь в никуда:

[1]: http://www.gotw.ca/publications/concurrency-ddj.htm[2]: PassMark, http://www.cpubenchmark.net

Concurrency vs Parallelism

[1]: Rob Pike: Concurrency is not Parallelism (it's better!), http://concur.rspace.googlecode.com/hg/talk/concur.html

Parallel programmingстрого одновременное исполнение нескольких задач

Concurrent programmingкомпозиция независимо выполняющихся задач

(не обязательно параллельно)

Concurrent programmingкомпозиция независимо выполняющихся задач

(не обязательно параллельно)

Всё это сложно

Корень проблемы

Shared mutable state

Shared mutable stateи его друзья

Зачем нужны акторы?

● Чтобы перестать думать о плохом:o блокировки, race conditions, дедлоки;o shared state, state visibility;o потоки, concurrent collections и т.д.

● И начать думать о хорошем:o single execution flow:

актор работает последовательно;o слабая связанность всех компонентов:

легко тестировать;o асинхронность:

больше никакого Await;o нет никакого shared mutable state.

● Легкость масштабирования:o часть платформы, не надо ничего изобретать;o есть восстановление после сбоев: “let it crash”.

● И начать думать о хорошем:o single execution flow:

актор работает последовательно;o слабая связанность всех компонентов:

легко тестировать;o асинхронность:

больше никакого Await;o нет никакого shared mutable state.

Модель акторов

● Придумана в 1972 году, до сих пор актуальна [1]

● Стала популярной благодаря Erlang● Всё - актор, даже небо, даже звезды

[1]: http://letitcrash.com/post/20964174345/carl-hewitt-explains-the-essence-of-the-actor

Модель акторов

● Придумана в 1972 году, до сих пор актуальна [1]

● Стала популярной благодаря Erlang● Всё - актор, даже небо, даже звезды

[1]: http://letitcrash.com/post/20964174345/carl-hewitt-explains-the-essence-of-the-actor

● Акторы:o функционируют параллельно;o асинхронно обмениваются сообщениями;o имеют персональный адрес и почтовый ящик.

● при получении сообщения можно:o отправить новое сообщение другим акторам;o создать новых акторов;o изменить свое поведение для следующего сообщения.

● Напоминает Email

● Jonas Bonéro Java champion;o Terracotta JVM clustering,

JRockit JVM, AspectWerkz AOP, Eclipse AspectJ.

● Ресурсыo http://akka.io/docs/o http://letitcrash.com/

● Кодo http://github.com/akka/akkao Apache 2.0 Licenseo Scala API, Java API

Áhkká (Lule Sami: "old woman")

Actor внутри

ActorRef

Почтовый ящик

Указывает на актора.Умеет класть сообщения в ящик.

Ваш код тут

Actor внутри

ActorRef

Почтовый ящик

Указывает на актора.Умеет класть сообщения в ящик.

Ваш код тут

Берет сообщения по-одному.Что-то с ними делает.

Единственный способ взаимодействия - отправка сообщения. Во внутренности

актора доступа нет ни у кого.

Создание актора

Почтовые ящики

Пути как в файловой системе:● akka://system/user/foo/bar● akka.tcp://system@srv.example.com/user/foo/bar

Выбор актора:● каждый актор знает себя, родителя и детей;● акторов можно выбирать по пути из ActorRegistry:

Типы:● UnboundedMailbox;● BoundedMailbox;● UnboundedPriorityMailbox;● BoundedPriorityMailbox.

Диспетчеры

● Актор != поток

поток 1

поток 2

A4 A4A1

поток 1

поток 2

A4 A4A1

● Каждый актор жив, только когда работает● В остальное время он освобождает поток

поток 1

поток 2

A4 A4A1

● Каждый актор жив, только когда работает● В остальное время он освобождает поток● Диспетчер занимается раскладыванием акторов

по потокам:o Dispatcher;o PinnedDispatcher;o BalancingDispatcher;o CallingThreadDispatcher.

поток 1

поток 2

A4 A4A1

● Каждый актор жив, только когда работает● В остальное время он освобождает поток● Диспетчер занимается раскладыванием акторов

по потокам:o Dispatcher;o PinnedDispatcher;o BalancingDispatcher;o CallingThreadDispatcher.

● Для непосредственного исполнения:o fork-join-executor;o thread-pool-executor.

Падший актор

● Код иногда ломается● Как жить дальше и что делать?

ActorRef

Parent

MessageBox

ActorRef

Parent

MessageBox

ActorRef

Parent

ActorRef

Parent

deadLetters Могильник для потерянных сообщений

ActorRef

Parent

deadLetters Могильник для потерянных сообщений

● И что?

Supervision

● Можно делать иерархии акторов● Каждый актор в ответе за своих детей● Упавшего ребенка можно:

Supervision

● Stop: остановить;● Restart: перезапустить;● Continue: оставить полу-лежачим;● Escalate: передать обработку выше.

Supervision

● Решение рекурсивно● Есть хуки preStart, preRestart, postStop, etc.

Supervision

● Решение рекурсивно● Есть хуки preStart, preRestart, postStop, etc.

Akka remoting/cluster

● Волшебный ActorRef: может указывать куда угодно

● Нет никакой разницы:o Акторы в одной JVM;o Акторы в разных JVM;o Акторы на разных серверах;o Акторы в нескольких DC, континентах и галактиках.

● Набор полезных примитивов:o Publish-subscribe;o Singleton;o Cluster state feed;o Cluster-aware routers.

● Легко отстрелить ногу

Akka в бою: задача

● Кейс: классический web-crawlingo Поисковик по людям (как http://people.yandex.ru, только круче).o Все просто на первый взгляд.o Но становится сложно, когда возрастают объемы.

Akka в бою: задача

● Кейс: классический web-crawlingo Поисковик по людям (как http://people.yandex.ru, только круче).o Все просто на первый взгляд.o Но становится сложно, когда возрастают объемы.

● Проблемы:o распределенная очередь;o ненадежная сеть;o ненадежные сервера;o разные сценарии сбора для разных сайтов;o невалидный HTML;o невозможно парсить весь рунет

на одном сервере.

Статистика

● Три машины: 32Gb RAM, Linux● 500 запросов/с на машину, поток 50мбит● 30Тб данных в месяц ● в очереди ~300 млн. целей● полный пересбор раз в два месяца

Прототип паука:● был написан на С++ и libcurl;● работал на одном сервере.

Наступили на грабли:● Упёрлись в один сервер

● Слали запросы синхронно:o 2000 простаивающих потоков, ждущих данные из сети;o 2k*8Mb = 16Gb памяти только на стек для потоков;o Нельзя делать select из >1024 дескрипторов.

● Сегфолты: падающий поток мог вынести всё:o Coredump на 20Гб;o полчаса чтобы посмотреть бектрейс.

● Жизнь слишком коротка для С++

После хождения по граблям, поняли что хотим:● асинхронное IO;● масштабирование из коробки;● сказать нет shared mutable data;● восстановление после сбоев;● легкость отладки и тестирования.

Варианты:● Scala + Akka;● Java + Akka;● Erlang;● boost: asio, phoenix, cppnetlib.

После хождения по граблям, поняли что хотим:● асинхронное IO;● масштабирование из коробки;● сказать нет shared mutable data;● восстановление после сбоев;● легкость отладки и тестирования.

Варианты:● Scala + Akka;● Java + Akka;● Erlang;● boost: asio, phoenix, cppnetlib.

Архитектура

сеть

Master

Log store

Data store

NodeBot

Dequeue

Очередь

Crawl Save

Работа с сетью

Несколько вариантов:● spray.io

o написан на idiomatic Scala, свой DSL;o Akka под капотом;o немного для других вещей;o spray-can сбоку на изоленте, многое не умеет;o разработку штормит, в процессе слияния с akka-http.

Работа с сетью

Несколько вариантов:● spray.io

o написан на idiomatic Scala, свой DSL;o Akka под капотом;o немного для других вещей;o spray-can сбоку на изоленте, многое не умеет;o разработку штормит, в процессе слияния с akka-http.

● Apache http-async-cliento Java;o стабильный как мамонт;o умеет вообще всё;o модульный и расширяемый

(inb4 MyConnectionKeepAliveStrategyBuilderFactory);o свои, ни с чем не совместимые Future, ThreadPool и т.д.

● Не такой уж и асинхронный:o решили использовать общий с akka thread-pool;o Java DNS lookup - синхронный и через UDP;

o UDP иногда теряется, это норма;o потеря пакета - вечная блокировка потока в thread-pool;o через два дня работы весь thread-pool заблокирован.

● Не такой уж и асинхронный:o решили использовать общий с akka thread-pool;o Java DNS lookup - синхронный и через UDP;

o UDP иногда теряется, это норма;o потеря пакета - вечная блокировка потока в thread-pool;o через два дня работы весь thread-pool заблокирован.

● Как жили дальше:o раздельные thread-pool для akka и AHC;o свой dns lookup, который умеет в таймауты;o регулярное изучение thread dump’ов на предмет блокировок.

Одноразовые акторы

● Создать нового актора - дешево и быстро:o ~300 байт памяти;o можно создать хоть миллион.

● Одна подзадача - один актор:o получил задачу;o сделал её, послал результат и помер.

● Чистые иммутабельные акторы

асинхронный коллбек!

Future[T]

Ask pattern● Возможность что-то асинхронно спросить у актора● Ответ - монада Future[T]

Ask pattern● Возможность что-то асинхронно спросить у актора● Ответ - монада Future[T]● Под капотом:

o создается временный актор, который ждет ответа;o ответ заворачивается в результат Future.

порядок вычисления

Akka ask puzzle

● Вылетел exception● Что окажется в result?

Akka ask puzzle

1. Failure(e:UnsupportedOperationException).2. “”3. Failure(e:AskTimeoutException).4. Failure(e:ClassCastException).

Akka ask puzzle

Временный актор создается вне общей

иерархии

Мы и ask pattern

● Если уметь готовить аски, то жить можно● Используем длинные цепочки асков:

Bot ScriptAction ScriptRunner

RequestExetutorThrottlerHttpClient

Мы и ask pattern

● Если уметь готовить аски, то жить можно● Используем длинные цепочки асков:

Bot ScriptAction ScriptRunner

RequestExetutorThrottlerHttpClient

● Легкая декомпозиция задачи на части● Каждую часть легко тестировать● Есть overhead на создание временного актора

FSM, Конечные автоматы

● Можно и без них, но с ними удобнее● Помогают в задачах, когда:

o актору нужно долго подниматься;o есть четкие переходы между состояниями.

● Увлеклись: o у бота 10 состояний;o ~30 правил перехода;o 500 строк лапши;o тестировать почти невозможно.

● Сейчас: o у бота 2 состояния (просыпаюсь и активный) и 5 правил;o вся логика вынесена в отдельные акторы;

есть и дочерние FSM.

Тестирование

Два подхода к тестированию:

● Синхронное через TestActorRefo можно руками дернуть актора за receive();o в самый раз для простой логики.

● Асинхронное через akka.TestKito полный запуск системы;o дополнительный синтаксис для assert-ов;o можно подсовывать mock-акторов.

Логгинг

● Есть интеграция c slf4j● log.debug(“foo”) - отправка сообщения логгеру● MDC - message diagnostic context

Логгинг

● Есть интеграция c slf4j● log.debug(“foo”) - отправка сообщения логгеру● MDC - message diagnostic context

У нас:● Свой логгер на основе akka.event.slf4j.Slf4jLogger● Пишем логи в кассандру:

o 5-10Гб в сутки;o разный time-to-live для DEBUG/INFO/WARN/ERROR;o агрегация на лету при записи;o простой web-gui, который рисует статистику.

Производительность

● 2M сообщений в секунду - легко!

[1]: http://letitcrash.com/post/17607272336/scalability-of-fork-join-pool

● На мощном сервере еще больше: [1]

● У нас: ~1000 msg/s, оверхед близок к нулю

● На мощном сервере еще больше: [1]

“Динамическая” типизация

[1]: H.E. Jiansen: Typecasting actors, from Akka to TAkka[2]: Akka 2.x Roadmap

● Боль: несоответствие типов сообщений вылезает наружу только в run-time

● Хочется строгой типизации

Старая проблема:● TypedActor в Akka 2.0● TAkka [1]

● “Gålbma”, Akka 3.0 [2]

Старая проблема:● TypedActor в Akka 2.0● TAkka [1]

● “Gålbma”, Akka 3.0 [2]

У нас:● Интеграционные тесты● Акторы обычно умеют только

в один тип сообщений

Ошибки: Thread starvation

Что это:

● Блокировка потоков в thread-pool.

Что это:

Откуда берутся:● Thread.sleep(), Await.result() внутри актора;● долгие вычисления;● интеграция с легаси-кодом.

Методы борьбы:● ломать пальцы за Thread.sleep() внутри актора;● отдельные dispatcher’ы;● мониторинг стека вызовов и загруженности

потоков.

Что это:

Откуда берутся:● Thread.sleep(), Await.result() внутри актора;● долгие вычисления;● интеграция с легаси-кодом.

Ошибки: OutOfMemoryException

Причины:● переполнение почтового ящика;● слишком много акторов.

Ошибки: OutOfMemoryException

Причины:● переполнение почтового ящика;● слишком много акторов.

Что делать:● мониторить загруженность почтового ящика;● прореживать очередь сообщений;● периодически изучать heap-dump и GC logs на

предмет утилизации памяти;● следить за логическими утечками (замыкания).

В итоге● прошли путь от akka 2.0 до 2.3.x● один год в production

В итоге● прошли путь от akka 2.0 до 2.3.x● один год в production● в начале приходится тяжело:

В итоге● прошли путь от akka 2.0 до 2.3.x● один год в production

● много скрытых граблей, но жить можно● исключительно простой и выразительный

формализм● удобно разрабатывать и тестировать

● в начале приходится тяжело:

Ссылки

● Typesafe activator [1]

● Coursera: Principles of reactive programming [2]

● Книги:o Jamie Allen: Effective Akka, 2013;o Derek Wyatt: Akka concurrency, 2013.

● Блоги:o letitcrash.com [4]

[1]: https://typesafe.com/activator[2]: https://www.coursera.org/course/reactive[3]: https://letitcrash.com

akka: как я перестал бояться и полюбил асинхронный код

Engineering

Асинхронный биллинг для службы...

Развитие продуктового портфеля...

Как перестать отлаживать...

Как я перестал бояться токенов и...

sanakirja fysiikka ven - akkuna venäjälle ·...

лука войно ясенецкий. я полюбил...

Асинхронный javascript

Асинхронный ввод / вывод

Обзор «Рейтинг инвестиционной ......

poudriere или как я перестал...

ЦЕНТРОБЕЖНЫЕ САМОВСАСЫВАЮЩИЕ...

Как я перестал мешать людям...

"Как перестать отлаживать...

srednja Škola, iii i iv razred ruski jezik testovi/testovi...

асинхронный двигатель с...

Как я перестал беспокоиться и...

Дмитрий Юницкий. «android ndk или как...

Индуктивно-ключевой...

асинхронный электродвигатель

ДОМ НАД ОНЕГО -...