предисловие
Только лысая голова может стать сильнее.
Текст был включен в мой репозиторий GitHub, добро пожаловать, звезда:GitHub.com/Zhongf UC очень…
Оглядываясь назад на фронт:
- Изучите Redis с Zero Single Row [бронза]
- Изучите Redis с нуля, одиночная строка [серебро]
- Изучите Redis с нуля, одиночная строка [золото]
- Изучите Redis с Zero Single Row [Platinum One]
- Изучите Redis с нуля по одной строке [Platinum II]
Сегодня давайте поделимся некоторыми общими вопросами интервью Redis:
- Как исправить лавину кеша?
- Как решить проблему проникновения в кеш?
- Как обеспечить согласованность между кэшем и двойной записью базы данных?
1. Лавина кеша
1.1 Что такое Cache Avalanche?
Напомним, почему мы используем кеш (Redis):
Теперь есть проблема,Если наш кеш не работает, это означает, что все наши запросы отправляются в базу данных..
В предыдущем исследовании мы все знали, что Redis не может кэшировать все данные (Память дорогая и ограниченная), поэтому Redis необходимо установить время истечения срока действия данных и использовать две стратегии отложенного удаления + обычное удаление для удаления ключей с истекшим сроком действия.Стратегия Redis для просроченных ключей + постоянство
Если кешированные данныеУстановленное время истечения такое же, и Redis просто удалил всю эту часть данных. Это приведет к тому, что эти кеши за это времяпровалиться одновременно, все запросы к базе.
Это кеш-лавина:
- Redis зависает, и все запросы уходят в базу данных.
- Установка одного и того же срока действия для кешированных данных приведет к тому, что кеш станет недействительным в течение определенного периода времени, и все запросы будут отправлены в базу данных.
Если произойдет лавина кеша, она, скорее всего, уничтожит нашу базу данных.вниз, в результате чего вся служба будет парализована!
1.2 Как решить проблему лавины кеша?
Для «установки одинакового времени истечения для кешированных данных, кеш недействителен в течение определенного периода времени, и все запросы идут к базе данных». Эту ситуацию очень легко решить:
- Решение: добавить срок действия при кэшированиислучайное значение, это сильноОдновременно уменьшить срок действия кеша.
Для ситуации «Redis зависает, все запросы уходят в базу» у нас могут быть следующие идеи:
- До инцидента: внедрение RedisВысокая доступность(архитектура «ведущий-ведомый» + Sentinel или Redis Cluster), старайтесь избегать зависания Redis.
- Во время инцидента: В случае, если Redis действительно зависнет, мы можем установитьЛокальный кеш (ehcache) + текущий лимит (hystrix), постарайтесь избежать уничтожения нашей базы данных (по крайней мере, чтобы убедиться, что наш сервис все еще может нормально работать)
- После инцидента: Redis сохраняется, автоматически загружает данные с диска после перезагрузки,Быстро восстановить кешированные данные.
2. Проникновение в кэш
2.1 Что такое проникновение в кэш
Например, у нас есть таблица базы данных с идентификаторами, начинающимися с 1 (Положительное число):
Но может быть хакер пытается испортить мою базу данных, идентификатор каждого запросаотрицательное число. Это сделает мой кеш бесполезным, и все запросы будут уходить в базу данных, но в базе нет этого значения, поэтому она каждый раз возвращает пустую.
Проникновение в кэш относится к запросу определенногоданные, которых нет. Из-за промаха кеша и для отказоустойчивости, еслиЕсли база данных не может найти данные, они не будут записаны в кеш., что приведет к этим несуществующим даннымКаждый запрос должен идти в базу данных для запроса, теряет смысл кэширования.
Это проникновение в кеш:
- Запрошенные данные много пропускают в кеше, из-за чего запрос уходит в базу данных.
Проникновение в кэш может также привести к повреждению нашей базы данных.вниз, в результате чего вся служба будет парализована!
2.1 Как решить проблему проникновения в кеш?
Есть также два решения для решения проблемы проникновения в кеш:
- Поскольку запрошенные параметры являются недопустимыми (каждый раз запрашиваются несуществующие параметры), мы можем использовать фильтр Блума или фильтр сжатия.ранний перехват, если это не законно, не пускайте этот запрос на уровень базы данных!
- Когда мы не можем найти его в базе данных, мы также помещаем этоПустые объекты помещаются в кеш. В следующий раз, когда вы запросите его, вы сможете получить его из кеша.
- В этом случае мы обычно устанавливаем пустой объект вболее короткое время экспирации.
Использованная литература:
- Статьи серии Cache -- 5. Проблема проникновения в кэш
3. Кэш согласуется с двойной записью базы данных
3.1 Для операций чтения процесс выглядит следующим образом
При разговоре о проникновении в кеш выше также было упомянуто: если данные из базы не найдены, они не будут записаны в кеш.
Как правило, мыоперация чтениякогда есть такойфиксированная рутина:
- Если наши данные в кеше, то берем напрямую кеш.
- Если в кеше нет нужных нам данных, мы сначала запросим базу данных, а затемЗаписать данные, найденные в базе данных, в кеш.
- Наконец, верните данные в запрос
3.2 В чем проблема согласованности двойной записи между кешем и базой данных?
Если вы только запрашиваете, кэшированные данные и данные базы данных в порядке. Но когда мы хотимвозобновитьКогда? Возможны различные ситуацииНесоответствие между базой данных и кэшированными данными.
- Несоответствие здесь относится к:Данные в базе данных несовместимы с кэшированными данными
Теоретически, пока мы устанавливаемсрок действия ключа, мы можем гарантировать данные кеша и базы данныхв конечном итоге последовательныйиз. Потому что, пока срок действия кэшированных данных истекает, они будут удалены. При последующем чтении, поскольку в кэше ничего нет, вы можете проверить данные в базе данных, а затем записать данные, найденные в базе данных, в кэш.
В дополнение к установке времени истечения, нам также необходимо принять дополнительные меры дляпопытайся избежатьБаза данных несовместима с кешем.
3.3 Для операций обновления
В общем, при выполнении операции обновления у нас есть два варианта:
- Сначала работайте с базой данных, затем работайте с кешем
- Сначала работайте с кешем, затем работайте с базой данных
Во-первых, чтобы было ясно, независимо от того, что мы выбираем, мы хотим этого.Обе операции либо успешны, либо терпят неудачу одновременно. Таким образом, это перерастет вРаспределенная транзакцияПроблема.
так,Если атомарность нарушена, могут быть следующие ситуации:
- Операция базы данных прошла успешно, но операция кэша не удалась.
- Операция кэша прошла успешно, но операция базы данных не удалась.
Если первый шаг не удался, мы просто возвращаем Exception и выходим, а второй шаг вообще не будет выполняться.
Давайте проанализируем его подробно.
3.3.1 Операционный кэш
Также есть два варианта работы с кешем:
- обновить кеш
- удалить кеш
Обычно мы беремудалить кешСтратегия кэширования по следующим причинам:
- В среде с высокой степенью параллелизма, независимо от того, работаете ли вы с базой данных сначала или позже, если вы добавляете кэш обновлений, тонамного легчеЭто приводит к несогласованности между базой данных и кэшированными данными. (удалить кешпрямой и простойполно)
- Если вы каждый раз обновляете базу данных, вам приходится обновлять кеш [здесь имеется в виду сцена частых обновлений, которые потребляют определенное количество производительности], лучше удалить ее напрямую. Когда я читаю его снова, в кеше ничего нет, то я иду в базу, чтобы найти это, нахожу в базе, а затем записываю в кеш (отражаяленивая загрузка)
Исходя из этих двух пунктов, при обновлении кеша рекомендуется выполнятьУдалитьдействуй!
3.3.2 Сначала обновите базу данных, затем удалите кеш
Нормальная ситуация такова:
- Сначала работайте с базой данных, успех;
- Потом удалите кеш, тоже успешно;
Если атомарность нарушена:
- Первый шаг выполнен успешно (работа с базой данных), а второй шаг не выполнен (удаление кеша), что приведет кНовые данные в базе, старые данные в кеше.
- Если первый шаг (работа с базой данных) не удался, мы можем напрямую вернуть ошибку (исключение) без несогласованности данных.
Если в сценарии с высокой степенью параллелизма база данных несовместима с кэшированными даннымиочень низкая вероятность, и не без:
- тайникпростонедействителен
- Поток A запрашивает базу данных и получает старое значение
- Поток B записывает новое значение в базу данных
- Поток B удаляет кеш
- Поток A записывает старое найденное значение в кеш
Чтобы достичь вышесказанного, позвольте мне сказатьочень низкая вероятность:
Потому что это условие должно выполняться, когда кеш читается и кеш объявляется недействительным, и есть параллельная операция записи. На самом деле операция записи базы данных будет намного медленнее операции чтения, и таблица будет заблокирована.Операция чтения должна входить в операцию базы данных до операции записи и обновлять кэш позже операции записи., вероятность выполнения всех этих условий в принципе невелика.
Для этой стратегии это фактически шаблон проектирования:Cache Aside Pattern
Решение проблемы с удалением кеша:
- Отправить удаляемый ключ в очередь сообщений
- Употребите сообщение самостоятельно и получите ключ, который необходимо удалить.
- Продолжайте повторять операцию удаления, пока она не завершится успешно
3.3.3 Сначала удалите кеш, затем обновите базу данных
Нормальная ситуация такова:
- Сначала удалите кеш, успех;
- Затем обновите базу данных, это также успешно;
Если атомарность нарушена:
- Первый шаг завершается успешно (удаление кеша), второй шаг завершается неудачей (обновление базы данных), а данные в базе данных и кеше по-прежнему согласуются.
- Если первый шаг (удаление кеша) не удался, мы можем напрямую вернуть ошибку (Exception), и данные в базе данных и кеше по-прежнему будут согласованы.
Выглядит красиво, но если мы проанализируем это в параллельном сценарии, то поймем, что проблема все же есть:
- Поток A удаляет кеш
- Поток B запрашивает и обнаруживает, что кэш больше не существует
- Поток B обращается к базе данных, чтобы запросить старое значение.
- Поток B записывает старое значение в кеш
- Поток A записывает новое значение в базу данных
Таким образом, это также приведет к несогласованности между базой данных и кешем.
Идея решения несогласованности между БД и кешем в условиях параллелизма:
- Незавершенные операции, такие как удаление кеша, изменение базы данных, чтение кеша и т. д., дляочередьвнутри осознатьсериализовать.
3.4 Сравнение двух стратегий
Мы можем обнаружить, что обе стратегии имеют свои преимущества и недостатки:
- Сначала удалите кэш, затем обновите базу данных.
- Неудовлетворительная производительность при высокой степени параллелизма, отличная производительность при нарушении атомарности.
- Сначала обновите базу данных, затем удалите кеш (
Cache Aside PatternШаблоны проектирования)- Отличная производительность при высокой степени параллелизма, неудовлетворительная производительность при нарушении атомарности.
3.5 Другие схемы и материалы для обеспечения согласованности данных
Можно использоватьdatabusили Аликанал монитор бинлогобновить.
Использованная литература:
- Процедура обновления кэша
- Как обеспечить согласованность данных, когда кеш и база данных записываются дважды?
- Анализ схемы непротиворечивости распределенной базы данных и кэша при двойной записи
- Cache Aside Pattern
Наконец
Вот несколько общих вопросов для интервью с Redis, я надеюсь, что вы будете полезны после прочтения и получите предложение без проблем!
рад вывестигалантерейные товарыОбщедоступный номер технологии Java: Java3y. Более 200 статейоригинальныйТехнические статьи, обширные видеоресурсы, красивые карты мозга!
Отличный обзор:
Я думаю, что моя статья хорошо написана, пожалуйста, нажмитеотличный!