intermediate
Streams
Используйте streams для append-only event logs with consumer groups, когда lightweight replay достаточно.
Streams — append-only логи с auto-generated ID (timestamp-sequence). Consumer groups позволяют воркерам забирать записи, подтверждать обработку и переигрывать pending — лёгкая альтернатива Kafka для умеренных объёмов событий.
XADD orders * type "paid" orderId "o-9" amount 42
XGROUP CREATE orders billing $ MKSTREAM
XREADGROUP GROUP billing c1 COUNT 10 BLOCK 5000 STREAMS orders >
XACK orders billing 1718448000123-0
XPENDING orders billing - + 10
| Понятие | Смысл | |---------|-------| | `XADD` | Добавить событие; `*` — auto ID | | Consumer group | Распределение работы между consumers | | `>` | Только новые сообщения | | Pending entries list | Неподтверждённые — цель для retry | | Trim (`MAXLEN` / `MINID`) | Ограничение памяти |
Streams дают at-least-once в пределах окна хранения — не бесконечную durability. Явно обрезайте поток и следите за ростом pending. Для межсервисных контрактов версионируйте поля payload.
На интервью: сравните streams с pub/sub и lists как очередью; упомяните ack и восстановление pending.
Типовые ошибки: отсутствие trimming → рост памяти; ack до завершения side effects; игнорирование poison messages в PEL; ожидание retention уровня Kafka на обычном Redis.
Компромисс — встроенные consumer groups и replay vs операционные лимиты: streams уместны для fan-out с восстановлением; отдельный log broker — при очень большом масштабе или долгом retention.
Чеклист:
- Смоделируйте поля события и версионирование.
- Создайте consumer group и политику ack.
- Осознанно обрезайте длину или возраст stream.
- Мониторьте pending entries и lag.