какая жесть! код на уровне Высоцкого, а может даже и выше

Кажется Саша специально подложил линейный подсчет неуспешных ответов при каждом запросе) Вместо перебора буфера можно использовать плавающее окно на очереди со счетчиком. Да и в half-open насколько знаю не весь трафик льется.

Спасибо

Я всегда пробую 3 раза, бог любит троицу :)

Есть у меня предположение, что тема не раскрыта. Вот я понял тут, циркутбрекер в данном варианте это реквест-тротлер по сути, а про настоящий циркутбрекер тут нам господин Сахаров не рассказал. Вот как клиент, получивший ошибку от вашего циркутбрекера должен транслировать ее дальше? =Непонятно! Меж тем настоящий циркутбрекер для этого использует другой механизм - А?! - Сахаров - давай исправляй ситуацию! Материал-то - так себе

Чтобы базу не ронять нельзя просто пул ограничивать внутри микросервиса или подключаться через то, что умеет реальные подключения ограничивать?

@alexandrsakharov629

11 ай бұрын

Внутри сервиса мы так и будем делать. 1 Однако, дело может быть не в бд 2 Внешний сервис для нас черный ящик, мы знаем лишь, что он перестал держать нагрузку

@jashakimov8578

11 ай бұрын

@@alexandrsakharov629 приветствую, а что делать дальше с клиентским запросом? Положить в очередь и потом обработать? Какую проблему помогает решать этот паттерн, если система реал-тайм должна отдавать ответы. Получается, что с что без CB мы отдаем ответ не 200 клиенту.

Круто что вы стали разбирать подобные паттерны. Но по моему субъективному мнению есть большое НО 1. Сам находится элементарно в гугле и нет никакой проблемы прочитать общее представление. Смысл пересказывать общедоступную базовую инфу? 2. То что вы представили в виде кода абстрактную реализацию это хорошо, но чутка нудновато)) 3. Хотелось хотя бы в общих чертах увидеть в видео то каким именно образом реализовывается этот паттерн хотя бы базового. Этого как раз и не хватает в инете. Вот на вашем примере, вы будете в том же инстансе приложения держать этот код и вести подсчет??? а как это скажется на пропускной способности? или может вы это будете фиксировать в какой то реляционной БД что бы лазить за этими данными и делать выводы?? или может быть мы эти данные будем записывать в Кэш и использовать эту прокладу и брать инфу оттуда??? или может существую еще какие либо способы?? боле прикладной инфы охота