Кэширование и очереди
Тема дорожной карты · Backend разработчик
Кеширование и очереди сообщений — два взаимодополняющих компонента бэкенд-инфраструктуры, совместно решающих двойную задачу снижения задержки и увеличения пропускной способности в высоконагруженных системах. Кеширование — наиболее часто реализуемое через Redis с командами SET/GET, TTL и структурами данных вроде упорядоченных множеств — хранит часто читаемые данные в памяти, сокращая время отклика с миллисекунд (обращение к базе данных) до микросекунд и поглощая всплески чтения, которые иначе перегрузили бы PostgreSQL или MySQL. Очереди сообщений разделяют производителей и потребителей, сохраняя сообщения в брокере — Apache Kafka для высокопроизводительной потоковой передачи событий, RabbitMQ для гибкой маршрутизации с exchange и binding, или AWS SQS для serverless-нагрузок, — обеспечивая асинхронную обработку задач: отправку писем, генерацию отчётов, изменение размера изображений или оркестровку компенсирующих транзакций паттерна Saga. На практике кеширование и очереди сообщений часто используются совместно: обработчик REST API записывает в базу данных, публикует доменное событие в Kafka и обновляет кеш Redis в одном запросе, гарантируя быстрые последующие чтения, пока нижестоящие потребители асинхронно обрабатывают событие. Redis сам по себе функционирует как облегчённая очередь сообщений через команды LPUSH/BRPOP со списками или структуру данных Streams (XADD, XREAD), обеспечивая семантику at-least-once, подходящую для многих сценариев очередей задач без выделенного брокера. Мониторинг глубины очереди (лаг потребителей Kafka, длина очередей RabbitMQ) и hit rate кеша через Prometheus и Grafana необходим для обнаружения узких мест в слоях кеширования и очередей сообщений до того, как они повлияют на задержку для пользователей.
Как это работает
Кэширование и очереди использует кеши (Redis, Memcached, in-process LRU) чтобы избежать дорогого DB или compute, и очереди (Redis Streams, RabbitMQ, Kafka, SQS) чтобы развязать медленную async-работу от request-пути. Стратегии инвалидации кеша: TTL (истечение по времени), write-through (обновлять кеш на запись), event-driven (инвалидация на связанное изменение), cache-aside (читаем кеш, fallback на БД). Паттерны очередей: work queues, pub/sub, exactly-once vs at-least-once.
Когда применять
Кеш — когда замер показывает повтор дорогого compute; никогда "превентивно". TTL-кеш — для данных с допустимой staleness (5-60 секунд закрывает большинство кейсов). Очереди — когда запрос триггерит работу, не помещающуюся в response window (отправка email, обработка файлов, вызовы third-party): возвращайте 202 Accepted + status URL. Consumers очередей — это сервисы со своим мониторингом + репликами.
Типичные ошибки
Ловушки Кэширование и очереди: stale-кеш, потому что забыли инвалидировать на связанном пути (знаменитая "две сложные проблемы"); cache stampede, когда ключ протух и N запросов одновременно бьют в БД (stale-while-revalidate или singleflight); at-least-once очереди без идемпотентных consumer (дубль emails/charges); не мониторите lag очереди (тихий backlog растёт, потом взрывается).