6952
правки
Изменения
м
Нет описания правки
Актор - примитив параллельного, вернее, конкурентного, вычисления, который обрабатывает сообщения из своей входной очереди и посылает их другим акторам. При этом в статье были важные полагания: одно сообщение обрабатывается полностью, нет гарантий порядка отправки сообщений, сообщения могут теряться и нет никаких синхронных вызовов. У актора есть состояние, которое влияет на обработку сообщений, при обработке он может посылать сообщения другим, менять состояние, создавать других акторов. И, кроме обмена сообщениями, никакого взаимодействия между акторами нет, что как раз обеспечивает возможности масштабирования.
Модель отношений акторов: иерархическая и одноранговая. В иерархической - родитель создает, решает что делать при ошибке, можно восстановить, в том числе с сохранением очереди. В одноранговой акторами управлет управляет run-time, создавая акторы по необходимости для обработки сообщений и удаляя при отсутствии активности.
Usecase: pipeline proicessingprocessing, transaction application, стриминг данных (реактивные системы, event-based, чаты), multi-user concurencyconcurrency, приложения с распределенным состояниям, для которых не хватает одной машины, IoT - сообщения от датчиков и состояния, Timers - много таймеров по разным условиям.
И дальше был их пример. Dodo работает в 20 странах и в каждой надо интегрироваться с местным эквайрингом для приема платежей, никакого стандарта нет. Они использовали Microsoft Orleans, фреймворк появился в 2015, потом заснул и перспективы были неясны, но сейчас вроде проснулся и будет развиваться. Дальше было ряд рекомендаций: не забыть про observability (логи метрики трейсы); помнить что ресурсы не бесконечны, хотя актор и легковесен, и mailbox не бесконечный. Продумать восстановление состояния и балансировку нагрузки. А еще написание в синхронном стиле async/await приводит к тому, что между потоками могут возникать deadlock.