Оригинальное содержание в этой ветке Твиттера
Привет, Дев,
Вы наверняка слышали о Kafka, RabbitMQ, SQS, потребителях, асинхронной обработке и т.д., верно?
Знаете ли вы, что такое или слышали об очередях DEAD-LETTER и RETRY? Если вы хотите понять основную концепцию этих двух вещей, вставьте еще.
cc @sseraphini
↓
Давайте подумаем о гипотетическом сценарии открытия счета в банке в два этапа:
1-) Отправка данных предложения для открытия счета.
2-) Асинхронный процесс оценки и выполнения самого открытия счета.
Это упрощенный сценарий.
Когда мы говорим об очередях повторов и “мертвых букв” (или тем, в случае Kafka), мы связываем их с потреблением сообщений. Тот, кто публикует сообщения для обработки, даже не должен знать о таких вещах, понятно?
Итак, давайте подумаем о случае неудачи на стороне потребителя.
Здесь, в сценарии отказа, при обращении к внешней службе, что-то случилось с сервером – произошел тайм-аут.
Остановитесь и подумайте, как бы вы поступили в этом случае. Вы не можете не одобрить предложение из-за тайм-аута службы – что-то случилось с автором предложения.
Естественнее всего было бы попробовать еще раз.
Давайте сделаем так, чтобы обработка была почти равномерной – без добавления тяжелых компонентов в архитектуру.
Первым шагом является отправка сообщения, которое не удалось обработать, в очередь повторных попыток.
Вам может быть интересно, стоит ли попробовать несколько раз, прежде чем отправлять его в очередь повторных попыток. Да, вы можете это сделать, но это может стать проблемой, если тайм-аут будет длиться слишком долго.
Давайте продолжим отправку сообщения для повторной попытки при первом тайм-ауте, хорошо?
Теперь нам нужно выполнить второй шаг – вернуть это сообщение компоненту, который обрабатывает предложения.
В зависимости от технологии узоры немного меняются. Но основная идея остается прежней: дать новый шанс для обработки сообщения. Это цикл.
В RabbitMQ используется комбинация истечения срока действия сообщений и обмена “мертвыми буквами”. В Kafka вы можете использовать набор из N тем повторных попыток. И т.д.
Опять же, идея остается прежней: сгенерировать цикл для новой попытки обработки сообщения.
Говоря о циклах, важно отметить, что вы не должны потреблять сообщение из очереди повторных попыток сразу после того, как оно туда попало. В противном случае это может привести к образованию огромной очереди сообщений, если ошибка сохраняется в течение длительного времени и постоянно поступают новые сообщения.
Чтобы обойти эту проблему интервала повторной обработки, необходимо добавить некоторое время между повторными попытками. Мы можем использовать механизмы истечения срока действия или даже концепцию, называемую экспоненциальным отступлением. Но сейчас не беспокойтесь об отступлении.
Пкп, ты все еще здесь. Эта нить хуже, чем Lost, верно? Сериал, который никогда не закончится. Но продержитесь еще немного – вы здесь уже так долго, еще немного – и вы не умрете.
Сделайте несколько фотографий красивых и горячих людей, чтобы немного проветриться, но потом продолжите здесь, хорошо? Это еще не конец.
Говоря о вещах, которые не заканчиваются, вы должны остановиться, если после N попыток ошибка все еще сохраняется.
Если ошибка сохраняется ИЛИ для неустранимых ошибок. Тайм-аут является восстанавливаемой ошибкой. Но в случае недействительного сообщения вам нечего делать – например, недействительный CPF.
Что ж, это подводит нас к важной концепции в этом мире переработки, повторных попыток, мертвой буквы:
- Переходные или временные ошибки.
- Неустранимые или необратимые ошибки.
Помни об этом, хорошо?
Теперь давайте, наконец, поговорим о мертвой букве. Dead-letter – это очередь, в которую мы отправляем сообщения, когда вы решили, что вам больше нечего делать. Либо из-за слишком большого количества попыток переработки, либо из-за неустранимой ошибки.
Это так просто.
Для мертвых писем можно установить другого потребителя, который будет что-то делать, сигнализацию, срабатывающую при достижении X количества сообщений, или даже вручную исследовать сообщения.
Dead-letter – это для того, чтобы не выбрасывать сообщения в безвестности.
Клянусь, все заканчивается, я просто дам вам несколько справочных ссылок, и мы попрощаемся, хорошо?
Модели повторной обработки с помощью Kafka
https://eng.uber.com/reliable-reprocessing/
RabbitMQ и обмены “мертвыми буквами” (повторные попытки выполняются при обмене “мертвыми буквами” в RabbitMQ)
https://rabbitmq.com/dlx.html
Экспоненциальный откат (он используется не только для очередей повторных попыток, ок).
https://en.wikipedia.org/wiki/Exponential_backoff
Спасибо большое за мораль, что дочитали до конца. Именно для вас я посвящаю много времени написанию этого материала! ❤️
Поцелуй и объятия.