Кэширование является незаменимым модулем в современных системах и стало ключевым компонентом высокопроизводительных архитектур с высокой степенью параллелизма. В этом блоге мы разберем правильную позу использования кеша.
Проблемы, которые может решить кэширование
-
Улучшить производительность
В подавляющем большинстве случаев при выборе возникают самые большие проблемы с производительностью. С одной стороны, select имеет много богатой семантики, такой как объединение, группировка, порядок и т. д., и эта семантика очень требовательна к производительности; с другой стороны, большинство приложений читают больше и пишут меньше, что усугубляет медленные вопросы проблема.
Удаленные вызовы в распределенных системах также требуют большой производительности, поскольку из-за сетевых накладных расходов общее время отклика уменьшится. Чтобы сэкономить такие накладные расходы на производительность, очень необходимо использовать кеш, когда это позволяет бизнес (не требует слишком данных в реальном времени).
-
Уменьшите нагрузку на базу данных
Когда пользовательские запросы увеличиваются, нагрузка на базу данных значительно возрастает, и нагрузку на базу данных можно значительно уменьшить с помощью кэширования.
Применимые сценарии кэширования
-
Низкие требования к данным в реальном времени
Для некоторых часто запрашиваемых, но редко изменяемых данных операций чтения значительно больше, чем записей, и необходимо применять кэширование. Например, некоторые элементы конфигурации веб-сайта.
-
высокие требования к производительности
Например, некоторые сцены пиковой активности.
Кэш три режима
Вообще говоря, существует три режима кэширования:
Режим обновления Cache Aside
Чтение/запись через режим обновления
Режим обновления Write Behind Caching
С точки зрения непрофессионала, обновляйте кеш и базу данных одновременно (режим обновления Cache Aside); сначала обновите кеш, а кеш отвечает за синхронное обновление базы данных (режим обновления Read/Write Through); сначала обновите кеш и обновлять базу данных асинхронно (модель Write Behind Caching update). Эти три режима имеют свои преимущества и недостатки, и их можно выбирать и использовать в соответствии с бизнес-сценариями.
Режим обновления Cache Aside
Это наиболее часто используемый режим кэширования. Конкретный процесс:
- недействителен: Приложение сначала извлекает данные из кеша, если не получается, то извлекает данные из базы данных и после успеха помещает их в кеш.
- ударил: Приложение извлекает данные из кеша и возвращается после выборки.
- возобновить: Поместите данные в базу данных после успеха, дайте кэшнедействителен.
Обратите внимание, что мы упоминали выше, что база данных сначала обновляется при обновлении кеша, а затем кеш становится недействительным. Так почему бы просто не обновить кеш напрямую? Здесь есть несколько ям обновления кеша, нам нужно избегать ям.
Руководство по предотвращению ям 1
Сначала обновите базу данных, а затем обновите кеш.Самая большая проблема с этим подходом заключается в том, чтоДве одновременные операции записи приводят к грязным данным. Как показано на рисунке ниже (на примере Redis и Mysql), две параллельные операции обновления, сначала обновляется база данных, но затем обновляется кеш, и сначала обновляется база данных, но сначала обновляется кеш. Таким образом, данные в базе данных и кеше будут несогласованными, и все грязные данные будут прочитаны в приложении.
Руководство по предотвращению ям II
Сначала удалите кеш, а затем обновите базу данных.Эта логика неверна, потому что две одновременные операции чтения и записи приводят к грязным данным.. Как показано ниже (в качестве примера возьмем Redis и Mysql). Предполагая, что операция обновления сначала удаляет кеш, в это время выполняется параллельная операция чтения. После того, как кеш не попал, старые данные извлекаются из базы данных и обновляются обратно в кеш. В это время операция обновления также завершает обновление базы данных. В этот момент данные в базе данных и кеше несовместимы, и приложение считывает исходные данные (грязные данные).
Руководство по предотвращению ям 3
Сначала обновите базу данных, а затем удалите кеш.Этот подход на самом деле не является ямой, и его также рекомендуется использовать в реальных системах. Однако теоретически при таком подходе могут возникнуть проблемы. Как показано на следующем рисунке (на примере Redis и Mysql), операция запроса не обращается к кешу, а затем запрашиваются старые данные в базе данных. В этот момент выполняется параллельная операция обновления, операция обновления обновляет данные в базе данных после операции чтения и удаляет данные в кеше. Однако операция чтения обновляет старые данные, считанные из базы данных, обратно в кэш. Это приведет к несогласованности данных в базе данных и кэше, и приложение будет считывать исходные данные (грязные данные).
Однако, если подумать, вероятность такого параллелизма крайне мала. Поскольку это условие должно выполняться, когда кеш читается из-за недействительности кеша, и есть параллельная операция записи. На самом деле операция записи БД будет намного медленнее операции чтения, и ее нужно заблокировать.Операция чтения должна войти в операцию БД раньше операции записи, а кэш будет обновляться позже операции записи. Вероятность всех этих состояний невелика. Но чтобы избежать влияния грязных данных, вызванных этой экстремальной ситуацией, нам все равно нужно установить время истечения срока действия кеша.
Чтение/запись через режим обновления
В приведенном выше режиме обновления Cache Aside код приложения должен поддерживать два хранилища данных, одно из которых является кешем (Cache), а другое — базой данных (Repository). В режиме сквозного чтения/записи приложению нужно только поддерживать кеш, а обслуживание базы данных выполняется прокси-сервером кеша.
Блок-схема сквозного чтения/записи в режиме обновления
Read Through
Режим Read Through предназначен для обновления кеша во время операции запроса, то есть, когда кеш недействителен, режим Cache Aside отвечает за загрузку данных в кеш вызывающей стороной, в то время как Read Through использует службу кеша для загрузить себя.
Write Through
Режим Сквозная запись аналогичен режиму Сквозное чтение, но происходит при обновлении данных. Когда есть обновление данных, если кеш не попал, обновить базу данных напрямую, а затем вернуться. При попадании в кеш он обновляется, а сам кеш обновляет базу данных (это синхронная операция).
Режим обновления Write Behind Caching
Режим обновления Write Behind Caching заключается в том, что при обновлении данных обновляется только кеш, а не база данных, и наш кеш будет асинхронно обновлять базу данных пакетами. Преимущество этой схемы в том, что можно быстро напрямую манипулировать памятью. Из-за асинхронности режим обновления Write Behind Caching также может объединять несколько операций с одними и теми же данными в базу данных, что значительно повышает производительность.
Но проблема заключается в том, что данные не являются строго согласованными и могут быть потеряны. Кроме того, логика реализации режима обновления Write Behind Caching более сложна, поскольку необходимо подтвердить, какие данные обновляются, а какие необходимо сбросить на уровень сохраняемости. Кэш является действительно постоянным только тогда, когда его необходимо аннулировать.
Суммировать
Преимущества и недостатки трех режимов кэширования:
- Режим обновления Cache Aside относительно прост в реализации, но он требует поддержки двух хранилищ данных, одно из которых является кешем (Cache), а другое — базой данных (Repository).
- В режиме сквозного чтения/записи требуется только поддерживать хранилище данных (кеш), но его немного сложнее реализовать.
- Режим обновления с кэшированием записи аналогичен режиму обновления Сквозное чтение/запись, разница заключается в том, что операция сохранения данных в режиме обновления кэширования с записью является асинхронной, а операция сохранения данных в режиме обновления Сквозное чтение/запись является синхронной. . Преимущество заключается в том, что прямая операция с памятью выполняется быстро, а несколько операций можно комбинировать и сохранять в базе данных. Недостатком является то, что данные могут быть потеряны, например, при отключении питания системы и т. д.
Кэширование повышает производительность, жертвуя строгой согласованностью. Таким образом, использование кеша для повышения производительности означает задержку обновления данных. Это требует от нас тщательного рассмотрения вопроса о том, подходит ли кэширование для использования в сочетании с бизнес-дизайном. Затем кеш должен установить время истечения.Плохо, если это время будет слишком коротким или слишком длинным.Если оно будет слишком коротким, то на базу данных может упасть больше запросов, что также означает, что преимущество кэширования теряется. Если она слишком длинная, грязные данные в кэше приведут к тому, что система будет находиться в состоянии задержки в течение длительного времени, а данные, к которым долгое время не обращались в системе, всегда будут находиться в памяти, а не истекает, что тратит память.
-----END-----
Друзья, которым понравилась эта статья, приглашаем отсканировать картинку ниже и обратить внимание на публичный аккаунт.Закодируйте эти вещи, смотрите больше захватывающего контента