В FastAPI появилась официальная интеграция с Redis. Вместе с fastapi-redis-sdk мы тесно сотрудничали с командой FastAPI, чтобы определить, как должна выглядеть естественно интегрированная работа с Redis, следуя модели зависимостей FastAPI, а не навязывая Redis паттерны, чуждые этому фреймворку.
Результатом стал нативный способ использования Redis в FastAPI: управление соединениями привязано к жизненному циклу приложения, синхронные и асинхронные зависимости доступны «из коробки», а кэширование органично вписывается в механизм внедрения зависимостей (dependency injection). Это также обеспечивает практические механизмы HTTP-кэширования и заголовки cache-control, поэтому решение выходит за рамки простого подключения и делает распространенные веб-паттерны первоклассными гражданами фреймворка.
можно использовать со всеми вариантами FastAPI, self-managed и FastAPI Cloud — новой управляемой платформой для развертывания и эксплуатации приложений FastAPI. FastAPI Cloud сейчас находится в стадии публичного бета-тестирования, и Redis Cloud доступен там как нативная интеграция. Это дает пользователям простой способ подключить существующую базу данных Redis или создать бесплатную прямо из панели управления FastAPI Cloud. Это сокращает путь к производственным сервисам и снижает трудозатраты, позволяя поддерживать кэширование уже сегодня, а также другие сценарии использования, которые находятся в разработке в рамках официально поддерживаемого SDK fastapi-redis-sdk.
Использование SDK
Установка пакета так же проста, как и любого другого пакета, доступного в PyPI:
Затем, чтобы привязать SDK к жизненному циклу вашего приложения, вам нужно вызвать:
Кэширование данных
На этом этапе вы готовы использовать функциональность кэширования фреймворка. Вы просто используете внедрение зависимостей и настраиваете правило кэширования:
Теперь все берется на себя автоматически:
- GET-эндпоинт кэшируется с временем жизни (TTL) 60 секунд, поэтому повторные запросы для одного и того же идентификатора пользователя будут извлекаться из кэша Redis, а не из базы данных.
- DELETE-эндпоинт автоматически аннулирует любые записи в кэше для предоставленного ID.
- PUT-эндпоинт может выполнять своего рода «магию»: если операция сохранения прошла успешно (и только в этом случае), мы обновим кэш новым сохраненным значением, избавившись от первого вызова GET после этого.
Группа вытеснения (eviction group), с другой стороны, может использоваться для идентификации данных, которые должны вытесняться вместе, что поможет улучшить согласованность кэша в тех случаях, когда некоторые кэшированные записи имеют смысл только вместе. Однако это требует определенных затрат, так как для обеспечения атомарности операции вытеснения данные сохраняются в одном слоте в случае кластерной среды.
Чтобы узнать больше о кэшировании, посетите раздел о кэшировании в нашем руководстве.
Ограничение частоты запросов (Rate limiting)
Аналогичным образом вам нужно настроить SDK для отслеживания правил ограничения частоты запросов:
Затем это делается очень просто:
Или, если вы хотите обрабатывать как кратковременные всплески, так и устойчивую нагрузку, вы можете объединить две отдельные декларации ограничения частоты с разными областями видимости, чтобы гарантировать, что они учитываются отдельно и не перезаписывают друг друга:
Подробнее об ограничении частоты запросов можно узнать в разделе об ограничении частоты запросов онлайн-руководства.
Конфигурация
Библиотека fastapi-redis-sdk следует модели конфигурации Pydantic Settings, как и рекомендует команда FastAPI, для обеспечения переносимости и безопасности типов. Обычно (в облачных средах, таких как FastAPI Cloud) параметры конфигурации внедряются как переменные окружения; и до тех пор, пока имена верны, они будут автоматически использоваться развернутыми эндпоинтами.
Таким образом, для облачных сред конфигурация будет выглядеть так:
В средах разработки вы можете использовать отдельные файлы .env:
Полный список параметров конфигурации можно увидеть в соответствующем разделе руководства.
Продвинутые рецепты
При внедрении CacheBackend или RateLimitBackend в ваши эндпоинты (синхронные или асинхронные — это работает для обоих) вы можете реализовать некоторые продвинутые рецепты кэширования и ограничения частоты запросов, включая, помимо прочего, те, что перечислены ниже.
Кэширование
Условное кэширование: кэшировать только при соблюдении определенных бизнес-правил.
Каскадное аннулирование: между группами вытеснения или когда группы вытеснения не могут быть использованы.
Динамический TTL: установка времени жизни на основе самих данных.
Конечно, все эти паттерны можно использовать вместе для продвинутых сценариев. См. раздел в руководстве, посвященный этим темам, для получения дополнительной информации.
Ограничение частоты запросов
Ограничение нисходящего ресурса: когда вы хотите защитить ресурс, от которого зависит ваш эндпоинт, а не сам эндпоинт.
Справедливость для каждого арендатора (Per-tenant fairness): когда у вас есть «шумный сосед» в мультиарендной среде.
Бюджет токенов: вычисление стоимости во время выполнения на основе использования.
Попробуйте сегодня
Если вы хотите попробовать SDK, ознакомьтесь с , guide и пакетом PyPI. Мы будем рады, если вы протестируете его, поделитесь отзывами и предложите улучшения или новые функции.
