Паттерны конкурентности в Go. Подробный разбор. Часть 3. Pub/Sub

[uvelichitel]

Метод Publish в цикле отправляет сообщения в каналы подписчиков. Если подписчик по каким либо причинам не вычитывает сообщение из канала, то цикл блокируется??

for _, ch := range chnls {

// может быть здесь хотя бы select залепить от блокировки

ch <- message

}

[stoi]

Вы правы. Всё есть тут: https://github.com/istovpets/messaging/blob/master/messaging.go#L237 А в данной статье - нарочито упрощенный учебный пример.

[stoi]

Подписчик не может не вычитывать - это часть Notifiyer. Но вот если хэндлер подписчика будет долго тупить - заблокируется. В конце статьи есть об этом. В боевом коде конечно так лучше не делать. И в библиотеке я предусмотрел несколько стратегий на этот счет

[kukymbr]

Главная проблема такой реализации, мне кажется, в том, что при любом перезапуске сервиса потеряются все недополученные сообщения. Фикс этой проблемы приведет к изобретению своей версии редиски, кролика и им подобным :)

[stoi]

Это не проблема, ИМХО. Это же внутрисервисные сообщения - между компонентами одного приложения. Завершилась работа сервиса, завершились и внутренние сообщения и компоненты уничтожились. Это не замена Кролику )

[kukymbr]

так он же может завершиться нештатно? сервис перезапустится, publisher останется доволен, что всё отправил (до перезапуска), а ни один subscriber ничего не получит и потеряется какая-нибудь важная запись в бд например)

[stoi]

Ну если нештатно, тогда всё что угодно можно предполагать ). Тут и редиски с кроликами не помогут ))). Безусловно, в описанной тобой ситуации нужно не просто пулять сообщения, а что-то придумывать. Я когда писал либу и статью, ориентировался на System.Messaging в Delphi https://docwiki.embarcadero.com/CodeExamples/Athens/en/System.Messaging_(Delphi). По опыту знаю - очень удобная штука для сложных проектов. Кардинально уменьшает связанность и хаос в коде.

[apevzner]

А ещё то, что поздноподписавшиеся могут пропустить что-то интересное, что случилось до их прихода

В итоге, такая реализация накладывает определенные ограничения на порядок инициализации, вводя неочевидные зависимости.

В системе с большим количеством компонент это может больно стукнуть в какой-то момент

[stoi]

Предполагается, что все подписки инициализируются при старте приложения. Как любые другие зависимости. Вы же не говорите, что, допустим, накладываются ограничения на HTTP сервер из-за того, что БД не инициализирована до его старта? Это не полноценный брокер сообщений для микросервисов и хранить сообщения он не должен, ИМХО. Впрочем, если нужен именно такой сценарий - нужно сочинять что-то другое, не спорю.