Забитый канал — как вы с ним поступаете в Go?

Разработчики языка Go подбросили программистам занятную дилемму — в виде фиксированного размера буфера у каналов (тех что используются для передачи сообщений между потоками — точнее «go-рутинами» приложения). На днях на ревью увидел у коллеги код в духе:

• хотим оповещать «подписчиков» об изменениях в БД, асинхронно

• используем для этого канал с буфером какой-то вместимости (например, 50)

• когда вызывается коллбэк от БД, мы создаём информационное сообщение и пытаемся затолкать его в канал

• если канал оказался заполнен, просто пишем ошибку в лог и нормально завершаем коллбэк

Стоит ли так делать? А какие ещё варианты? Был бы канал безразмерным (как в erlang или некоторые из очередей в java) — программист и не задумался бы (может семантически лучше чтобы отправка в канал удавалась всегда — как запись в массив или мэпу) — но в Go нам предоставили «более полный» контроль над ситуацией, только не сказали что с ним делать 🙂

Мне неизвестен ответ в духе «серебрянной пули» — ниже я лишь подытожил варианты которые обычно приходят в голову — и буду рад если вы поделитесь соображениями и опытом (а может и какими-то полезными библиотечками).

Вариант 1 — блокироваться

Предусмотренное в самом Go поведение достаточно естественно — блокироваться на операции записи в канал пока в буфере не появится место. В этом смысле никакой ошибки при записи и не возникает. Код создающий отправляемые события начинает «самотормозиться» — и во многих случаях этого достаточно (особенно если нагрузка пиковая а не постоянная).

Когда это может быть нехорошо?

Ну, понятно — если вдруг у нас вызывающий код прямо очень критичный ко времени выполнения и блокироваться ему не положено. При этом сама логика работы должна подразумевать «отправил и забыл» — впрочем если у канала буфер ненулевого размера то речь именно о такой логике обычно и идёт.

Вариант 2 — долой ограничения

Чтобы не отставать от «других языков» можно наверняка обернуть канал в структурку и сделать его авто-разрастающимся. Скорее всего такие реализации уже есть, стоит только копнуть в гитхабе.

Хорошо ли это?

Смотря из-за чего он «разрастается». Как и выше вскользь говорилось — если это короткий пик нагрузки (ну вот в нашем случае может какая-то мудрёная операция на БД выполнилась) который лишь временно превысил вместимость канала — то вроде бы нормально. Это получается просто канал который сам подстроится под нужный размер не заставляя программиста пытаться «угадать заранее».

Это защитит и от неожиданностей при эволюции приложения. Быть может сейчас мы по тестированию определили что достаточно буфера на 50 сообщений, а год-два спустя из-за усложнения запросов в БД там пики до 150 будут — (но не миллиард и не миллион даже). Ради таких незначительных изменений в константах пересобирать код (заводить тикеты и пр) кажется глупо.

Если же переполнение из-за того что нагрузка постоянно превышает возможности «получателя» на выходе канала, то бишь нам не хватает производительности — то безразмерный канал будет просто «маскировать» проблему — вполне возможно что из-за этого приложение «бумкнет» не на тестовом стенде а в проде 🙂

Вариант 3 — внешняя очередь

В последнем случае — когда мы чувствуем что нам пригодился бы «безразмерный» канал, но подозреваем что проблемы могут возникать из-за производительности консьюмера, а не из-за «пиков» — на мысль обычно должна прийти реализация с внешней очередью. Всё-таки каналы, работающие «внутри инстанса» это вещь с ограниченной применимостью. Внешние очереди — другое дело:

• обычно у нас есть возможность масштабировать количество консьюмеров и это даёт большую гибкость

• плюс существует немало готовых способов мониторить состояние большинства популярных мессадж-брокеров и получать ворнинги и алармы централизованно не когда «оно уже бумкнуло» а когда в очередях скапливается подозрительно много сообщений

• можно даже второе с первым связать, запускать консьюмеры в «лямбдах» и т.п. (эластичное решение — если у нас есть эластичное облако)

Тут основными противопоказаниями является разве что некоторое усложнение системы (вот уж ошибки записи во внешнюю очередь всегда могут произойти, проверять их необходимо и т.п.) — ну и зоопарк этих самых очередей и даже «баталии» разработчиков (ортодоксы с кафкой и рэббитом против сектантов с натсом и бинстолкд, шутка).

В целом этот вариант «корректнее» ложится на «микросервисную» идею — а встроенные каналы можно использовать лишь для каких-то самых легковесных операций.

Вариант 4 — фоллбэк с синхронным вызовом

В некоторых случаях (в частности вот этот с нотификациями по операциям в БД) предлагается рассмотреть использование «фоллбэка» — если не удалось отправить сообщение через канал, не дёрнуть ли нам «консьюмера» напрямую?

Ведь для чего в данном случае канал нужен — чтобы не тормозить коллбэк вызванный БД при совершении операции. Но если канал заполнен — ну чёрт с ним, пусть попробует выполниться «напрямую» — протормозит так и ладно — но всё же операция выполняется.

Это похоже на то как сверхпроводящий кабель заключают в «изоляцию» из обычной меди например. Если температура повышается и сверхпроводимость исчезает — ток продолжает идти по медной оболочке, хотя и с потерями — но это лучше чем резко разрывать цепь.

Правда при ближайшем рассмотрении этот вариант не сильно отличается от блокирования на операции записи. Только мы нарушаем порядок эвентов (если это важно). Да и логика консьюмера должна позволять такой «вызов извне» (нужно соблюсти в нём потокобезопасность и пр).

Зачем такой вариант может быть нужен? Мне трудно придумать юзкейс 🙂 может вы знаете ситуацию с каким-то особенным консьюмером который изредка (на каких-то типах сообщений?) сильно тормозит… Что-то странное в общем.

Некоторый профит «на уровне языка» в том что мы при этом точно можем писать ворнинг в лог или сигнализировать другим способом что наблюдается нештатная ситуация. При простой блокировке на записи нам это по-простому не сделать.

Вариант 5 — с обратной связью

Мы можем занять «проактивную» позицию и проверять что буфер полон (или лучше — полон наполовину) — и если так, то не просто сыпать сообщения в лог — а принимать какие-то меры — например, сигнализировать вызывающему коду чтобы поумерил свои аппетиты. Послать сигнал «горшочек, не вари!»

Очевидно этот подход сильно зависит от задачи. В случае с нотификациями по операциям в БД — куда мы пойдём? Попросим «писать пореже»? Включим задержки в пользовательском интерфейсе? 🙂 Наверняка область применения найдётся — наиболее явно если это какая-то балк-обработка (но ей не так часто нужны мессаджи-каналы-очереди).

Заключение

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

Варианты с мониторингом состояния канала и оповещениями или даже «саморегуляцией» кажутся наиболее прогрессивными, но требуют дополнительных трудозатрат. Известны ли вам какие-то готовые обёртки подобного рода над каналами в Go?

С другой стороны — а если это очередь для отправки алармов по проблемам при выполнении. ошибкам и т.п. — то куда же мы будем отсылать ошибки о том что очередь ошибок переполнилась? 🙂