Рекомендовано 👍: руководство по обучению/интервью по Java близко к 100 тысячам звезд:JavaGuide
Я вижу, что многие друзья пишут в своих резюме»Умение пользоваться кешем", но меня спросили"3 общие стратегии чтения и записи для кэшированияно он был ошеломлен.
На мой взгляд, причина этой проблемы в том, что когда мы изучали Redis, мы могли просто писать какие-то демки, но не обращали внимания на стратегию чтения и записи кеша, либо вообще не знали об этом.
Тем не менее, понимание трех распространенных стратегий чтения и записи кеша очень полезно для использования кеша в реальной работе и для ответов на вопросы о кеше на собеседованиях!
Ниже я кратко представлю свое понимание этих трех стратегий чтения и записи кэша.
Кроме того,Эти три стратегии чтения и записи кэша имеют свои преимущества и недостатки, и лучшей из них не существует, нам нужно выбрать более подходящую в соответствии с конкретными бизнес-сценариями.
Личные возможности ограничены. Если есть что-то, что нужно дополнить/улучшить/изменить в статье, пожалуйста, укажите это в комментариях и развивайтесь вместе! —— Любите своего брата-проводника
Шаблон кэширования в стороне
Cache Aside Pattern — это шаблон чтения и записи кэша, который мы используем чаще, и он больше подходит для сценариев с большим количеством запросов на чтение.
В шаблоне Cache Aside сервер должен поддерживать как БД, так и кеш, и результат БД должен иметь преимущественную силу.
Давайте посмотрим на шаги чтения и записи кэша в этом режиме стратегии.
Напишите:
- Сначала обновите БД
- Затем удалите кеш напрямую.
Простая картинка нарисована, чтобы помочь вам понять этапы написания.
читать :
- Чтение данных из кеша и возврат сразу после чтения
- Если его нельзя прочитать из кеша, прочитать данные из БД и вернуться
- Затем поместите данные в кеш.
Простая картинка нарисована, чтобы помочь вам понять шаги чтения.
Вам недостаточно только понять вышеизложенное, нам также необходимо понять принцип.
Например, интервьюер, скорее всего, спросит: «Можно ли в процессе записи данных сначала удалить кеш, а потом обновить БД?"
Отвечать:Это точно не сработает! потому что это может вызватьДанные базы данных (БД) и кеша (Cache) несовместимыПроблема. Зачем? Например, если запрос 1 сначала записывает данные A, а затем запрос 2 считывает данные A, весьма вероятно, что это приведет к несогласованности данных. Этот процесс можно просто описать так:
Запрос 1 сначала удаляет данные A в кеше -> Запрос 2 считывает данные из БД -> Запрос 1, затем обновляет данные A в БД.
После того, как вы ответите на этот вопрос, интервьюер может продолжить: "В процессе записи данных есть ли проблема сначала обновить БД, а потом удалить кеш?"
Отвечать:Теоретически несогласованность данных все же может возникнуть, но вероятность очень мала, потому что скорость записи кеша намного быстрее скорости записи базы данных!
Например, запрос 1 сначала считывает данные A, затем запрос 2 записывает данные A, и если данных A нет в кэше, также может возникнуть несогласованность данных. Этот процесс можно просто описать так:
Запрос 1 считывает данные A из БД -> Запрос 2 записывает обновленные данные A в базу данных и удаляет данные A из кеша -> Запрос 1 записывает данные A в кеш.
Теперь давайте проанализируемПодводные камни шаблона Cache Aside.
Дефект 1: Проблема в том, что данные первого запроса не должны быть в кеше
Решение: Горячие данные можно заранее поместить в кеш.
Дефект 2: если операция записи выполняется часто, данные в кэше будут часто удаляться, что повлияет на частоту попаданий в кэш.
Решение:
- Сценарий строгой согласованности между данными базы данных и кэша: при обновлении БД кэш также обновляется, но нам нужно добавить блокировку/распределенную блокировку, чтобы гарантировать отсутствие проблем с потокобезопасностью при обновлении кэша.
- Сценарии, в которых данные базы данных и кеша несовместимы, могут быть временно разрешены: при обновлении БД кеш также обновляется, но к кешу добавляется относительно короткое время истечения, так что даже если данные несогласованны, влияние будет относительно маленький.
Чтение/запись через шаблон
В шаблоне Read/Write Through сервер рассматривает кэш как основное хранилище данных, считывает данные из него и записывает в него данные. Служба кеша отвечает за чтение и запись этих данных в БД, освобождая приложение от ответственности.
Друзья этой стратегии чтения и записи кеша также должны обнаружить, что она очень редко встречается в процессе разработки. Помимо влияния на производительность, высокая вероятность связана с тем, что распределенный кеш Redis, который мы часто используем, не обеспечивает функцию кеша для записи данных в БД.
Пишите через:
- Сначала проверьте кеш, если кеш не существует, обновите БД напрямую.
- Если он существует в кеше, сначала обновите кеш, а затем служба кеша самостоятельно обновит БД (Обновлять кеш и БД синхронно).
Простая картинка нарисована, чтобы помочь вам понять этапы написания.
Прочитать:
- Чтение данных из кеша и возврат непосредственно при чтении.
- Если он не может быть прочитан, сначала загрузите его из БД, запишите в кеш и верните ответ.
Простая картинка нарисована, чтобы помочь вам понять шаги чтения.
Шаблон Read-Through на самом деле просто инкапсулирован поверх шаблона Cache-Aside. В соответствии с шаблоном Cache-Aside, когда возникает запрос на чтение, если соответствующие данные не существуют в кеше, клиент несет ответственность за запись данных в кеш, а шаблон сквозного чтения — это сама служба кеша для записи кеша. .Прозрачен для клиента.
Как и шаблон Cache Aside, шаблон Read-Through также имеет проблему, заключающуюся в том, что данные первого запроса не должны кэшироваться, а горячие данные могут быть помещены в кэш заранее.
Write Behind Pattern (асинхронная запись в кэш)
Шаблон отложенной записи очень похож на шаблон сквозного чтения/записи, оба из которых обрабатываются службой кэширования для чтения и записи кэша и БД.
Тем не менее, они очень разные:Сквозное чтение/запись обновляет кеш и БД синхронно, в то время как отложенное кэширование обновляет только кеш, а не БД напрямую, а вместо этого обновляет БД в асинхронном пакете.
Очевидно, что этот метод создает большие проблемы с согласованностью данных, например, если данные кеша могут не обновлять БД асинхронно, служба кеша может зависнуть.
Эта стратегия также очень редко встречается в нашем обычном процессе разработки, но это не означает, что у нее мало сценариев применения.Например, асинхронная запись сообщений из очереди сообщений на диск и механизм MySQL InnoDB Buffer Pool используют эту стратегию.
Производительность записи БД в соответствии с шаблоном отложенной записи очень высока, что очень подходит для некоторых сценариев, когда данные часто меняются, а требования к согласованности данных не так высоки, например, количество просмотров страниц и количество лайков.
Мой адрес на гитхабе:Snailclimb - Overview