У меня есть сервис, построенный на архитектуре Microservices. Дизайн включает в себя 3 компонента, которые общаются с очередями. Компоненты системы:
- Микросервис «А» получает запрос и генерирует подзапросы. Каждый подзапрос представляет собой сообщение очереди, записанное в очередь службы «B». Каждое входящее сообщение, генерирующее несколько сообщений в очередь "B".
- Микросервис "B" получает задачу для ее выполнения и выполнения. Когда все подзапросы, выполненные службой «А», выполнены - эта служба помещает сообщение в очередь службы «C». Постановка сообщения в следующую очередь происходит только тогда, когда завершено все выполнение сообщений.
- Микросервис "C" получает сообщение и помечает строку в базе данных как завершенную.
То, как это реализовано сегодня, это шаг «1». Я создаю счетчик с начальным значением числа задач. Каждое выполнение службы "B" уменьшает этот счетчик на 1. После последнего выполнения - значение счетчика будет равно 0 - тогда поток выполнения сгенерирует новое сообщение для службы "C". Этот процесс гарантирует только 1 сообщение в очередь "C".
В принципе, это работает. Проблема с этим, является количество операций декремента.
Сегодня я реализовал этот счетчик как строку базы данных (SQL операция обновления: atomi c). Это надежно, но делает мою базу данных тяжелой жизнью.
Другие решения, о которых я думал:
- MySQL База данных: надежная, относительно медленная. Ограниченная пропускная способность.
- Redis: работает быстро, но мы не можем доверять ему (после перезапуска все данные удаляются).
- Нет SQL: неправильная обработка параллелизма. Горячие точки нарушают производительность.
Хотите знать, есть ли у такого рода проблемы лучшее решение?