разбивка кеша
Сбой кеша означает, что ключ очень горячий, и он постоянно несет большой параллелизм, и большой параллелизм сосредоточен на доступе к этой точке.Когда срок действия ключа истечет, непрерывный большой параллелизм пробьет кеш и напрямую запросит базу данных. как прорезать дыру в барьере.
Итак, как решить эту проблему?
Есть много способов решить эту проблему, например, сделать кэш резидентным в памяти, использовать асинхронное обновление и др. Здесь мы представляем использование распределенных блокировок для решения таких проблем.
Главная идея
- 1. Получаем данные из кеша и возвращаем напрямую, если данные получены.
- 2. Если данные не получены из кеша, их нужно прочитать из базы данных, чтобы предотвратить большое количество одновременных прямых обращений к базе данных, необходимо добавить распределенную блокировку, чтобы гарантировать, что только один запрос обращается базу данных.
- 3. При успешной блокировке делаем три шага: 1) считываем данные из базы, 2) записываем данные в кеш, 3) удаляем распределенную блокировку.
- 4. Если блокировка не удалась, дайте процессу приостановиться на некоторое время и повторите шаг 1.
- 5. Чтобы предотвратить возникновение непредвиденных ситуаций, нам нужно установить порог, Когда количество раз, полученных в кеше, превышает порог, программа будет выходить напрямую, чтобы предотвратить блокировку большого количества параллелизма.
Redis реализует распределенные блокировки
Мы используем redis для реализации распределенных блокировок здесь, используя следующий оператор
SET [KEY] [RAND_NUM] EX [LOCK_TIME] NX
- КЛЮЧ: Ключ замка, указанный в соответствии с реальной ситуацией.
- RAND_NUM: случайное число для предотвращения случайного удаления блокировки из-за сбоя блокировки из-за длительного времени выполнения.
- EX: Указывает, что время истечения этой блокировки установлено для предотвращения взаимоблокировки после истечения срока действия.
- LOCK_TIME: сколько секунд истекает в секундах.
- NX: Указывает, что эта блокировка создается, если вторичная блокировка не существует.
Если блокировки не существует, Redis вернет "ok", указывая на то, что блокировка была создана успешно. Когда блокировка существует, Redis возвращает "NULL". Мы можем определить, было ли создание успешным, в соответствии с возвращаемым значением.
сцены, которые будут использоваться
Как видно из блок-схемы, обновление кеша приведет к блокировке параллельных потоков.
Здесь есть два ключевых момента, влияющих на производительность системы:
- 1. Чем больше количество одновременных кэшей, тем больше влияние на производительность системы.
- 2. Чем больше времени требуется для обновления одного кэша, тем больше это влияет на производительность системы.
Таким образом, сценарий использования этого метода: данные простого кэша без точки доступа (небольшой параллелизм, короткое время обновления).