Lists

Списки Redis — двусвязные списки строк: простые FIFO/LIFO очереди, буферы recent items и лёгкий staging задач. Producers делают push; consumers — pop или блокируются в ожидании работы.

					LPUSH jobs:email '{"id":1,"to":"a@b.c"}'
BRPOP jobs:email 30          # blocking consumer, таймаут 30 с
RPUSH logs:api "2026-06-15 ok"
LTRIM logs:api 0 999         # оставить последние 1000 записей
LLEN jobs:email
				

| Операция | Поведение | |----------|-----------| | `LPUSH` / `RPUSH` | Добавление в голову или хвост — O(1) | | `LPOP` / `RPOP` | Удаление одного элемента | | `BRPOP` / `BLPOP` | Блокировка до элемента или таймаута | | `LTRIM` | Фиксированное окно — паттерн ring buffer |

Списки сами по себе не durable message queue: извлечённый элемент исчезает, если нет reliable-queue паттерна (`RPOPLPUSH` в processing list или Streams). По умолчанию — at-most-once.

На интервью: опишите требования к очереди и почему подойдут lists, streams или настоящий broker.

Типовые ошибки: критичные workflow на lists без ack/retry; неограниченный рост списка; `BRPOP` без аналога visibility timeout; гонки нескольких consumers без координации.

Компромисс — простота и низкая latency vs гарантии доставки: lists уместны для best-effort распределения работы; durability и consumer groups — у streams или внешней очереди.

Чеклист:

• Сформулируйте семантику доставки (at-most-once vs at-least-once).
• Ограничивайте размер списка через `LTRIM` при буферизации.
• Объясните blocking consumer и таймауты.
• Назовите, когда lists заменяют Streams.