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.