+-----------+--------------+--------------+
| АБСОЛЮТНО | НЕ ВИДИТ ПРО | БЛЕМ В ТАКОМ |
| ОФОРМЛЕНИ | И СЛУЖЕБНОГО | ВЫВОДА <EOT> |
+-----------+--------------+--------------+
Статья об использовании реактивного доступа к базам данных из корутин. Spring все упрощает, но это плохо сказывается на понимании реальных процессов работы приложения. Для демонстрации был выбран фреймворк KTor (просто потому, что мне нравится смотреть на то, что делает JetBrains), который интенсивно использует корутины — чтобы задача сочетания Reactive Streams и этих самых корутин добавила интереса. В процессе работы пришло понимание, что происходящее — явный пример преобразования непонятного многим реактивного потока в понятное императивное программирование, на котором мы собаку съели. Я люблю реактивные цепочки, но почему бы не порадовать тех, кто любит армейский порядок?
Реактивные приложения завоевали сердца и посадили нервы многих разработчиков, причем эти множества заметно пересекаются. Посадили бы еще больше, если бы не усилия сообществ, адаптирующих чистый поток разума от создателей спецификаций в удобоваримые библиотеки. Так произошло со спецификацией R2DBC и фреймворком Spring (Boot) — разработчику виден уже привычный Spring Data API с уже привычными реактивными типами данных. Однако есть причины не использовать Spring: не хочется Spring и хочется чего-то нового. Ну, есть еще унаследованный код, но в этом случае вряд ли придется столкнуться с реактивным доступом к данным.
В этом случае придется посмотреть на R2DBC без прикрас. И он будет ожидаемо сильно отличаться от того, что нам предлагают в готовом фреймворке — так же, как JDBC отличается от Spring Data JPA. Плюс реактивность. И реактивность по спецификации Reactive Streams. А у нас на слуху корутины. Которые вроде как будущее и все равно под них переписывать.
В этой статье я покажу как решить одну из проблем, возникающих при использовании распределенных очередей задач — регулирование пропускной способности очереди, или же, более простым языком, настройка ее rate limit'a. В качестве примера я возьму python и свою любимую связку Celery+RabbitMQ, хотя алгоритм, который я использую, никак не зависит от этих инструментов и может быть реализован на любом другом стэке.
Для начала пара слов о том, какую проблему я вообще пытаюсь решить. Дело в том, что 99.9% сервисов в интернете запрещают бесконтрольно закидывать их сотнями/тысячами запросов в секунду, угрожая дать в ответ какой-нибудь 403 или 500. Нет, ну правда, жалко им чтоле? Иногда таким сервисом может выступать даже своя собственная БД… Вобщем, доверять нынче нельзя никому, поэтому приходится себя как-то сдерживать.
Конечно, если вся работа ведется внутри 1го процесса, то никакой проблемы нет, но т.к мы работаем с Celery, то у нас может быть не только N процессов (далее воркеров), но и M машин, и задача все это дело синхронизировать уже не кажется столь тривиальной.