Эта статья написанаyanglbmeОригинал, впервые опубликованный в публичном аккаунте"Сообщество открытого исходного кода Doocs"Добро пожаловать в переиздание.
Все мы знаем, что одним из самых простых и популярных способов повышения производительности системы на самом деле являетсяиспользовать кеш. Мы вводим кэширование, которое эквивалентно дублированию данных. Всякий раз, когда обновляются системные данные, очень важно синхронизировать кеш и источник данных (например, базу данных MySQL).Конечно, это также зависит от требований самой системы, чтобы увидеть, допускает ли система определенную задержку данных.
В этой статье я хотел бы познакомить вас с наиболее распространенными стратегиями кэширования, их преимуществами и недостатками, а также сценариями использования, а именно:
- Cache-Aside
- Read-Through
- Write-Through
- Write-Behind
Пожалуйста, следуйте за мной, чтобы посмотреть.
Политика резервного кэширования
Cache-AsideВероятно, наиболее часто используемая стратегия кэширования. В соответствии с этой стратегией приложение (Приложение) будет взаимодействовать с кешем (Кэшем) и источником данных (Источником данных), и приложение будет проверять кеш, прежде чем обращаться к источнику данных. Как показано ниже:
Рассмотрим процесс запроса данных:
- Во-первых, приложение сначала определяет, остались ли данные в кэше;
- Если данные находятся в кеше, т.е.
Cache hit, называемое "попаданием в кэш". Данные считываются напрямую из кеша и возвращаются клиентскому приложению; - Если данных нет в кеше, т.е.
Cache miss, известный как «промах кеша». Приложение считывает эти данные из того места, где они хранятся, например из источника данных MySQL, сохраняет данные в кэше и возвращает их клиенту.
Cache-Aside策略特别适合“读多”的应用场景。 использоватьCache AsideСистема политик несколько устойчива к сбоям кэша. Если служба кэширования выходит из строя, система по-прежнему может работать, обращаясь к базе данных напрямую.
Однако эта стратегия не гарантирует согласованности между хранилищем данных и кешем, и для обновления или аннулирования кеша необходимо использовать другие стратегии. Кроме того, когда данные запрашиваются в первый раз, это всегда приводит к промаху кэша, что требует дополнительного времени для загрузки данных в кэш. Чтобы решить эту проблему, разработчики могут «подогреть» данные, вручную инициируя операции запроса.
Политика сквозного чтения
вышеCache-AsideВ стратегии приложению нужно «разобраться» с кешем и источником данных, а вRead-ThroughВ соответствии с политикой приложениеНет необходимости управлять источниками данных и кешем, просто делегируйте синхронизацию источника данныхпровайдер кеша Cache ProviderВот и все. Все взаимодействие с данными осуществляется через абстрактный уровень кэширования.
Когда вы много читаете,Read-ThroughЭто может снизить нагрузку на источник данных и обладает определенной эластичностью к сбою службы кэширования. Если служба кэширования выходит из строя, поставщик кэша по-прежнему может работать, обращаясь непосредственно к источнику данных.
Однако, когда данные запрашиваются в первый раз, это всегда приводит к промаху кеша, и для загрузки данных в кеш требуется дополнительное время.Я думаю, все знают, как с этим бороться, и это все еще старая рутина "прогрева кеша".
Read-Through适用于多次请求相同数据的场景。 Это то же самое, чтоCache-AsideСтратегии очень похожи, но между ними все же есть некоторые различия, которые еще раз подчеркнуты здесь:
- существует
Cache-Aside, приложение отвечает за выборку данных из источника данных и их обновление в кэше. - пока в
Read-Through, эта логика обычно не зависит отпровайдер кешаслужба поддержки.
Прописная политика
Write-ThroughВ соответствии со стратегией, когда происходит обновление данных (запись), поставщик кэшаCache ProviderОтвечает за обновление базового источника данных и кэша. Кэш согласуется с источником данных, и записи всегда проходят через абстрактный уровень кэша в источник данных.
На практике запись данных происходит медленнее из-за необходимости синхронной записи данных в кэш и источник данных. Однако, когда сRead-ThroughПри совместном использовании мы получаемRead-ThroughВсе преимущества, а также гарантии согласованности данных, избавляющие нас от использования методов инвалидации кеша.
Политика отложенной записи
Если нет серьезных требований к консистенции, мы можем просто вступать в запросы кэшированных обновлений и периодическиflushСбросить в хранилище данных.
Это,Write-BehindПри обновлении данных записывается только кэш. Преимущество заключается в том, что запись данных выполняется быстро и подходит для больших рабочих нагрузок записи. иRead-ThroughПри совместном использовании они хорошо работают для смешанных рабочих нагрузок, когда недавно обновленные данные и данные, к которым осуществлялся доступ, всегда доступны в кэше.
Он устойчив к сбоям источника данных и может допускать некоторое время простоя источника данных. Если поддерживается пакетная обработка или слияние, общее количество операций записи в источник данных может быть уменьшено, что снижает нагрузку и стоимость.
Однако, как только обновленные данные кэша не будут записаны в источник данных, система отключится, и данные не могут быть извлечены.
Как, разве мы не лучше разбираемся в стратегии кэширования?
Добро пожаловать в мою общедоступную учетную запись WeChat «Сообщество открытого исходного кода Doocs». Оригинальные технические статьи будут опубликованы как можно скорее.