Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 На сегодняшний день время отклика на запрос является критичной метрикой для любого проекта. Пользователи не очень любят, когда web-страница формируется долго (несколько секунд или дольше). Поэтому разработчики стремятся уменьшить время ответа на запрос клиента, для чего прибегают к кэшированию.

2 Представим, что разрабатывается торговая платформа и есть личный кабинет с аналитикой сделок пользователя. Нужно выводить количество сделок, прибыль, средний оборот и тд. Большинство метрик являются агрегационными, то есть их нужно вычислять. Если использовать только РСУБД, то среднее время ответа будет сотни миллисекунд, а при большой нагрузке - секунды. Можно подключить подходящие аналитические базы данных, но чаще всего это слишком дорого в средних проектах.

3 Самая распространенная практика решения сегодня - это кэш. Сложные вычисления кэшируются, то есть записываются в оперативную память. Обращение к оперативной памяти займет сотни наносекунд, примерно в миллион раз быстрее, чем вычислить данные из РСУБД. Новая схема взаимодействия будет включать кэширующий сервер. Алгоритм следующий:

4 <ol><li>клиент делает запрос</li>

5 <li>бекенд проверяет кэш. Если значение есть в кэше, то оно просто возвращается клиенту</li>

6 <li>если значения в кэше нет, то сервер вычисляет все из базы, записывает числа в кэш и отдает клиенту. Теперь все последующие запросы будут возвращать результаты вычислений из кэша</li>

7 </ol><h2>Подводные камни</h2>

8 Как и любое решение в разработке, кэширование - не серебряная пуля и имеет свои недостатки. Несколько моментов, которые стоит держать в уме при использовании кэша:

9 <ul><li>приложение должно уметь работать без кэша. Кэширующий сервер упал или недоступен? Пользователь все равно должен получать все данные просто с небольшой задержкой. Завязывать какую-то логику продукта на кэш (например, хранить данные аналитики только в кэше) - нельзя, потому что это ненадежное хранилище.</li>

10 <li>с введением нового звена в архитектуру всегда следует усложнение разработки и поддержки продукта. Проверка и запись значений в кэше - это дополнительная логика в коде, которая требует дополнительного времени на тестирование и исправление потенциальных ошибок.</li>

11 <li>сколько времени должно храниться значение в кэше? Что делать, если значение невалидно, так как пользователь открыл новую сделку или получил прибыль? Эти вопросы будут возникать постоянно, и в каждом проекте ответы будут уникальными.</li>

12 </ul>Redis чаще всего используют именно как кэширующий сервер. Он имеет богатый встроенный функционал для этих целей. Рассмотрим основные команды, с помощью которых кэшируют значения в Redis.

13 <h3>Кэширование</h3>

14 Представим, что нужно записать количество сделок пользователя в кэш. Запишем, что у пользователя с ID33имеется5сделок. Используем обычную команду set:

15 Данные записаны. Однако они будут храниться вечно до следующей перезагрузки сервера или пока не будут удалены вручную. Одно из основных свойств кэша - это то, что он хранится короткий промежуток времени. Данных может быть много, а ресурсы серверов не бесконечны. К счастью в Redis можно указать время жизни ключа (время экспирации), по истечении которого ключ будет удален. Для этого достаточно добавить постфикс ex количество_секунд к команде set:

16 Проверить, через сколько ключ удалится можно командой ttl:

17 В данном случае ключuser:33

18 исчезнет через 115 секунд.

19 Если попытаться получить значение спустя это время, то вернется пустой ответ:

20 Время жизни можно задавать не только в секундах, но и в миллисекундах с помощью префикса px количество_миллисекунд:

21 Проверка времени жизни осуществляется командой pttl:

22 Вывод выше показывает, что ключuser:33

23 исчезнет через 7484 миллисекунд (~7.4 секунд).

24 Для установки времени жизни для уже существующего ключа используется команда expire

25 <h3>Инвалидация кэша</h3>

26 Любой кэш может стать неактуальным раньше времени жизни. В нашем примере со сделками это может произойти при возникновении новой сделки у пользователя. В этом случае нужно удалить ключ в кэше, чтобы при следующем запросе произошел пересчет значения. Может возникнуть вопрос: а почему бы просто не добавить значение в имеющийся ключ? В данном примере это было бы наилучшим решением, но действовать необходимо не "в лоб". При увеличении значения двумя командами get + set может получиться неконсистентное состояние (подробнее эта проблема будет рассмотрена в следующем уроке). Также обновление значения не всегда возможно, например, в случае если значение - это среднее арифметическое.

27 Удаление ключа происходит командой del:

28 Вернувшееся значение1означает, что ключ существовал и был успешно удален. Если ключа не было, то вернулся бы 0.

29 Иногда требуется удалить тысячи ключей за раз. Например, у поставщика цен на акции произошел сбой и все сделки за период сбоя оказались недействительными. В этом случае нельзя использовать N вызовов команды del, потому что это будет выполняться очень долго и заберет все ресурсы Redis. Для множественного удаления существует команда unlink, которую можно безопасно использовать в продакшен-среде:

30 Все ключи для удаления указываются через пробел. Стоит учитывать, что ключи удаляются асинхронно, то есть могут существовать после unlink короткий промежуток времени.

31 <h2>Резюме</h2>

32 <ul><li>кэш ускоряет время ответа клиенту, но не заменяет надежных хранилищ</li>

33 <li>в Redis ключ с временем жизни в секундах записывается командой set ключ значение ex количество_секунд, а в миллисекундах командой set ключ значение px количество_миллисекунд</li>

34 <li>инвалидация - неотъемлемая часть работы с кэшем. Чтобы удалить атомарный ключ, используется del ключ. Для удаления множества ключей существует команда unlink ключ1 ключ2 ...</li>

35 </ul>