Используйте ограниченный локальный кеш ещё действующего токена и singleflight для его обновления, чтобы запросы не штормовали Auth Service. Истёкший или недопустимый токен нельзя принимать ради доступности.
ZSET хранит уникальных участников с числовыми score и поддерживает порядок и диапазоны; Hash хранит пары полей и значений без такой сортировки. Внутреннее представление ZSET зависит от размера.
Распространённые стратегии — cache-aside, read-through, write-through, write-behind и обновление или удаление кеша при записи. Redis хранит значения, но выбранную согласованность обеспечивает вся схема.
В коде синхронный Redis блокирует async-обработчик, запросы к БД выполняются по одному ID, а отсутствие продукта приводит к ошибке. Нужны валидация входа, пакетное чтение и контролируемый кеш.
BGSAVE создаёт дочерний процесс через fork: ребёнок записывает снимок, а родитель продолжает обслуживать клиентов. Copy-on-Write позволяет сначала разделять страницы памяти и копировать их при изменении.
Ключи и узлы отображаются на хеш-кольцо; ключ обслуживает следующий узел по кольцу. При изменении состава переносится часть диапазонов, а не почти все ключи, как при hash(key) % N.
Типовой поток: склад публикует изменения в Kafka, каталог обновляет модель чтения и кеш Redis, а frontend получает данные через API. Реальная схема и формула популярности зависят от проекта.
Gossip в Redis Cluster распространяет сведения об узлах, но сам по себе не является алгоритмом консенсуса. Отдельные правила определяют подтверждение отказа и выбор новой primary-реплики.
Lua-скрипт выполняет проверку и изменение данных без вклинивания других команд Redis. Поэтому счётчик, лимит и TTL можно согласованно обновить одним вызовом вместо гонки между GET и SET.
Redis применяют для счётчиков, ограничения частоты, рейтингов, временного состояния, очередей и потоков событий. Выбор структуры зависит от требуемых операций и гарантий сохранности.
В gossip узлы периодически обмениваются сведениями с частью соседей, распространяя состояние по кластеру. Отсутствие ответа вызывает подозрение в отказе, но не доказывает физическую смерть узла.
Redis может атомарно проверить остаток и создать резерв через Lua-скрипт, не выполняя отдельные read и write. Но защита от overselling требует согласования долговечного учёта и отказов.