Спасибо! У меня чисто в оперативе: при падении теряется максимум 30 событий или 60 секунд буфера, а для телеметрии цена такой потери — ноль, так что тащить внешнюю зависимость в подсистему, которая не имеет права ронять бота, смысла нет. Обычные остановки (деплой, рестарт) и так закрыты graceful shutdown'ом — dp.shutdown.register(batcher.close) дошлёт хвост, реально теряется только при SIGKILL/OOM. Реализацию такого батчера можешь посмотреть: https://github.com/ivan-nechaev/anystat-python/blob/main/src/anystat/_batcher.py
А вам всё зависит от того, зачем батчер нужен: вопрос тут один — сколько стоит одно потерянное событие? Если телеметрия — оперативы хватит; если это задачи распознавания, результата которых юзер ждёт (а то и заплатил за них) — нужна персистентная очередь, и Redis полностью оправдан. Ну а если просто хочется сузить окно потерь, дешевле не Redis, а flush_interval поменьше.
Спасибо! У меня чисто в оперативе: при падении теряется максимум 30 событий или 60 секунд буфера, а для телеметрии цена такой потери — ноль, так что тащить внешнюю зависимость в подсистему, которая не имеет права ронять бота, смысла нет. Обычные остановки (деплой, рестарт) и так закрыты graceful shutdown'ом — dp.shutdown.register(batcher.close) дошлёт хвост, реально теряется только при SIGKILL/OOM.
Реализацию такого батчера можешь посмотреть: https://github.com/ivan-nechaev/anystat-python/blob/main/src/anystat/_batcher.py
А вам всё зависит от того, зачем батчер нужен: вопрос тут один — сколько стоит одно потерянное событие? Если телеметрия — оперативы хватит; если это задачи распознавания, результата которых юзер ждёт (а то и заплатил за них) — нужна персистентная очередь, и Redis полностью оправдан. Ну а если просто хочется сузить окно потерь, дешевле не Redis, а flush_interval поменьше.