Комментарии 14
А как обрабатывается недоступность БД?
В случае недоступности БД обработка запроса, предусматривающего обращение к БД, завершится ошибкой, о чём будет уведомлён инициатор запроса. Отправку запроса, конечно, через какое-то время придётся повторить.
А как долго продюсер ждет подтверждения и куда он их сохраняет, а обратная связь сделана через outbox?
В нашем случае обратная связь реализована через Redis, куда продюсер записывает идентификатор и статус запроса. Консюмер должен обновить этот статус по завершении обработки. Если в течение часа (таймаут может отличаться для разных типов запросов) статус не поменяется, продюсер (или клиент, т.к. большинство запросов отслеживаются именно клиентами их отправившими) посчитает, что запрос завершился ошибкой, и клиент получит соответствующее уведомление. Поскольку Redis не связан напрямую с основной БД, говорить о том, что у нас поддерживается outbox, конечно, нельзя. Однако, замечу, что запись результатов обработки запроса в основную БД сопровождается записью в т.н. журнал запросов в этой же БД, что является дополнительным средством контроля повторной обработки запроса.
Просто запись в БД и запись в Redis не одна атомарная операция. Мы записали в БД, пишем в Redis и ловим ошибку от Redis.
Согласен! Поэтому у нас и предусмотрен журнал запросов в основной БД. Клиент, не получив подтверждения об успешной обработке запроса по истечении таймаута, сочтёт такой запрос обработанным с ошибкой и может его повторить. Но поскольку данные этого запроса уже есть в журнале, консюмер не станет обрабатывать его повторно, а просто попытается ещё раз актуализировать информацию в Redis.
Для таких случаев можно использовать DLQ (Dead Letter Queue). Физически это такой же топик в Kafka, куда направляются необработанные сообщения.
upd. перечитал статью и увидел обратную связь
Да, как вариант) Но мы ограничились уведомлением об ошибке, фактически перенеся ответственность за дальнейшую судьбу необработанного сообщения туда, где это сообщение лучше всего сохранится до лучших времен (до последующей переотправки), а именно - на клиентскую часть.
Вот это было бы интересно подробнее, как реализовано в коде.
На этот случай у нас должна быть предусмотрена обратная связь по каждому сообщению в заявленный срок
Kafka, Python и золотая рыбка