Как стать автором
Обновить

Комментарии 8

Бхаха

Хорошо, давай я объясню всё как для пятилетнего, а потом разберу текст про колбэки в акторной модели и покажу, почему акторная модель проще, чем подписки и колбэки. Поехали!

Объяснение как для 5-летнего: что такое акторная модель, колбэки и подписки?

Представь, что у тебя есть игрушки, и ты хочешь, чтобы они что-то делали. Например, машинка должна ехать, а кукла — говорить "привет".

Колбэки — это как попросить друга

Ты даёшь машинку другу и говоришь: "Когда я скажу 'поехали', ты сразу её толкни, чтобы она ехала". Это называется колбэк. Ты ждёшь, пока друг всё сделает, и не можешь играть с другой игрушкой, пока он не закончит. Если друг долго возится, ты стоишь и ждёшь — это скучно и медленно.

Подписки (PubSub) — это как радио

Ты включаешь радио и говоришь: "Эй, все, кто слышит, когда я крикну 'поехали', толкайте свои машинки!" Кто-то услышит и сделает, кто-то нет. Ты не знаешь точно, кто что сделает, и не ждёшь — просто крикнул и пошёл дальше играть. Но если никто не услышал, машинка так и не поедет.

Акторная модель — это как почта с друзьями-помощниками

Ты пишешь письмо: "Машинка, поезжай!" — и бросаешь его в ящик. У тебя есть друг-почтальон, который сам решает, когда и как доставить письмо машинке. Ты не ждёшь, сразу берёшь куклу и играешь дальше. Машинка поедет, когда почтальон скажет, и тебе не нужно стоять рядом. Всё просто: отправил письмо и забыл!

Почему акторная модель проще?

С колбэками ты стоишь и ждёшь друга — это как если программа "зависает".

С подписками ты кричишь на радио, но не знаешь, кто услышит, и иногда надо проверять, всё ли сработало.

С акторами ты просто отправляешь письмо и не паришься — всё само сделается, когда надо. Не нужно следить за друзьями или кричать громче.

Разбор текста: "Колбэки в акторной модели" — как для 5-летнего и чуть сложнее

Теперь разберём текст. Он про то, как программисты решают, чтобы их код не "зависал" и работал быстро, даже если кто-то другой его использует.

Главная идея текста (как для 5-летнего)

Представь, что ты делаешь игрушечную фабрику, где машинки меняют цвет. Ты хочешь, чтобы другие дети могли сказать: "Эй, когда цвет поменяется, скажи мне!" Но если ты будешь ждать, пока они что-то сделают (например, нарисуют картинку), твоя фабрика остановится. Автор говорит: "Давай не ждать, а отправлять письма, как в почте, чтобы всё работало быстро!"

Подробности текста (чуть сложнее)

Автор жалуется, что в программировании часто прячут важные вещи, и это мешает. Например:

Ты пишешь код для смены цвета машинки.

Другой программист хочет узнать, когда цвет сменился, чтобы нарисовать картинку.

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

Пример кода (на псевдо-Эликсир):

elixir Скопировать Открыть блок

listener — это друг, который ждёт, когда ты сменишь цвет.

tap — это как сказать: "Я сделал, теперь ты делай".

Но проблема: если друг долго рисует картинку в on_change, твой код ждёт. Это синхронно — как если ты стоишь и смотришь на друга, пока он не закончит.

Почему это плохо?

Автор говорит: в реальной жизни ждать нельзя. Если код тормозит, клиенты уходят. Поэтому синхронный код (когда ждёшь) — это почти всегда плохо.

Что делать вместо колбэков?

PubSub (подписки) — как радио:

Ты кричишь: "Цвет сменился!" в канал.

Кто подписался, услышит и сделает что-то (например, нарисует картинку).

Ты не ждёшь, но не знаешь точно, кто что сделает.

Брокеры сообщений — как почта с гарантией:

Ты отправляешь письмо в "почтовый ящик" (брокер вроде RabbitMQ).

Другой код забирает письмо, когда хочет, и рисует картинку.

Ты идёшь дальше, не ждёшь.

Акторная модель (как в Erlang/Elixir) — лучшая почта:

У тебя есть "актёры" — маленькие помощники (как машинки или куклы).

Ты отправляешь им письмо: "Смени цвет!" или "Нарисуй картинку!"

Они делают всё сами, когда готовы, а ты играешь дальше.

Почему акторная модель проще колбэков и подписок?

Колбэки: ты ждёшь друга, пока он рисует. Если он медленный — всё тормозит.

Подписки: ты кричишь, но не знаешь, услышали ли. Надо проверять, кто подписался, и следить за каналами — это сложно.

Акторы: ты отправил письмо и забыл. Помощники сами разберутся, и ничего не тормозит. Всё просто и надёжно.

Как это в Erlang/Elixir?

В тексте упоминается Erlang (и Elixir):

Там нет "ожидания". Ты отправляешь сообщение актёру (как письмо), и он делает что-то сам.

Даже если ты хочешь ответ (как с GenServer.call), это всё равно два письма: одно туда, другое обратно. Ты не стоишь на месте.

Пример (как для 5-летнего):

Колбэк: "Докажи, что сменил цвет, прямо сейчас!" — и стоишь ждёшь.

PubSub: "Эй, всем, цвет сменился!" — и надеешься, что услышали.

Актор: "Машинка, смени цвет, когда сможешь" — и идёшь играть дальше.

Вывод

Акторная модель проще, потому что:

Ты не ждёшь (всё асинхронно).

Не надо следить, кто что услышал (как с подписками).

Каждый помощник (актёр) сам знает, что делать, и не мешает другим.

Текст автора говорит: "Колбэки — это прошлый век, они тормозят. Используйте акторов или хотя бы PubSub, чтобы всё было быстро и просто!" В Erlang/Elixir это уже встроено, как почта в игрушечном городе — отправил письмо и не паришься.

И пара моментов

Без подтверждения (fire and forget):

Ты отправляешь сообщение: "Смени цвет на красный!"

Актёр (например, процесс в Erlang) получает его и делает, что ты просил.

Ты не ждёшь и не знаешь точно, сделал он или нет. Это как бросить письмо и уйти — ты доверяешь, что всё сработает.

С подтверждением (запрос-ответ):

Ты отправляешь сообщение: "Смени цвет на красный и скажи мне, когда сделаешь!"

В письме ты добавляешь свой "адрес" (идентификатор твоего актёра).

Актёр меняет цвет и отправляет тебе ответ: "Сделал, цвет красный!"

Ты получаешь это сообщение позже и можешь что-то с ним сделать (например, сказать "ура!").

Почему это не как колбэки?

С колбэками ты бы сказал: "Смени цвет и сразу дай мне результат!" — и стоял бы, пока актёр не закончит. Это синхронно: ты ждёшь, и ничего другого делать не можешь.

В акторной модели даже с подтверждением ты не "стоишь":

Без ожидания: если тебе не нужен ответ, ты просто отправил сообщение и пошёл дальше.

С ожиданием: если нужен ответ, ты отправляешь запрос и ждёшь только его, но сам актёр работает независимо. Внутри это два письма, а не "зависание".

Сравнение с подписками

С подписками (PubSub) ты кричишь: "Цвет сменился!" — и кто-то может услышать, но ты не знаешь, кто и когда. Если тебе нужно подтверждение, приходится самому проверять: "Эй, ты услышал? Ты сделал?" Это лишняя работа.

С акторами ты можешь прямо попросить: "Сделай и скажи мне!" — и получить письмо обратно. Это проще, потому что:

Не надо следить за каналами (как в PubSub).

Не надо бояться, что кто-то не услышал.

Я польщен, что мой текст заставил вас потратить столько времени для написания ответа. Я не понял, зачем, правда, и почему в комментарии к моему тексту, но это издержки акторной модели в комментариях на форумах.

Какого такого времени?

Это же LLM

Мне было лень вспоминать что такое акторная модель и чем она отличается от подписок. Вот такой нехитрый способ вспомнить.

Получилось забавно, написал сюда.

калбеки в акторной модели это как есть дедикейтед сервер, и 2 игрока, 1 игрок начинает танцевать, второму в чат пишет оповещение шепотом, игрок 1 начинает танцевать вы про это?, калбек это вроде просто адрес функции за счет того что функция будет захвачена адресом явно вроде быстрее будет латенси как я понимаю

где-то даже читал что на супер действия в мире 3д стоит вешать действия в 3д мир на functional<()> (bind) чтото там типо так получше будет

вроде быстрее будет

Про это в тексте есть целый абзац. Будет быстрее сам вызов колбэка, но если он сам по себе выполняется долго, то вызывающий код будет вынужден ждать. Это непримелемо в подавляющем большинстве сценариев под высокой нагрузкой.

Синхронные вызовы — почти всегда признак недостаточной квалификации разработчика.

он покажет следствие запуска контролером 1 оповещение вокруг него он выполнится в условиях времени сервера почти сразу и дойдёт до контроллера 2 их в примере всего 2, соотв если соберется весь сервер в одном месте оповещение просядет, тоесть в пуле все будут, а в частной ситуации местячковой-рядовой вокруг контроллера икс не больше 100 контроллеров

контроллеры - игроки, в условиях сервера всегда, даже если обработка тридов время-то одно, ну у меня всегда синхронизировалось, рассинхрон не пробовал

Под высокой нагрузкой не бывает одного сервера, их много. Контроллеров (в вашей терминологии) в моих задачах обычно сотни тысяч.

Хабр уже не торт🎂, знаю 🦥

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации