Списки и хэши
Тема дорожной карты · Redis
Списки Redis — это упорядоченные коллекции строковых элементов, реализованные в виде связных списков, поддерживающие эффективные операции добавления и извлечения с обоих концов через LPUSH/RPUSH и LPOP/RPOP. Списки являются естественной структурой данных для очередей сообщений, очередей задач и лент активности на базе Redis, где BRPOP обеспечивает блокирующую семантику извлечения для рабочих-потребителей. Хэши Redis сопоставляют строковые имена полей со строковыми значениями в рамках одного ключа, что делает их идеальными для представления объектов, таких как профили пользователей или записи конфигурации, с помощью HSET и HGET. Как списки, так и хэши используют компактные in-memory кодировки (ziplist/listpack) для небольших коллекций, автоматически переходя к представлениям на основе связного списка или хэш-таблицы по мере роста. Понимание того, когда использовать списки Redis, а когда хэши, фундаментально для проектирования эффективных моделей данных Redis в веб-приложениях.
Как это работает
Списки и хэши — два фундаментальных типа. Lists (LPUSH/RPUSH/LPOP/RPOP/LRANGE) — связные списки: быстрый push/pop с обоих концов (O(1)), медленный random access (O(N)). Hashes (HSET/HGET/HGETALL/HMSET) — мэп поле→значение внутри одного ключа: идеально для object-like данных (юзер с name, email, plan). Оба отлично подходят для queue-паттернов (BLPOP/BRPOP — блокирующие) и per-entity хранения атрибутов.
Когда применять
Lists — для очередей (LPUSH producer + BRPOP consumer — базовая work queue), таймлайнов недавней активности (LPUSH + LTRIM хранит последние N), упорядоченных логов. Hashes — когда у одной сущности много полей и вы запрашиваете по ID сущности: эффективно по памяти (один ключ на сущность) и атомарные апдейты по полю. Redis Streams (настоящий append-only лог с consumer groups) — предпочитайте list-based очередям на production-масштабе.
Типичные ошибки
Ловушки Списки и хэши: гигантский HGETALL на хеше с 100K полей (блокирующая команда; весь хеш сериализуется); lists как очередь сообщений с at-least-once (нужны ack — используйте Redis Streams); LRANGE 0 -1 на миллион-элементном списке (network buffer старит всех); неограниченный рост списка (max length через LPUSH ... LTRIM 0 N-1).