34 lines
4.3 KiB
Markdown
34 lines
4.3 KiB
Markdown
|
---
|
|||
|
|
aliases:
|
|||
|
|
tags:
|
|||
|
|
- maturity/🌱
|
|||
|
|
date: 2024-11-12
|
|||
|
|
---
|
|||
|
|
При реализации [[../Идемпотентность|идемпотентности]] в системах, где требуется многократная обработка событий или вызовов, [[../../../meta/zero/00 Redis|Redis]] может быть использован как ключевой инструмент для предотвращения повторной обработки сообщений. Данное решение подходит для различных систем обмена сообщениями, таких как [[../../../../../_inbox/00 Kafka|Kafka]], [[../../system-design/gRPC|gRPC]], [[../../network/HTTP|HTTP]], и других видов асинхронных или синхронных вызовов.
|
|||
|
|
### Основной подход
|
|||
|
|
Каждое сообщение или запрос должен иметь уникальный идентификатор, обычно называемый **requestId**. Этот идентификатор присваивается при создании сообщения или вызова и передаётся вместе с ним в процессе обработки. Потребитель, получая сообщение, сначала проверяет наличие **requestId** в Redis. Этот подход позволяет контролировать, было ли сообщение уже обработано и в каком оно состоянии.
|
|||
|
|
|
|||
|
|
Алгоритм выглядит следующим образом:
|
|||
|
|
1. **Получение сообщения**: Потребитель получает сообщение, извлекает **requestId** и проверяет его наличие в Redis.
|
|||
|
|
1. Если **requestId** уже существует в Redis и статус обработки указывает на **COMPLETED**, потребитель ничего не делает и отправляет **ack** (подтверждение) в Kafka (или другой источник).
|
|||
|
|
2. **Обработка сообщения**: Если **requestId** отсутствует в Redis или статус обработки указывает на **FAILED**, потребитель, то потребитель обрабатывает сообщение. Перед обработкой статус в Redis обновляется на **IN_PROGRESS** с TTL, например, 40 секунд.
|
|||
|
|
3. **Запись результата**:
|
|||
|
|
- После успешной обработки статус в Redis обновляется на **COMPLETED**, и устанавливается длительный TTL, например, на 3-24 часа, чтобы сигнализировать, что это сообщение уже было успешно обработано и повторная обработка не требуется.
|
|||
|
|
- Если при обработке возникает ошибка, статус обновляется на **FAILED** и потребитель отправляет **nack** в Kafka (или другой источник).
|
|||
|
|
### Рекомендации по реализации
|
|||
|
|
- **Уникальность requestId**: Генерируйте **requestId** таким образом, чтобы обеспечить его уникальность в пределах всей системы, например, используя UUID или другие подходящие алгоритмы.
|
|||
|
|
- **Оптимальный TTL**: Выберите TTL в зависимости от требований к ретеншену данных. Слишком короткий TTL может привести к потере информации об обработке, а слишком длинный — к переполнению Redis.
|
|||
|
|
***
|
|||
|
|
## Мета информация
|
|||
|
|
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
|
|||
|
|
**Родитель**:: [[../Идемпотентность|Идемпотентность]]
|
|||
|
|
**Источник**::
|
|||
|
|
**Создана**:: [[2024-11-12]]
|
|||
|
|
**Автор**::
|
|||
|
|
### Дополнительные материалы
|
|||
|
|
-
|
|||
|
|
|
|||
|
|
### Дочерние заметки
|
|||
|
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
|||
|
|
|