Всем привет !! Недавно я готовился к стажировке Dcard по бэкенду, и эта серия статей (Crazy Go Day) — это навыки разработки, которые я gjkexbk за это время.
Что такое редис?
Redis — это база данных которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа, с открытым исходным кодом, которая более эффективна при доступе к данным и вычислениях по сравнению с другими классическими базами данных, такими как PostgresSQL и MongoDB.
Хотя в настоящее время Redis можно использовать в качестве основной базы данных (с модулями Redis), в статье я использую его в качестве базы хранения данных в кеше .
Случаи, требующие кэширования
Многие пользователи одновременно получают доступ к одной и той же службе API за короткий промежуток времени.
Некоторые пользователи пытаются получить доступ к несуществующей службе API.
Вышеуказанные случаи являются очень распространенными и базовыми при работе API.
Таким образом, одним из решений является кэширование в мидлваре, чтобы ошибочный запрос не обращался к нашим службам контроллера, которые выполняют запросы к базе данных.
Решение этих ошибок: одновременный доступ многих пользователей
Когда запрос в первый раз посылается на ресурс «А», мы будем подключаться к базе данных, чтобы найти для него этот «А».
После выполнения запроса к базе данных мы сохраним «A» в нашей базе данных кеша с ограничением по времени истечения срока действия. Причина, по которой нам необходимо добавить ограничение по времени , заключается в том, что база данных кеша НЕ имеет много памяти, и за использования облачного хранилища нужно платить.
Предположим, что через несколько секунд мы получаем другой запрос, запрашивающий ресурс «А». Теперь когда он поступит к нашему API, ресурс «А» будет немедленно возвращен из кеша!
Другими словами, все запросы за этот период времени, запрашивающие ресурс «А», могут быть выполнены быстрее, чем выполнение запросов к базе данных.
Теперь мы поняли концепцию , теперь давайте углубимся в реализацию в Go :)
Во-первых, поскольку наш объект данных URL имеет свое собственное время экспирации срока действия, что может вызвать противоречие со временем экспирации хранения данных в кеше, нам необходимо выполнить некоторые вычисления, как указано в коде.
После расчета мы можем поместить исходный контент URL в кеш со сроком действия.
Теперь мы решили первую проблему эффективности!
Когда пользователь впервые попытается получить доступ к несуществующему URL-адресу «B», мы запросим базу данных, чтобы проверить, существует ли этот URL-адрес или нет.
Убедившись, что этот URL-адрес не существует, мы записываем его в наш кеш.
В следующий раз, когда другой пользователь попытается получить доступ к тому же несуществующему URL-адресу, скрипт вернет клиенту «RESOURCE_NOT_EXIST»!
Теперь давайте напишем код
Когда мы не можем найти что-то в БД в нашем контроллере, мы сохраняем пару ключ-значение, например <url_id>: NOT_EXIST, в redis.
Так что в следующий раз мы будем знать, что этот URL не существует. Что если будет создан другой url_id после того, как мы запишем его для NOT_EXIST?
Теперь мы заканчиваем все нашу работы по кэшированию. И напишем полую скрипт.
Мидлвар сначала проверит входной параметр url_id, а затем подтвердит, что запись url_id означает EXIST или NOT_EXIST!
Таким образом мы написали наш скрипт для кэширования.
Исходный код здесь.
Спасибо, что уделили время статье.