Struchkov Mark
9a5643fd64
All checks were successful
continuous-integration/drone/push Build is passing
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) -->
|
||
|