Параллельные вычисления
Actor Model: Erlang, Akka
32 инженера, 450 миллионов пользователей. Когда Facebook купил WhatsApp за $19 миллиардов, инженеры не поверили: команда меньше, чем стандартный отдел в Google. Секрет - Erlang и акторная модель.
- WhatsApp: каждый сервер держит 2 миллиона одновременных TCP-соединений на Erlang/OTP
- Akka используется в Lightbend, PayPal, LinkedIn - там где нужна высокая конкурентность без shared state
- Discord перешёл с Python на Elixir (язык на BEAM VM) для real-time messaging - сейчас обрабатывает миллионы сообщений в секунду
Акторы: вычисление как переписка
1987 год. WhatsApp ещё не существует, но Джо Армстронг уже придумал то, на чём он будет работать. Erlang появился в Ericsson для телефонных станций - систем, которые не могут упасть никогда. Основная идея: вместо shared memory - изолированные акторы, которые общаются только через сообщения.
Актор - это примитив вычислений с тремя операциями: создать другого актора, отправить сообщение, определить поведение при получении следующего сообщения. Никакого общего состояния - только почтовый ящик.
Два ключевых свойства акторов: изоляция состояния (нет shared memory) и асинхронная доставка сообщений. Это устраняет race conditions на уровне модели, а не через блокировки.
Что происходит, если актор A отправляет сообщение актору B?
Mailbox и паттерны обмена сообщениями
Mailbox - единственная точка входа для актора. Erlang гарантирует порядок доставки сообщений между двумя конкретными акторами. Но от разных отправителей - порядок не гарантирован. Это принципиально: не нужно синхронизировать отправителей.
Переполнение mailbox - реальная проблема в production. Akka решает её через BackpressureStrategy: DropNew, DropHead, или fail актора. В Erlang по умолчанию mailbox неограничен, что может привести к OOM - мониторинг queue length обязателен.
Erlang гарантирует порядок сообщений при следующем условии:
Supervision: Let It Crash
Философия Erlang: 'Let it crash'. Вместо защитного кода с try-catch везде - иерархия супервизоров. Когда дочерний актор падает, супервизор решает что делать: перезапустить, остановить, остановить всех детей.
- restart - перезапустить актора с чистым состоянием (подходит для transient ошибок)
- resume - проигнорировать исключение, продолжить с текущим состоянием
- stop - остановить актора навсегда
- escalate - передать ошибку вышестоящему супервизору
В Erlang эта система называется OTP (Open Telecom Platform). Именно OTP делает 9 девяток uptime возможным: AXD301 switch достиг 99.9999999% - 31 миллисекунда простоя в год.
Когда стратегия supervision 'resume' подходит лучше всего?
Location Transparency и распределённые системы
Location transparency - актор не знает, где физически находится другой актор: на том же процессе, другом JVM процессе или на другом сервере в другой стране. Код отправки сообщения идентичен в обоих случаях.
WhatsApp использовал Erlang для messaging backend. При продаже Facebook в 2014 году - 450 миллионов пользователей, 32 инженера. Каждый сервер обслуживал 2 миллиона соединений одновременно. Location transparency позволяла прозрачно масштабировать кластер.
Actor Model устраняет все проблемы распределённых систем
Actor Model упрощает управление состоянием и отказоустойчивость, но split-brain, network partitions и exactly-once семантику нужно решать отдельно
Модель акторов - это абстракция над конкурентностью, а не серебряная пуля. CAP-теорема применима и к акторным системам.
В чём главное преимущество location transparency для разработчика?
Ключевые идеи
- Актор = изолированное состояние + mailbox + поведение. Никакого shared memory.
- Supervision tree: вместо try-catch везде - иерархия перезапусков. Let it crash.
- Location transparency: код не меняется при горизонтальном масштабировании кластера.
Связанные темы
Actor Model пересекается с несколькими концепциями параллельного программирования:
- CSP и каналы (Go) — Альтернативная модель конкурентности - каналы вместо mailbox, нет изоляции состояния по умолчанию
- Distributed Systems — Actor Model масштабируется на кластер через location transparency - основа распределённых акторных систем
Вопросы для размышления
- Чем философия 'Let it crash' отличается от традиционного defensive programming с try-catch?
- Когда акторная модель хуже, чем shared-memory многопоточность? Какие задачи ей не подходят?
- Как location transparency усложняет отладку и трассировку запросов в распределённой системе?