Комментарии 4

В целом, хорошо. Однако, я немного, с Вашего позволения, покритикую не конкретно Ваше решение, а саму идею кастомной реализации job queue.
Если предположить что Вы разрабатываете библиотеку реализации job queue — то после того как она станет уровня продакшин — ее можно юзать всем и во всех проектах. Если же это как часть обычного коммерческого проекта — уверяю Вас, что устранение багов (утраченные сообщения, дублирующиеся сообщения и, особенно, остановка очередей — визитная карточка rabbitmq) ожидает Вас и Вашу команду.
В этом смысле есть готовые решения см. обзор решений https://habr.com/ru/post/458608/. Если почитать issue этих решений на git.hub, Вы сможете примерно узнать в начале какого пути Вы находитесь.


Кстати, очень не хватает отлаженной библиотеки job queue на rabbitmq, и Ваша библиотека вполне может стать ею.

Спасибо за комментарий и положительную оценку! Я согласен с Вашей критикой кастомной реализации job queue. Действительно есть много отличных готовых решений и делать еще одно не совсем уместно. Эта статья скорее недосказанный (поскольку я хотел сделать упор именно на rabbit и typescript) вариант реализации event sourcing.
RabbitMQ всем хорош, но не очень любит большое количество динамических подключений. На мой субъективный взгляд он просто повисает. Хотя возможно он и очухивается через какое-то время. Перезапуск его лечит и, мне лично, это кажется возможным вариантом решения. Надеюсь нагрузочное тестирование проводилось и этот аспект был учтен.

В данном случае подключений не так уж много (единицы) — т.к. к нему же не браузеры или мобильные устройства по веб-сокету подключаются, а подключаются только сервисы бэкэнда.
Но то о чем вы говорите — подвисание — вернее остановка очредей дело как я слышал от разработчиков и читал в статьях — распространенный случай и дело тут не в физическом исчерпании ресурсов а в протоколе. Могут быть различные сочетания не предусмотренных ситуаций. Например:
1) воркер получил сообщение из очереди — воркер выполнил (или не выполнил бизнес-задачу) — воркер свалился не подтвердив получение события — rabbitmq обнаружил разрыв соединения и вернул событие в очередь — очередной воркер получил сообщение… процесс идет по кругу
2) воркер получил сообщение и подвис в момент обработки выполнив (или не выполнив) бизнес-задачу и не подтвердив получение — событие не обработано и не ставится в очередь до разрыва соединения
3) воркер получил сообщение и подвис в момент обработки выполнив бизнес-задачу и подвисает не подтвердив получение — событие не обработано и rabbitmq по таймауту возвращает событие в очередь — следующий воркер получает то же сообщение, повторно выполняет бизнес-задачу и подвисает (т.к. тот же набор данных) — то таймауту rabbitmq возвращает событие в очередь… процесс идет по кругу


В зависимости от сочетаний настроек и багов могут проявляться: остановки очередей, не выполнение заданий, повторное выполнение заданий

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.