Что такое кэширование данных: Кэширование данных для оптимизации производительности — Microsoft Azure Well-Architected Framework

Кэширование данных для оптимизации производительности — Microsoft Azure Well-Architected Framework

Twitter LinkedIn Facebook Адрес электронной почты

• Статья
• 09/22/2022
• Чтение занимает 2 мин

Кэширование — это стратегия, при которой вы храните копию данных наряду с основным хранилищем данных. Преимущества кэширования включают уменьшение времени отклика и возможность быстро обслуживать данные, что может улучшить взаимодействие с пользователем. Хранилище кэша обычно размещается ближе к клиенту, чем основное хранилище.

Кэширование становится наиболее эффективным, когда экземпляр клиента несколько раз считывает те же данные, особенно в том случае, если к исходному хранилищу данных применяются все указанные далее условия.

• Оно остается относительно статичным.
• Оно является медленным по сравнению со скоростью кэша.
• Оно является объектом высокого числа конкурентных запросов.
• Оно находится далеко, из-за чего задержки в сети могут вызвать снижение скорости доступа.

Кэширование может значительно повысить производительность, масштабируемость и доступность данных. Преимущества кэширования становятся все заметнее с увеличением объемов данных и числа пользователей, которым необходим доступ к этим данным. Это происходит потому, что кэширование снижает задержку и число конфликтов, связанных с обработкой больших объемов параллельных запросов в хранилище исходных данных.

Включение соответствующего кэширования также позволяет сократить задержку за счет исключения повторяющихся вызовов микрослужб, API-интерфейсов и репозиториев данных. Ключом к эффективному использованию кэша является определение наиболее подходящих данных для помещения в кэш и их кэширование в правильный момент времени. Данные могут добавляться в кэш по требованию, как только они впервые извлекаются приложением. Это означает, что приложению будет необходимо извлечь данные из хранилища данных только один раз, а последующий доступ к ним уже может осуществляться с помощью кэша. Дополнительные сведения см. в разделе Определение способа эффективного кэширования данных.

Дополнительные сведения см. в разделе Кэширование.

Кэш Azure для Redis

Кэш Azure для Redis повышает производительность и масштабируемость приложения. Он обрабатывает большие объемы запросов приложений, сохраняя часто используемые данные в памяти сервера, в которой их можно быстро записать и считать. Кэш Azure для Redis на основе программного обеспечения Redis предоставляет хранилище данных с критически низкой задержкой и высокой пропускной способностью для современных приложений.

Кэш Azure для Redis также повышает производительность приложений за счет поддержки стандартных шаблонов архитектуры приложений. Некоторые из наиболее распространенных шаблонов включают кэш данных и кэш содержимого. Наиболее распространенные шаблоны и их описания см. в разделе Общие шаблоны архитектуры приложений.

Сеть доставки содержимого (CDN) Azure

Сеть доставки содержимого (CDN) является распределенной сетью серверов, которая позволяет эффективно доставлять пользователям веб-содержимое. Сети CDN хранят кэшированное содержимое на пограничных серверах в расположениях точек подключения, находящихся рядом с пользователями. Это позволяет свести задержки к минимуму. Дополнительные сведения о CDN см. в статье Что такое сеть доставки содержимого в Azure?

Azure CDN предлагает следующие основные возможности:

• Динамическое ускорение сайтов (DSA) — предоставляет пользователям быстрые, надежные и настраиваемые веб-решения, которые не зависят от браузера, местоположения, устройства или сети.
• Правила кэширования CDN — управление режимом кэширования Azure CDN.
• Поддержка пользовательского домена HTTPS — безопасная доставка конфиденциальных данных при их передаче через Интернет и защита веб-приложений от атак.
• Журналы диагностики Azure — экспорт основных метрик использования из конечной точки CDN в различные типы источников для их последующей настройки.
• Сжатие файлов — увеличение скорости передачи файлов и повышение производительности загрузки страницы за счет уменьшения размера файлов перед их отправкой с сервера.
• Геофильтрация — ограничение доступа к содержимому по стране или региону путем создания правил для конкретных путей в конечной точке CDN.

Следующий

Секция

Что такое кэширование? | Microsoft Azure

Разработчики и ИТ-специалисты используют кэширование для сохранения данных типа “ключ-значение” во временной памяти и получения к ним более быстрого доступа, чем к данным, хранящимся в обычном хранилище данных. Кэши применяются в многочисленных сценариях при использовании различных технологий, например компьютерное кэширование в оперативной памяти (ОЗУ), сетевое кэширование в сети доставки содержимого, веб-кэш для мультимедийных данных сети или облачный кэш, повышающий надежность работы облачных приложений. Разработчики часто создают приложения для кэширования обрабатываемых данных, а затем переориентируют их для выполнения более быстрой обработки запросов, чем обработка запросов в стандартных базах данных.

Кэширование можно использовать, чтобы снизить затраты на базу данных, обеспечить более высокую пропускную способность и меньшею задержку, чем может обеспечить большинство баз данных, а также повысить производительность облачных и веб-приложений.

Как работает кэширование в базах данных?

Разработчики могут добавить кэш в базу данных-источник, который можно разместить в базе данных или приложении, либо настроить его как отдельный уровень. Обычная база данных, как правило, используется для хранения больших и полных наборов данных длительного пользования, а кэш для хранения временных подмножеств данных с целью быстрого их извлечения.

Кэширование можно использовать со всеми типами хранилищ данных, включая базы данных NoSQL, а также реляционные базы данных, такие как SQL Server, MySQL и MariaDB. Кэширование также хорошо работает со многими специфическими платформами обработки данных, такими как База данных Azure для PostgreSQL, База данных SQL Azure и Управляемый экземпляр SQL Azure. Прежде чем приступать к настройке архитектуры данных, рекомендуется изучить, какой тип хранилища данных будет соответствовать вашим требованиям наилучшим образом. Например, вам необходимо понять, что представляет собой база данных PostgreSQL, прежде чем использовать ее для объединения реляционных и неструктурированных хранилищ данных.

Каковы преимущества многоуровневого кэша? И что такое Redis?

Разработчики используют многоуровневое кэширование, называемое также уровнями кэширования, для хранения различных типов данных в отдельных кэшах в соответствии с потребностями приложений.

Добавление одного или нескольких уровней кэширования позволяет существенно повысить пропускную способность и производительность уровня данных с задержкой.

Redis — это популярное хранилище данных в памяти с открытым исходным кодом, используемое для создания высокопроизводительных многоуровневых кэшей и других хранилищ данных. Недавнее исследование показало, что использование образца приложения совместно с Кэшем Azure для Redis увеличивает пропускную способность данных более чем на 800 % и уменьшает время задержки более чем на 1000 %¹.

Кэши также позволяют снизить совокупную стоимость владения уровнем данных. Используя кэши для сохранения наиболее распространенных запросов и снижения нагрузки на базу данных, вы можете уменьшить количество приобретаемых экземпляров базы данных, что приведет к значительной экономии средств и снижению совокупной стоимости владения.

Типы кэширования

Стратегия кэширования зависит от того, как приложение считывает и записывает данные. Ваше приложение часто записывает данные или данные записываются один раз и часто считываются? Всегда ли возвращаемые данные являются уникальными? На выбор модели кэширования также влияют различные способы доступа к данным. Распространенные типы кэширования включают кэш на стороне, кэш сквозного чтения и сквозной записи, а также кэш отложенной или обратной записи.

Кэш на стороне

Для приложений, выполняющих большое количество операций чтения, разработчики часто используют модель программирования «кэш на стороне». Они размещают кэш вне приложения, которое затем подключается к кэшу для запроса и получения данных или соединяется напрямую с базой данных, если данных в кэше нет. После получения данных приложение копирует их в кэш для будущих запросов.

Кэш на стороне можно использовать, чтобы повысить производительность приложения, обеспечить согласованность данных в кэше и хранилище, а также предотвратить устаревание данных в кэше.

Кэш сквозного чтения и сквозной записи

Данные кэшей сквозного чтения постоянно обновляются. При использовании кэшей сквозной записи приложение сначала записывает данные в кэш, а затем в базу данных. Эти кэши тесно интегрированы с базой данных, и приложение рассматривает их как основное хранилище данных.

Кэши сквозного чтения позволяют упростить работу приложений, в которых регулярно запрашиваются одни и те же данные. При этом сам кэш имеет сложную структуру, а двухэтапный процесс сквозной записи может вызывать задержки. Разработчики сочетают разные типы кэшей, чтобы обеспечить согласованность данных в кэше и базе данных, уменьшить задержку в работе кэша сквозной записи и упростить обновление кэша сквозного чтения.

С помощью кэшей сквозного чтения и сквозной записи разработчики могут упростить код приложения, увеличить масштабируемость кэша и уменьшить нагрузку на базу данных.

Кэш отложенной или обратной записи

В этом сценарии приложение записывает данные в кэш, которые сразу подтверждаются, а затем кэш записывает данные в базу данных в фоновом режиме. Кэши отложенной записи, также известные как кэши обратной записи, лучше всего подходят для рабочих нагрузок с интенсивной записью данных. Они повышают производительность записи, так как приложению не требуется ждать завершения записи, чтобы перейти к выполнению следующей задачи.

Распределенный кэш и хранилище сеансов

Пользователи часто путают распределенные кэши и хранилища сеансов, которые похожи, но имеют разные требования и назначения. Вместо добавления в базу данных распределенного кэша разработчики внедряют хранилища сеансов — хранилища временных данных на уровне пользователя, чтобы хранить профили, сообщения и другие пользовательские данные сеансовых приложений, таких как веб-приложения.

Что такое хранилище сеансов?

Сеансовые приложения отслеживают действия, выполняемые пользователями при входе в систему. Чтобы сохранить эти данные при выходе пользователя из системы, их можно сохранить в хранилище сеансов. Это позволит улучшить управление сеансами, снизить затраты и повысить производительность приложений.

В чем различия между хранилищем сеансов и кэшем базы данных?

Данные хранилища сеансов не могут совместно использоваться разными пользователями. При кэшировании разные пользователи могут получить доступ к одному и тому же кэшу. Разработчики используют кэширование для повышения производительности базы данных или экземпляра хранилища, а хранилище сеансов для повышения производительности приложений благодаря записи данных в хранилище в памяти. Это позволяет полностью устранить необходимость доступа к базе данных.

В хранилище сеансов, как правило, записываются данные с коротким сроком хранения, а в кэш базы данных-источника с длительным сроком хранения. Хранилище сеансов требует репликации, высокой доступности и надежности данных, чтобы гарантировать сохранность данных транзакций и присутствие пользователей в системе. С другой стороны, если данные кэша на стороне теряются, в постоянной базе данных остается их копия.

Преимущества кэширования

Улучшение производительности приложений

Чтение данных из кэша в памяти происходит намного быстрее, чем чтение данных из дискового хранилища данных. Быстрый доступ к данным, в свою очередь, позволяет существенно улучшить общую производительность приложений.

Уменьшение нагрузки на базу данных и сокращение затрат

Кэширование позволяет уменьшить количество запросов к базе данных, повысить ее производительность и снизить издержки, устраняя необходимость в масштабировании инфраструктуры базы данных и снижая затраты на пропускную способность.

Масштабируемая и прогнозируемая производительность

Один экземпляр кэша позволяет обрабатывать миллионы запросов в секунду, обеспечивая такой уровень пропускной способности и масштабируемости, который не может обеспечить ни одна база данных. Кэширование также обеспечивает гибкость, которая необходима для горизонтального и вертикального масштабирования приложений и хранилищ данных. Приложение, использующее кэш, позволяет многим пользователям одновременно получать доступ к одним и тем же файлам, не увеличивая нагрузку на серверные базы данных. Если в приложении часто наблюдаются пики использования и недостаточная пропускная способность, кэш в памяти может помочь уменьшить время задержки.

Для чего используется кэширование?

Кэширование выводимых данных

Кэширование выводимых данных позволяет повысить производительность веб-страниц благодаря сохранению их полного исходного кода, например HTML-сценариев и клиентских сценариев, которые сервер отправляет браузерам для отображения. Каждый раз, когда пользователь просматривает веб-страницу, сервер кэширует выводимый код в памяти приложения. Это позволяет приложению обрабатывать запросы без запуска кода страницы и без взаимодействия с другими серверами.

Кэширование данных и баз данных

Скорость и пропускная способность базы данных может иметь большое значение для общей производительности приложений. Кэширование используется для часто вызываемых данных, которые редко меняются, например данные о ценах или запасах. Кэширование способствует более быстрой загрузке веб-сайтов и приложений благодаря увеличению пропускной способности и уменьшению времени задержки при получении данных из серверных баз данных.

Хранение данных сеансов пользователей

Пользователи приложений часто создают данные, которые необходимо хранить в течение короткого периода времени. Хранилище данных в памяти, такое как Redis, лучше подходит для эффективного, экономного и надежного хранения больших объемов данных сеансов, например данных, вводимых пользователями, записей корзины или параметров персонализации, чем хранилища или базы данных.

Брокеры сообщений и архитектуры типа «издатель-подписчик»

Облачным приложениям часто требуется обмениваться данными между службами. Они могут использовать кэширование для реализации брокеров сообщений и архитектур типа «издатель-подписчик», чтобы уменьшить задержку и ускорить управление данными.

Приложения и API

Как и браузеры, приложения сохраняют важные файлы и данные, чтобы в случае необходимости быстро получать к ним доступ. Кэширование ответов API уменьшает нагрузку на серверы и базы данных приложений, обеспечивая более быстрое время отклика и более высокую производительность.

¹Утверждения о производительности основаны на данных исследования, проведенного компанией GigaOm в октябре 2020 г. по заказу корпорации Майкрософт. В исследовании сравнивается производительность тестового приложения, использующего базу данных Azure с реализацией Кэша Azure для Redis в качестве решения для кэширования и без нее. В качестве элемента базы данных в исследовании использовались База данных SQL Azure и База данных Azure для PostgreSQL. Использовался экземпляр Базы данных SQL Azure общего назначения 5-го поколения с 2 виртуальными ядрами и экземпляр Базы данных Azure для PostgreSQL общего назначения с 2 виртуальными ядрами в сочетании с экземпляром Azure для Redis уровня P1 Premium на 6 ГБ. Эти результаты сравнивались с результатами экземпляров Базы данных SQL Azure общего назначения 5-го поколения с 8, 16, 24 и 32 виртуальными ядрами и Базы данных Azure для PostgreSQL общего назначения с 8, 16, 24 и 32 виртуальными ядрами без реализации Кэша Azure для Redis. Контрольные данные были получены с помощью нагрузочного теста базы данных веб-приложения GigaOm, который имитирует отправку увеличивающегося числа HTTP-запросов к обычному веб-приложению и серверной базе данных. Фактические результаты могут отличаться в зависимости от конфигурации и региона. См. полное исследование.

Добавьте в свое приложение гибкий уровень кэширования с помощью полностью управляемой службы Redis. Узнайте, как начать работу с Кэшем Azure для Redis.

Начать

Если вы хотите реализовать гибкое кэширование на основе файлов для высокопроизводительных приложений, ознакомьтесь со сведениями об Azure HPC Cache.

Azure HPC Cache

Кэширование данных в web приложениях.

Использование memcached / Хабр

Я немного расскажу вам про кэширование. Кэширование, в общем-то, не сильно интересно, берешь и кэшируешь, поэтому я еще расскажу про memcached, довольно интимные подробности.

Про кэширование начнем с того, что просят вас разработать фабрику по производству омнониевых торсиометров. Это стандартная задача, главное делать скучное лицо и говорить: «Ну, мы применим типовую схему для разработки фабрики».

Вообще, это ближе к фабричному производству, т.е. откуда проблема пошла? Фабрика работает очень быстро, производит наши торсиометры. А для калибровки каждого прибора нужен чистый омноний, за которым надо летать куда-то далеко и, соответственно, пока мы в процессе добычи этого омнония, приборы лежат некалиброванные, и, по сути дела, все производство останавливается. Поэтому мы строим рядом с фабрикой склад. Но это не бесплатно.

Переходим к терминологии. Просто, чтобы мы общались про кэширование на одном языке есть довольно устоявшаяся терминология.

Источник называется origin; объем склада, т.е. размер кэша — cache size; когда мы идем на склад за образцом нужной формы, и кладовщик выдает то, что мы просили — это называется cache hit, а если он говорит: «Нет такого», это называется cache miss.

У данных — у нашего омнониума — есть freshness, буквально — это свежесть. Fresheness используется везде. Как только данные теряют свою природную свежесть, они становятся stale data.

Процесс проверки данных на годность называется validation, а момент, когда мы говорим, что данные негодные, и выбрасываем их со склада — это называется invalidation.

Иногда случается такая обидная ситуация, когда у нас не остается места, но нам лучше держать свежий омнониум, поэтому мы находим по каким-то критериям самый старый и выбрасываем. Это называется eviction.

Схема такая, что от нашего браузера до бэкенда есть масса звеньев в цепи. Вопрос: где кэшировать? На самом деле, кэшировать надо абсолютно везде. И, хотите вы этого или нет, данные будут кэшироваться, т.е. вопрос, скорее, — как мы можем на это повлиять?

Для начала нужно найти хорошие данные для кэширования. В связи с тем, что мы делаем какой-то кэш, у нас появляется еще одно промежуточное звено в цепи, и необязательно, что кэш что-то ускорит. Если мы плохо подберем данные, то, в лучшем случае, он не повлияет на скорость, а в худшем — еще и замедлит процесс всего производства, всей системы.

Нет смысла кэшировать данные, которые часто меняются. Нужно кэшировать данные, которые используются часто. Размер данных имеет значение, т.е. если мы решаем кэшировать в памяти blu-ray фильм — классно, мы его очень быстро достанем из памяти, но, скорее всего, нам потом его придется перекачать куда-нибудь по сети, и это будет очень медленно. Такой большой объем данных не соизмерим со скоростью доставки, т.е. нам нет смысла держать такие данные в памяти. Можем на диске держать, но нужно сравнивать по скорости.

Кстати, можете погуглить «programming latencies». Там на сайте очень хорошо даны все стандартные задержки, например, скорость доступа в CPU cache, скорость отправки Round Trip пакета в дата-центре. И когда вы проектируете, что-то прикидываете, хорошо смотреть, там очень наглядно показано, что сколько времени и по сравнению с чем занимает.

Это готовые рецепты для кэширования:

Это релевантный HTTP Headers:

Я немного расскажу про некоторые, но, вообще-то, про это надо читать. В принципе, в вебе единственное, как мы можем влиять на кэширование — это правильно устанавливая вот эти header’ы.

Expires использовался раньше. Мы устанавливаем freshness для наших данных, мы буквально говорим: «Все, этот контент годен до такого вот числа». И сейчас этот header нужно использовать, но только как fallback, т.к. есть более новый header. Опять-таки, эта цепочка очень длинная, вы можете попасть на какую-то прокси, которая понимает только вот этот header — Expires.

Новый header, который сейчас отвечает за кэширование, — это Cache-Control:

Тут вы можете указать сразу же и freshness, и validation механизм, и invalidation механизм, указать, это public данные или private, как их кэшировать…

Кстати, no-cache — это очень интересно. По названию очевидно, что мы говорим: кэшируйте везде, пожалуйста, как угодно кэшируйте, если мы говорим «no-cache». Но каждый раз, когда мы используем какие-то данные из этого контента, например, у нас есть формочка, и мы в этой формочке делаем submit, то мы говорим, что в любом случае все ваши закэшированные данные не актуальны, вам надо их перепроверить.

Если мы хотим, вообще, выключить кэширование для контента, то говорим «no-store»:

Эти «no-cache», «no-store» очень часто применяются для форм аутентификации, т.е. мы не хотим кэшировать неаутентифицированных пользователей, чтобы не получилось странного, чтобы они не увидели лишнего или не было недопонимания. И, кстати, про этот Cache-Control: no-cache… Если, допустим, Cache-Control header не поддерживается, то его поведение можно симулировать. Мы можем взять header Expires и установить дату какую-нибудь в прошлом.

Эти все header’ы, включая даже Content-Length, для кэша актуальны. Некоторые кэшируюшие прокси могут просто даже не кэшировать, если нет Content-Length.

Собственно, мы приходим к memcached, к кэшу на стороне бэкенда.

Опять же мы можем кэшировать по-разному, т.е. мы достали какие-то данные из базы, что-то в коде с ними делаем, но, по сути дела, это кэш, — мы один раз их достали, чтобы много раз переиспользовать. Мы можем использовать в коде какой-то компонент, фреймворк. Этот компонент для кэширования нужен, потому что у нас должны быть разумные лимитэйшны на наш продукт. Все начинается с того, что приходит какой-то инженер по эксплуатации и говорит: «Объясни мне требования на свой продукт». И вы должны ему сказать, что это будет столько-то оперативной памяти, столько-то места на диске, такой-то прогнозируемый объем роста у приложения… Поэтому, если мы что-то кэшируем, мы хотим иметь ограничения. Допустим, первое ограничение, которое мы можем легко обеспечить, — по числу элементов в кэше. Но если у нас элементы разного размера, тогда мы хотим это закрыть рамками фиксированного объема памяти. Т.е. мы говорим какой-нибудь размер кэша — это самый главный лимит, самый главный boundary. Мы используем библиотеку, которая может такую штуку делать.

Ну, или же мы используем отдельный кэширующий сервис, вообще stand-alone. Зачем нам нужен какой-то отдельный кэширующий сервис? Чаще всего бэкенд — это не что-то такое монолитное, один процесс. У нас есть какие-то разрозненные процессы, какие-то скрипты, и если у нас есть отдельный кэширующий сервис, то есть возможность у всей инфраструктуры бэкенда видеть этот кэш, использовать данные из него. Это здорово.

Второй момент — у нас есть возможность расти. Например, мы ставим один сервис, у нас заканчивается кэшсайз, мы ставим еще один сервис. Естественно, это не бесплатно, т.е. «а сегодня мы решили отмасштабироваться» не может случиться. Нужно планировать такие вещи заранее, но отдельный кэширующий сервис такую возможность дает.

Кэш еще дает нам availability практически за бесплатно. Допустим, у нас есть какие-то данные в кэше, и мы пытаемся достать эти данные из кэша. У нас что-то где-то падает, а мы делаем вид, что ничего не упало, отдаем данные с кэша. Оно, может, в это время переподнимется как-то, и будет даже availability.

Собственно, мы подобрались к memcached. Memcached — это типичный noSQL.

Почему noSQL для кэширования — это хорошо?

По структуре. У нас есть обычная хэш-таблица, т.е. мы получаем низкий latency. В случае с memcached и аналогичными key-value storage’ами — это не просто низкий latency, а в нотации big-O у нас сложность большинства операций — это константа от единицы. И поэтому мы можем говорить, что у нас какой-то временной constraint. У нас, например, запрос занимает не больше 10 мс., т.е. можно даже договариваться о каком-то контракте на основании этих latency. Это хорошо.

Чаще всего мы кэшируем что попало — картинки вперемешку с CCS’ом с JS’ом, какие-то фрагменты форм прирендеренных, что-то еще. Это непонятно, какие данные, и структура key-value позволяет их хранить довольно легко. Мы можем завести нотацию, что у нас account.300.avatar — это картинка, и оно там работает. 300 — это ID аккаунта в нашем случае.

Немаловажный момент — то, что упрощается код самого storage’а, если у нас key-value noSQL, потому что самое страшное, что может быть — это мы как-то испортим или потеряем данные. Чем меньше кода работает с данными, тем меньше шанса испортить, поэтом простой кэш с простой структурой — это хорошо.

Про memcached key-value. Можно указывать вместе с данными expiration. Поддерживается работа в фиксированном объеме памяти. Можно устанавливать 16-битные флаги со значением произвольно — они для memcached прозрачны, но чаще всего вы будете с memcached работать и с какого-то клиента, и скорее всего, этот клиент уже загреб эти 16 бит под себя, т. е. он их как-то использует. Такая возможность есть.

memcached может работать с поддержкой викшинов, т.е. когда у нас кончается место, мы самые старые данные выпихиваем, самые новые добавляем. Или же мы можем сказать: «Не удаляй никакие данные», тогда при добавлении новых данных она будет возвращать ошибку out of memory — это флажок «-М».

Структурированной единой документации по memcached нет, лучше всего читать описание протокола. В принципе, если вы наберете в Google «memcached протокол», это будет первая ссылка. В протоколе описаны не только форматы команд — отправка, что мы отправляем, что приходит в ответ… Там описано, что вот эта команда, она будет вести себя вот так и так, т.е. там какие-то корнер кейсы.

Коротенько по командам:

get — получить данные;

set/ add/ delete/ replace — как мы сторим эти данные, т.е.:

• set — это сохранить, добавить новые, либо заменить,
  
• add — это добавить только, если такого ключа нет,
  
• delete — удалить;
  
• replace — заменить, только если такой ключ есть, иначе — ошибка.
  

Это в среде, когда у нас есть шард. Когда у нас есть кластер, это никакой консистентности нам не гарантирует. Но с одним инстансом консистанси можно поддерживать этими командами. Более или менее можно такие constraint’ы выстраивать.

prepend/ append — это мы берем и перед нашими данными вставляем какой-то кусочек или после наших данных вставляем какой-то кусочек. Они не очень эффективно реализованы внутри memcached, т.е. у вас все равно будет выделяться новый кусок памяти, разницы между ними и set функционально нет.

Мы можем данным, которые сохраняем, указать какой-то expiration и потом мы можем эти данные трогать командой touch, и мы продляем жизнь конкретно вот этому ключу, т.е. он не удалится.

Есть команды инкремента и декремента — incr/decr. Работает оно следующим образом: вы сторите какое-то число в виде строки, потом говорит incr и даете значение какое-то. Оно суммирует. Декремент — то же самое, но вычитает. Там есть интересный момент, например, 2 — 3 = 0, с точки зрения memcached, т.е. она автоматически хэндлит андерфлоу, но она не дает нам сделать отрицательное число, в любом случае вернется ноль.

Единственная команда, с помощью которой можно сделать какую-то консистентность, — это cas (это атомарная операция compare and swap). Мы сравниваем два каких-то значения, если эти значения совпадают, то мы заменяем данные на новые. Значение, которое мы сравниваем, — это глобальный счетчик внутри
memcached, и каждый раз, когда мы добавляем туда данные, этот счетчик инкрементится, и наша пара key-value получает какое-то значение. С помощью команд gets мы получаем это значение и потом в команде cas мы его можем использовать. У этой команды есть все те же проблемы, которые есть у обычных атомиков, т.е. можно наделать кучу raise condition’ов интересных, тем более, что у memcached нет никаких гарантий на порядок выполнения команд.

Есть у memcached ключик «-С» — он выключает cas. Т.е. что происходит? Этот счетчик пропадает из key-value pair, если вы добавляете ключик «-С», то вы экономите 8 байт, потому что это 64-хбитный счетчик на каждом значении. Если у вас значения небольшие, ключи небольшие, то это может быть существенная экономия.

Как работать с memcached эффективно?

Она задизайнена, чтобы работать с множеством сессий. Множества — это сотни. Т.е. начинается от сотен. И дело в том, что в терминах RPS — request per second — вы не выжмете из memcached многого, используя 2-3 сессии, т.е. для того, чтобы ее раскачать, надо много подключений. Сессии должны быть долгоиграющие, потому что создание сессии внутри memcached — довольно дорогостоящий процесс, поэтому вы один раз прицепились и все, эту сессию надо держать.

Запросы надо batch’ить, т.е. мы должны отправлять запросы пачками. Для get-команды у нас есть возможность передать несколько ключей, этим надо пользоваться. Т.е. мы говорим get и ключ-ключ-ключ. Для остальных команд такой возможности нет, но мы все равно можем делать batch, т.е. мы можем формировать запрос у себя, локально, на стороне клиента с использованием нескольких команд, а потом этот запрос целиком отправлять.

memcached многопоточна, но она не очень хорошо многопоточна. У нее внутри много блокировок, довольно ad-hoc, поэтому больше четырех потоков вызывают очень сильный контеншн внутри. Мне верить не надо, надо все перепроверять самим, надо с живыми данными, на живой системе делать какие-то эксперименты, но очень большое число потоков работать не будет. Надо поиграться, подобрать какое-то оптимальное число ключиком «-t».

memcached поддерживает UDP. Это патч, который был добавлен в memcached facebook’ом. То, как использует facebook memcached — они делают все сеты, т.е. всю модификацию данных по TCP, а get’ы они делают по UDP. И получается, когда объем данных существенно большой, то UDP дает серьезный выигрыш за счет того, что меньше размер пакета. Они умудряются больше данных прокачать через сетку.

Я вам рассказывал про incr/decr — эти команды идеально подходят для того, чтобы хранить статистику бэкенда.

Статистика в HighLoad’e — это вещь незаменимая, т.е. вы не сможете понять, что, как, откуда происходит конкретная проблема, если у вас не будет статистики, потому что после получаса работы «система ведет себя странно» и все… Чтобы добавить конкретики, например, каждый тысячный запрос фейлится, нам нужна какая-то статистика. Чем больше статистики будет, тем лучше. И даже, в принципе, чтобы понять, что у нас есть проблема, нам нужна какая-то статистика. Например, бэкенд отдавал за 30 мс страницу, начал за 40, взглядом отличить невозможно, но у нас перформанс просел на четверть — это ужасно.

Memcached тоже сама по себе поддерживает статистику, и если вы уже используете memcached в своей инфраструктуре, то статистика memcached — это часть вашей статистики, поэтому туда заглядывать надо, туда надо смотреть, чтобы понимать, правильно ли бэкенд использует кэш, хорошо ли он данные кэширует.

Первое — по каждой команде есть hits и misses. Когда мы обратились к кэшу, и нам отдали данные, поинкрементился hit по этой команде. Например, сделали delete ключ, у нас будет delete hits 1, так по каждой команде. Естественно, надо, чтобы hits была 100%, misses не было вообще. Надо смотреть. Допустим, у нас может быть очень высокий miss ratio. Самая банальная причина — мы просто лезем не за теми данными. Может быть такой вариант, что мы выделили под кэш мало памяти, и мы постоянно переиспользуем кэш, т.е. мы данные какие-то добавили-добавили-добавили, на каком-то моменте там первые данные выпали из кэша, мы за ними полезли, их там уже нет. Мы полезли за другими, их там тоже нет. И оно вот так все крутится. Т.е. надо либо со стороны бэкенда уменьшить нагрузку на memcached, либо можно увеличить параметром «-m» объем памяти, который мы разрешаем использовать.

Evictions — это очень важный момент. Ситуация, про которую я рассказываю, она будет видна из того, что evictions rate будет очень высокий. Это количество, когда пригодные данные не експайред, т.е. они свежие, хорошие выбрасываются из кэша, у нас тогда растет число evictions.

Я говорил, что надо использовать batch’и. Как подобрать размер batch’a? Серебряной пули нет, надо экспериментально это все подбирать. Зависит все от вашей инфраструктуры, от сети, которую вы используете, от числа инстансов и прочих факторов. Но когда у нас batch очень большой… Представьте ситуацию, что мы выполняем batch, и все остальные конекншны стоят и ждут, пока batch выполнится. Это называется starvation — голодание, т.е. когда остальные конекшны голодают и ждут, пока выполнится один жирный. Чтобы этого избежать, внутри memcached есть механизм, который прерывает выполнение batch’a насильно. Реализовано это довольно грубо, есть ключик «-R», который говорит сколько команд может выполнить один конекшн подряд. По умолчанию это значение 20. И вы, когда посмотрите на статистику, если у вас conn_yields stat будет каким-то очень высоким, это значит, что вы используете batch больше, чем может memcached прожевать, и ему приходится насильно часто переключать контекст этого конекшна. Тут можно либо увеличить размер batch’а ключиком «-R», либо не использовать со стороны бэкенда такие batch’и.

Еще я говорил, что memcached выбрасывает из памяти самые старые данные. Так вот, я соврал. На самом деле это не так. Внутри memcached есть свой memory менеджер, чтобы эффективно работать с этой памятью, чтобы выбрасывать эти атомы. Он устроен таким образом, что у нас есть slabs (буквально «огрызок»). Это устоявшийся термин в программировании memory менеджеров для какого-то куска памяти, т.е. у нас есть просто какой-то большой кусок памяти, который, в свою очередь, делится на pages. Pages внутри memcached по Мб, поэтому вы не сможете создать там данные «ключ-значение» больше одного Мб. Это физическое ограничение — memcached не может создать данные больше, чем одна страница. И, в итоге, все страницы побиты на чанки, это то, что вы видите на картинке по 96, 120 — они определенного размера. Т.е. идут куски по 96 Мб, потом куски по 120, с коэффициентом 1.25, от 32-х до 1 Мб. В пределах этого куска есть двусвязный список. Когда мы добавляем какое-то новое значение, memcached смотрит на размер этого значения (это ключ + значение + экспирейшн + флаги + системная информация, которая memcached нужна (порядка 24-50 байт)), выбирает размер этого чанка и добавляет в двусвязный список наши данные. Она всегда добавляет данные в head. Когда мы к каким-то данным обращаемся, то memcached вынимает их из двусвязного списка и опять бросает в head. Т.о., те данные, которые мало используются, переползают в tail, и в итоге они удаляются.

Если памяти нам не хватает, то memcached начинает удалять память с конца. Механизм list recently used работает в пределах одного чанка, т.е. эти списки выделены для какого-то размера, это не фиксированный размер — это диапазон от 96 до 120 попадут в 120-ый чанк и т.д. Влиять на этот механизм со стороны memcached мы никак не можем, только со стороны бэкенда надо подбирать эти данные.

Можно посмотреть статистику по этим slab’ам. Смотреть статистику по memcached проще всего — протокол полностью текстовый, и мы можем Telnet’ом подсоединиться, набрать stats, Enter, и она вывалит «простыню». Точно так же мы можем набрать stats slabs, stats items — это в принципе, похожая информация, но stats slabs дает картину, больше размазанную во времени, там такие stat’ы — что было, что происходило за весь тот период пока memcached работал, а stat items — там больше о том, что у нас есть сейчас, сколько есть чего. В принципе, обе эти вещи надо смотреть, надо учитывать.

Вот мы подобрались к масштабированию. Естественно, мы поставили еще один сервер memcached — здорово. Что будем делать? Как-то надо выбирать. Либо мы на стороне клиента решаем, к какому из серверов будем присоединяться и почему. Если у нас availability, то все просто — записали туда, записали сюда, читаем откуда-нибудь, не важно, можно Round Robin’ом, как угодно. Либо мы ставим какой-то брокер, и для бэкенда у нас получается, что это выглядит как один инстанс memcached, но на самом деле за этим брокером прячется кластер.

Для чего используется брокер? Чтобы упростить инфраструктуру бэкенда. Например, нам надо из дата-центра в дата-центр поперевозить сервера, и все клиенты должны об этом знать. Либо мы можем хак за этим брокером сделать, и для бэкенда все прозрачно пройдет.

Но вырастает latency. 90% запросов — это сетевой round trip, т.е. memcached внутри себя запрос обрабатывает за мкс — это очень быстро, а по сети данные ходят долго. Когда у нас есть брокер, у нас появляется еще одно звено, т.е. все еще дольше выполняется. Если клиент сразу знает, на какой кластер memcached ему идти, то он данные достанет быстро. А, собственно, как клиент узнает, на какой кластер memcached ему идти? Мы берем, считаем хэш от нашего ключа, берем остаток от деления этого хэша на количество инстанса в memcached и идем на этот кластер — самый простой солюшн.

Но добавился у нас еще один кластер в инфраструктуру, значит, сейчас нам нужно грохнуть весь кэш, потому что он стал неконсистентным, не валидным, и заново все пересчитать — это плохо.

Для этого есть механизм — consistent hashing ring. Т.е. что мы делаем? Мы берем хэш значения, все возможные хэш значения, например int32, берем все возможные значения и располагаем как будто на циферблате часов. Так. мы можем сконфигурировать — допустим, хэши с такого-то по такой-то идут на этот кластер. Мы конфигурируем рэнджи и конфигурируем кластеры, которые отвечают за эти рэнджи. Таким образом, мы можем тасовать сервера как угодно, т.е. нам надо будет поменять в одном месте это кольцо, перегенерировать, и сервера, клиенты или роутер, брокер — у них будет консистентное представление о том, где лежат данные.

Я еще бы хотел немного сказать про консистентность данных. Как только у нас появляется новое звено, как только мы кэшируем где-либо, у нас появляется дубликат данных. И у нас появляется проблема, чтобы эти данные были консистентными. Потому что есть много таких ситуаций — например, мы записываем данные в кэш — локальный или удаленный, потом идем и пишем эти данные в базу, в этот момент база падает, у нас конекшн с базой пропал. По сути дела, по логике, этих данных у нас нет, но в это же время клиенты читают их из кэша — это проблема.

memcached плохо подходит для consistancy каких-то решений, т.е. это больше решения на availability, но в то же время, есть какие-то возможности с cas’ом что-то наколхозить.

Контакты

» [email protected]
» http://cachelot.io/

Этот доклад — расшифровка одного из лучших выступлений на обучающей конференции разработчиков высоконагруженных систем HighLoad++ Junior.

Также некоторые из этих материалов используются нами в обучающем онлайн-курсе по разработке высоконагруженных систем HighLoad.Guide — это цепочка специально подобранных писем, статей, материалов, видео. Уже сейчас в нашем учебнике более 30 уникальных материалов. Подключайтесь!

Ну и главная новость — мы начали подготовку весеннего фестиваля «Российские интернет-технологии», в который входит восемь конференций, включая HighLoad++ Junior.

Что такое кэширование и как оно работает

За последние несколько лет информационные технологии радикально улучшили любой вид бизнеса. Между тем архитектуры программного обеспечения становятся все более сложными, а число их пользователей растет в геометрической прогрессии. Это представляло собой проблему производительности для любого приложения. Низкая производительность может подорвать стратегические цели любой компании, поэтому крайне важно найти разумные способы ее улучшения. Как следствие, необходимо избегать накладных расходов и сокращать время поиска и обработки данных. Именно здесь в игру вступает кэширование, и поэтому ни один разработчик больше не может его игнорировать.

Во-первых, мы углубимся в концепцию кэширования, поймем, почему оно важно и какие риски с ним связаны. Затем мы изучим наиболее важные виды кэширования.

Что такое кэширование

Кэширование — это механизм повышения производительности приложений любого типа. Технически кэширование — это процесс хранения и доступа к данным из кеша. Но подождите, что такое кеш? Кэш — это программный или аппаратный компонент, предназначенный для хранения данных, чтобы будущие запросы на те же данные могли обслуживаться быстрее.

Основная причина появления кэширования заключается в том, что доступ к данным из постоянной памяти занимает значительное время. Таким образом, всякий раз, когда данные извлекаются или обрабатываются, они должны храниться в более эффективной памяти. Мы называем такую ​​память кешем , которую можно рассматривать как высокоскоростной уровень хранения данных, основной целью которого является уменьшение необходимости доступа к более медленным уровням хранения данных. Чтобы быть рентабельными и эффективными, кэш-память должна быть относительно небольшой, особенно по сравнению с традиционной памятью. Вот почему они обычно реализуются с использованием аппаратного обеспечения быстрого доступа, такого как ОЗУ (оперативная память), а также программного компонента.

Благодаря кэшам можно реализовать механизм эффективного повторного использования ранее извлеченных или вычисленных данных. Всякий раз, когда поступает новый запрос, запрошенные данные сначала ищутся в кэше. Попадание в кэш происходит, когда запрошенные данные могут быть найдены в кэше. Наоборот, промах кэша происходит, когда это невозможно. Очевидно, предполагается, что чтение требуемых данных из кешей выполняется быстрее, чем повторное вычисление результата или чтение его из исходного хранилища данных. Таким образом, чем больше запросов можно обслужить из кеша, тем быстрее будет работать система.

В заключение отметим, что кэширование — довольно простой способ повысить производительность. Это особенно верно по сравнению с оптимизацией алгоритмов, которая обычно является очень сложной и трудоемкой задачей.

Почему кэширование важно

Кэширование чрезвычайно важно, поскольку оно позволяет разработчикам добиться повышения производительности, иногда значительного. Как упоминалось ранее, это жизненно важно.

В частности, ни пользователи, ни разработчики не хотят, чтобы приложения долго обрабатывали запросы. Как разработчики, мы хотели бы развернуть наиболее производительную версию наших приложений. И как пользователи мы готовы ждать всего несколько секунд, а иногда даже миллисекунд. Правда в том, что никто не любит тратить свое время на просмотр загружаемых сообщений.

Кроме того, важность обеспечения высокой производительности настолько важна, что кэширование быстро стало неизбежной концепцией в компьютерных технологиях. Это означает, что его используют все больше и больше сервисов, что делает его практически вездесущим. Как следствие, если мы хотим конкурировать с множеством приложений на рынке, мы должны правильно внедрить системы кэширования. Кроме того, объяснение пользователям, почему наши системы работают медленно, может представлять собой проблему.

Другим важным аспектом кэширования является то, что оно позволяет избежать каждый раз новых запросов или повторной обработки данных. Так что мы можем избежать накладных расходов, таких как сетевые накладные расходы, и уменьшить использование ЦП, особенно если запросы связаны со сложными разработками. Это может продлить срок службы наших машин или серверов. Кроме того, отказ от новых запросов снижает общее количество необходимых запросов, что может снизить стоимость вашей инфраструктуры. Фактически, при работе с облачными платформами или поставщиками общедоступных API, например, обычно выставляются счета за любое сетевое взаимодействие между их службами. Отличные побочные эффекты, не так ли?

Проблемы

Кэширование ни в коем случае не является простой практикой, и эта тема неизбежно сопряжена с проблемами. Давайте рассмотрим самые коварные из них.

Проблема когерентности

Поскольку всякий раз, когда данные кэшируются, создается копия, теперь есть две копии одних и тех же данных. Это означает, что со временем они могут расходиться. В двух словах, это проблема когерентности, которая представляет собой наиболее важную и сложную проблему, связанную с кэшированием. Нет конкретного решения, которое предпочтительнее другого, и лучший подход зависит от требований. Определение наилучшего механизма обновления или аннулирования кэша — одна из самых больших проблем, связанных с кэшированием, и, возможно, одна из самых сложных задач в информатике.

Выбор данных для кэширования

Кэшировать можно практически любые данные. Это означает, что выбор того, что должно находиться в нашем кеше, а что исключить, открыт для бесконечных возможностей. Таким образом, это может стать очень сложным решением. При решении этой проблемы необходимо учитывать некоторые аспекты. Во-первых, если мы ожидаем, что данные будут часто изменяться, нам не следует кэшировать их слишком долго. В противном случае мы можем предлагать пользователям недостоверные данные. С другой стороны, это также зависит от того, сколько времени мы можем терпеть устаревшие данные. Во-вторых, наш кеш всегда должен быть готов для хранения часто необходимых данных, требующих большого количества времени для генерации или извлечения. Идентификация этих данных — непростая задача, и вы рискуете заполнить наш кеш бесполезными данными. В-третьих, кэшируя большие данные, вы можете очень быстро заполнить кэш или, что еще хуже, использовать всю доступную память. Если ваша оперативная память совместно используется вашим приложением и вашей системой кэширования, это может легко стать проблемой, поэтому вам следует ограничить объем оперативной памяти, зарезервированной для кэширования.

Что делать с промахами кэша

Промахи кэша представляют собой временные затраты на наличие кэша. На самом деле кэш пропускает, создавая задержки, которых не было бы в системе, не использующей кэширование. Таким образом, чтобы извлечь выгоду из повышения скорости за счет наличия кеша, промахи кеша должны быть относительно низкими. В частности, они должны быть низкими по сравнению с кэш-попаданиями. Достичь этого результата непросто, и если он не будет достигнут, наша система кэширования может превратиться в не более чем накладные расходы.

Типы кэширования

Хотя кэширование является общей концепцией, есть несколько типов, которые выделяются среди остальных. Они представляют собой ключевые концепции для любых разработчиков, заинтересованных в понимании наиболее распространенных подходов к кэшированию, и их нельзя пропустить. Давайте посмотрим их все.

Кэширование в памяти

В этом подходе кэшированные данные хранятся непосредственно в ОЗУ, что, как предполагается, быстрее, чем обычная система хранения, в которой находятся исходные данные. Наиболее распространенная реализация этого типа кэширования основана на базе данных ключ-значение. Их можно рассматривать как наборы пар ключ-значение. 9Ключ 0011 представлен уникальным значением, а значение — кэшированными данными.

По сути, это означает, что каждая часть данных идентифицируется уникальным значением. Указав это значение, база данных «ключ-значение» вернет связанное значение. Такое решение является быстрым, эффективным и простым для понимания. Вот почему это обычно предпочтительный подход для разработчиков, которые пытаются создать уровень кэширования.

Кэширование базы данных

Каждая база данных обычно имеет определенный уровень кэширования. В частности, внутренний кеш обычно используется, чтобы избежать чрезмерных запросов к базе данных. Кэшируя результат последних выполненных запросов, база данных может немедленно предоставить ранее кэшированные данные. Таким образом, в течение периода времени, в течение которого нужные кэшированные данные действительны, база данных может избегать выполнения запросов. Хотя каждая база данных может реализовать это по-своему, наиболее популярный подход основан на использовании хэш-таблицы, в которой хранятся пары ключ-значение. Как и раньше, ключ используется для поиска значения. Обратите внимание, что такой тип кеша обычно предоставляется по умолчанию технологиями ORM (Object Relational Mapping).

Веб-кэширование

Его можно разделить на две дополнительные подкатегории:

Кэширование веб-клиента

Этот тип кэша знаком большинству пользователей Интернета и хранится на клиентах. Поскольку он обычно является частью браузеров, его также называют Кэширование веб-браузера . Он работает очень интуитивно. Когда браузер впервые загружает веб-страницу, он сохраняет ресурсы страницы, такие как текст, изображения, таблицы стилей, сценарии и медиафайлы. При следующем открытии той же страницы браузер может искать в кэше ресурсы, которые ранее были кэшированы, и извлекать их с компьютера пользователя. Как правило, это намного быстрее, чем загружать их из сети.

Кэширование веб-сервера

Это механизм, предназначенный для хранения ресурсов на стороне сервера для повторного использования. В частности, такой подход полезен при работе с динамически генерируемым контентом, для создания которого требуется время. И наоборот, это бесполезно в случае статического контента. Кэширование веб-сервера предотвращает перегрузку серверов, сокращает объем выполняемой работы и повышает скорость доставки страниц.

Кэширование CDN

CDN означает Сеть доставки контента и предназначен для кэширования контента, такого как веб-страницы, таблицы стилей, скрипты и медиафайлы, на прокси-серверах. Его можно рассматривать как систему шлюзов между пользователем и исходным сервером, где хранятся его ресурсы. Когда пользователю требуется ресурс, прокси-сервер перехватывает его и проверяет, есть ли у него копия. Если это так, ресурс немедленно доставляется пользователю; в противном случае запрос перенаправляется на исходный сервер. Эти прокси-серверы размещены в огромном количестве мест по всему миру, и запросы пользователей динамически перенаправляются на ближайший из них. Таким образом, ожидается, что они будут ближе к конечным пользователям, чем исходные серверы, что означает снижение задержки в сети. Кроме того, это также уменьшает количество запросов к исходным серверам.

Заключение

В этой статье мы рассмотрели, что такое кэширование и почему оно приобретает все большее значение в информатике. В то же время очень важно не недооценивать угрозы и риски, связанные с кэшированием. Внедрение правильно определенной системы кэширования — непростая задача, требующая времени и опыта. Вот почему знание наиболее важных типов кэш-памяти имеет основополагающее значение для проектирования правильной системы. Как показано, их можно свести к очень ограниченному набору. Освоение их всех должно быть миссией каждого разработчика. В заключение, кэширование — это неизбежное понятие, и объяснение его общих понятий, на что была нацелена эта статья.

Спасибо за внимание! Я надеюсь, что вы нашли эту статью полезной. Не стесняйтесь обращаться ко мне с любыми вопросами, комментариями или предложениями.

Все, что связано с кэшированием: варианты использования, преимущества, стратегии, выбор технологии кэширования, знакомство с некоторыми популярными продуктами | by Kousik Nath

Изображение Christian Wiediger на unsplash.com

Почти все знакомы с кэшированием, несмотря на то, что эта технология настолько распространена в настоящее время, начиная от процессора и заканчивая браузером и любым веб-приложением — все программное обеспечение в определенной степени зависит от кэширования для обеспечения высокой производительности. быстрый ответ. Задержка в несколько миллисекунд может привести к потерям в миллиарды долларов, поэтому отклик менее чем за миллисекунду становится повседневной необходимостью. На рынке доступно огромное количество решений для кэширования. Но это не означает, что использование какой-либо технологии решает вашу проблему. Итак, в этом посте я попытаюсь объяснить различные параметры, которые помогут вам выбрать технологию, а также мы обсудим функции и некоторые реальные варианты использования уже доступных на рынке решений, чтобы, прежде чем использовать их, вы знали их общие варианты использования.

Прежде чем принять решение о уровне кэширования, вам нужно задать себе следующие вопросы:

• Какие бизнес-варианты использования в вашей системе требуют высокой пропускной способности, быстрого отклика или низкой задержки?
• Вас устраивает несогласованность данных при использовании кэша?
• Какие данные вы хотите хранить? Объекты, статические данные, простые пары ключ-значение или структуры данных в памяти?
• Вам нужно поддерживать кэш для транзакционных / основных данных?
• Вам нужен внутрипроцессный кеш или общий кеш на одном узле или распределенный кеш для n узлов?
• Вам нужно решение для кэширования с открытым исходным кодом, коммерческое или предоставляемое платформой?
• Если вы используете распределенный кэш, как насчет производительности, надежности, масштабируемости и доступности?

Эффективное кэширование помогает как потребителям контента, так и его поставщикам. Вот некоторые преимущества кэширования для доставки контента:

Снижение сетевых затрат: Контент может кэшироваться в различных точках сетевого пути между потребителем контента и источником контента. Когда содержимое кешируется ближе к потребителю, запросы не вызывают дополнительной сетевой активности за пределами кеша.

Повышенная скорость отклика: Кэширование позволяет быстрее извлекать содержимое, поскольку нет необходимости в круговом обходе всей сети. Кэши, поддерживаемые рядом с пользователем, такие как кэш браузера, могут сделать это извлечение почти мгновенным.

Повышение производительности на том же оборудовании: Для сервера, на котором создан контент, можно добиться большей производительности на том же оборудовании, разрешив агрессивное кэширование. Владелец контента может использовать мощные серверы на пути доставки, чтобы взять на себя основную нагрузку при загрузке определенного контента.

Доступность содержимого во время сбоев в сети: С помощью определенных политик можно использовать кэширование для предоставления содержимого конечным пользователям, даже если оно может быть недоступно в течение коротких периодов времени с исходных серверов.

Давайте рассмотрим некоторые популярные варианты использования кэширования, возможно, ваш вариант использования может пересекаться с одним из них:

Поиск данных в памяти: профиль пользователя, некоторые исторические / статические данные или некоторый ответ API в соответствии с вашими вариантами использования. Кэширование поможет в хранении таких данных. Кроме того, когда вы создаете решение динамического программирования для какой-либо задачи, двумерные массивы или хэш-карты работают как кэширование.

Ускорение РСУБД: Реляционные базы данных работают медленно, когда дело доходит до работы с миллионами строк. Ненужные данные или старые данные, большие объемы данных могут замедлить их индексирование, независимо от того, выполняете ли вы сегментирование или секционирование, один узел всегда может испытывать задержку и задержку ответа на запрос, когда база данных заполнена своей емкостью. В таких сценариях, вероятно, многие запросы «SELECT» или запросы на чтение могут кэшироваться извне, по крайней мере, на какое-то небольшое временное окно. Реляционные базы данных также используют собственное кэширование, но для повышения производительности внешнее кэширование может иметь гораздо большую емкость, чем внутреннее кэширование. Это один из самых популярных вариантов использования кэширования.

Управление всплеском в веб-приложениях и мобильных приложениях: Популярные веб-приложения и мобильные приложения часто испытывают сильный всплеск, когда они привлекают большое внимание пользователей. Многие из таких вызовов могут заканчиваться запросами на чтение в базе данных, вызовами внешних веб-сервисов, некоторые могут быть вычисленными данными, такими как вычисление предыдущих платежей на лету, некоторые могут быть некритическими динамическими данными, такими как количество подписчиков для пользователя, количество подписчиков. повторные твиты, количество просмотров и т. д. Кэширование может использоваться для обслуживания таких данных.

Хранилище сеансов: Активные веб-сеансы — это данные, к которым очень часто обращаются — независимо от того, хотите ли вы выполнить аутентификацию API или хотите сохранить последнюю информацию о корзине в приложении электронной коммерции, кеш может хорошо служить сеансу.

Кэширование токенов: Токены API могут кэшироваться в памяти для обеспечения высокопроизводительной аутентификации и проверки пользователей.

Игры: Профиль игрока и таблица лидеров — это 2 экрана, которые очень часто просматривают геймеры, особенно в многопользовательских онлайн-играх. Таким образом, с миллионами игроков становится чрезвычайно важно очень быстро обновлять и получать такие данные. Кэширование подходит и для этого варианта использования.

Кэширование веб-страницы: Чтобы сделать мобильное/веб-приложение легким и гибким пользовательским интерфейсом, вы можете создавать динамические веб-страницы на сервере и обслуживать их через API вместе с соответствующими данными. Таким образом, если у вас есть миллионы пользователей, вы можете обслуживать такие на лету созданные полные/фрагментированные веб-страницы из кеша в течение определенного периода времени.

Генерация глобального идентификатора или счетчика: Если у вас есть переменное количество, скажем, экземпляров реляционной базы данных на узлах, и вы хотите сгенерировать для них автоматически увеличивающийся первичный ключ или когда вы хотите назначить уникальный идентификатор своим пользователям, вы можете использовать кэширование для извлечения и обновления таких данных в масштабе.

Быстрый доступ к любым подходящим данным: Часто мы думаем, что кеш используется только для хранения часто используемых данных для чтения. Хотя в основном это правильно, такое поведение может варьироваться в зависимости от вариантов использования. Кэш можно использовать для хранения менее частых данных, если вам действительно нужен быстрый доступ к этим данным. Мы используем кеш для очень быстрого доступа к данным, поэтому сохранение наиболее частых/наименее частых данных — это просто вопрос использования.

Дизайн приложения/системы во многом зависит от используемых стратегий доступа к данным. Они диктуют отношения между источником данных и системой кэширования. Поэтому очень важно выбрать правильную стратегию доступа к данным. Прежде чем выбрать какую-либо стратегию, проанализируйте схему доступа к данным и постарайтесь, чтобы ваше приложение соответствовало любому из следующих параметров.

Сквозное чтение/Отложенная загрузка: Загружать данные в кэш только при необходимости. Если приложению нужны данные для какого-то ключа x , сначала выполните поиск в кеше. Если данные присутствуют, верните данные, в противном случае извлеките данные из источника данных, поместите их в кеш и затем верните.

Преимущества:

1. Он не загружает и не хранит все данные вместе, это по запросу. Подходит для случаев, когда вы знаете, что вашему приложению может не понадобиться кэшировать все данные из источника данных в определенной категории.
2. Если таких узлов кэша несколько и один из них выходит из строя, это не наносит вреда приложению, хотя в такой ситуации приложение сталкивается с повышенной задержкой. По мере того, как новый узел кеша появляется в сети, через него проходит все больше и больше запросов, и он продолжает заполнять необходимые данные при каждом промахе кеша.

Недостатки:

1. Для промаха кеша есть 3 сетевых обхода. Проверить в кеше, получить из базы данных, залить данные в кеш. Таким образом, кеш вызывает заметную задержку ответа.
2. Устаревшие данные могут стать проблемой. Если данные изменяются в базе данных, а срок действия ключа кэша еще не истек, в приложение будут переданы устаревшие данные.

Сквозная запись: При вставке или обновлении данных в базе данных также обновляйте данные в кэше. Таким образом, обе эти операции должны выполняться в одной транзакции, иначе данные будут устаревать.

Преимущества:

1. Отсутствие устаревших данных. Он устраняет проблему устаревания кэша сквозного чтения.
2. Подходит для тяжелых систем чтения, которые плохо переносят устаревание.

Недостатки:

1. Это система штрафов за запись. Каждая операция записи выполняет 2 сетевые операции — запись данных в источник данных, затем запись в кеш.
2. Кэш-память: Если большая часть данных никогда не будет прочитана, в кэше будут храниться бесполезные данные. Это можно контролировать с помощью TTL или истечения срока действия.
3. В целях обеспечения согласованности между кешем и источником данных при записи данных, если какой-либо из узлов вашего кеша отсутствует, операция записи завершается сбоем.

Запись после кэширования: В этой стратегии приложение записывает данные непосредственно в систему кэширования. Затем через определенный настроенный интервал записанные данные асинхронно синхронизируются с базовым источником данных. Итак, здесь служба кэширования должна поддерживать очередь операций «записи», чтобы их можно было синхронизировать в порядке вставки.

Преимущества:

1. Поскольку приложение записывает данные только в службу кэширования, ему не нужно ждать, пока данные будут записаны в базовый источник данных. Чтение и запись происходят на стороне кэширования. Таким образом улучшается производительность.
2. Приложение защищено от сбоя базы данных. В случае сбоя базы данных элементы в очереди можно повторить или повторно поставить в очередь.
3. Подходит для систем с высокой пропускной способностью чтения и записи.

Недостатки:

1. Возможная согласованность между базой данных и системой кэширования. Таким образом, любая прямая операция с базой данных или операция присоединения могут использовать устаревшие данные.

Ограничения дизайна приложения со стратегией отложенной записи:

1. Поскольку в этой стратегии сначала записывается кеш, а затем база данных — они не записываются в транзакцию, если кэшированные элементы не могут быть записаны в базу данных, должен выполняться некоторый процесс отката для обеспечения согласованности во временном окне.
2. Кэширование с отложенной записью может привести к неупорядоченным обновлениям базы данных, поэтому база данных должна иметь возможность ослаблять ограничения внешнего ключа. Кроме того, если база данных является общей базой данных, другие приложения также могут использовать ее, поэтому невозможно узнать, будут ли обновления кэша с отложенной записью конфликтовать с другими внешними обновлениями. Это должно быть обработано вручную или эвристическим путем.

Кэширование с предварительным обновлением: Это метод, при котором кэшированные данные обновляются до истечения срока их действия. Когерентность Oracle использует этот метод.

Время упреждающего обновления выражается в процентах от времени истечения срока действия записи. Например, предположим, что время истечения срока действия записей в кэше установлено на 60 секунд, а коэффициент упреждающего обновления установлен на 0,5. Если доступ к кэшированному объекту осуществляется через 60 секунд, Coherence выполнит синхронный считывается из хранилища кеша, чтобы обновить его значение. Однако, если запрос выполняется для записи старше 30, но менее 60 секунд, возвращается текущее значение в кэше, и Coherence планирует асинхронную перезагрузку из хранилища кэша.

Итак, что делает кэширование с упреждающим обновлением, так это то, что оно по существу обновляет кеш с настроенным интервалом непосредственно перед следующим возможным доступом к кешу, хотя обновление данных может занять некоторое время из-за задержки в сети, и тем временем уже может быть выполнено несколько тысяч операций чтения. в очень читаемой тяжелой системе всего за несколько миллисекунд.

Преимущества:

1. Это полезно, когда большое количество пользователей использует одни и те же ключи кэша. Поскольку данные периодически и часто обновляются, устаревшие данные не являются постоянной проблемой.
2. Уменьшенная задержка по сравнению с другими методами, такими как кеш со сквозным чтением.

Недостатки:

1. Вероятно, это немного сложно реализовать, поскольку служба кэширования требует дополнительных усилий для обновления всех ключей по мере обращения к ним. Но в условиях интенсивного чтения это того стоит.

Суть обсуждения стратегий заключается в том, что при проектировании системы вы знаете, какую систему вы проектируете — будь то система с интенсивным чтением, интенсивной записью или сочетанием того и другого в очень большом масштабе. Различные системы будут иметь разные требования, поэтому очень сложно придумать несколько надежных вариантов использования и полностью проверенную стратегию. Вы можете выбрать одну или несколько стратегий, как описано выше, в зависимости от вашего варианта использования.

Политика вытеснения позволяет кэшу гарантировать, что размер кэша не превышает максимальный предел. Для этого существующие элементы удаляются из кэша в зависимости от политики исключения, но ее можно настроить в соответствии с требованиями приложения.

Решение для кэширования может предоставлять различные политики вытеснения, но перед выбором технологии кэширования полезно знать, какая политика вытеснения может потребоваться вашему приложению. Может случиться так, что вашему приложению нужны разные политики вытеснения для разных вариантов использования, это прекрасно, но знание этого поможет вам лучше выбрать технологию кэширования.

• Наименее недавно использовавшиеся (LRU): Одной из наиболее часто используемых стратегий является LRU. В большинстве случаев кэширования приложения снова и снова обращаются к одним и тем же данным. Скажем, в любой поисковой системе Google, когда вы что-то ищете, вы снова и снова будете получать одни и те же результаты, по крайней мере, в течение некоторого промежутка времени. Когда вы ищете авиабилеты, автобусы или поезда, вы получаете одни и те же маршруты до тех пор, пока какой-либо маршрут не будет деактивирован или полностью зарезервирован. В таких случаях кэшированные данные, которые не использовались в последнее время, или неиспользуемые данные могут быть безопасно удалены.

Преимущества:
1. Наиболее близок к наиболее оптимальному алгоритму
2. Выбирает и удаляет элементы, которые давно не используются к элементу обращались больше, чем при последнем доступе

• Наименее часто используемые (LFU):

Ваша мобильная клавиатура использует LFU . Когда вы вводите несколько букв, вы можете увидеть несколько предложенных слов в верхней части клавиатуры, совпадающих с введенными вами буквами. В начале, когда приложение клавиатуры 9Кэш 0344 пуст, он может показать вам эти 4 слова (Предположим, вы набрали буквы «STA». Предлагаемые слова могут появиться, например, старт, стенд, статуя, посох). Идея здесь в том, что, основываясь на словах, которые вы используете, он будет игнорировать слово LRU в предложениях через определенное время. Вы можете не увидеть слово «персонал» в предложениях позже, если вы его не использовали.

Если у вас есть случай, когда вы знаете, что данные довольно повторяющиеся, обязательно используйте LFU , чтобы избежать кеш промах. Кажется, что они оба совершенно независимы и имеют изолирующее значение. Это зависит от варианта использования, где вы хотите использовать любой из них.

Преимущества:
1. Учитывает возраст элемента
2. Учитывает опорную частоту элемента
3. Лучше работает при высокой нагрузке, когда быстро запрашивается много элементов (меньше ложных выселений)
Недостатки:
1. Часто используемый элемент будет удален только после большого количества промахов
2. Более важно сделать недействительными элементы, которые могут изменяться

• Последние использованные (MRU): Давайте рассмотрим Tinder. Tinder персонализирует для вас совпадающие профили и буферизует результаты в кеш или высокопроизводительный кеш. Таким образом, вы можете предположить, что некоторое пространство для каждого пользователя выделено для очереди соответствующих персонализированных результатов. Когда вы видите страницу рекомендаций Tinder, в тот момент, когда вы проводите пальцем вправо или влево, вам больше не нужен этот вид рекомендаций. Таким образом, в этом случае Tinder может удалить рекомендацию из очереди этого пользователя и освободить место в памяти. Эта стратегия удаляет самые последние использованные элементы, поскольку они не потребуются, по крайней мере, в ближайшем будущем.
• First In, First Out (FIFO): Это больше похоже на MRU, но следует строгому порядку вставленных элементов данных. MRU не выполняет заказ на вставку.

В некоторых случаях может потребоваться применить комбинацию политик вытеснения, например LRU + LFU, чтобы решить, какие данные вытеснять. Это зависит от вашего варианта использования, поэтому старайтесь выбирать такие технологии, которые соответствуют политике выселения, о которой вы подумали.

Различные технологии кэширования хорошо подходят для разных типов данных благодаря их внутренней структуре. Таким образом, выбор правильной технологии также зависит от того, какой тип данных они могут эффективно хранить.

Хранилище объектов: Подходит для хранения неизменяемых объектов, таких как объект ответа HTTP, набор результатов базы данных, обработанная HTML-страница и т. д. Пример: Memcached.

Хранилище значения простого ключа: Сохранение простого строкового ключа в строковое значение практически поддерживается любым кэшем. Пример: Redis, Memcached, Hazelcast, Couchbase и т. д.

Кэш собственной структуры данных: Если ваш вариант использования поддерживает сохранение и извлечение данных из изначально поддерживаемых структур данных, то Redis и Aerospike — хороший выбор.

Кэширование в памяти: Подходит для хранения любого значения ключа или объектов, непосредственно доступных через оперативную память, в том же узле. Пример: HashMap, Guava Cache и т. д., кэширование запросов Hibernate и MySQL.

Кэш статических файлов: Подходит для кэширования изображений, файлов, статических файлов, таких как файлы css или javascript. Пример: Akamai CDN, Memcached в определенной степени.

Один узел (в процессе) Кэширование:

Это стратегия кэширования для нераспределенных систем. Приложения создают и управляют своими собственными или сторонними объектами кэша. И приложение, и кеш находятся в одном и том же пространстве памяти.

Этот тип кэша используется для кэширования сущностей базы данных, но также может использоваться в качестве своего рода пула объектов, например, объединения последних использованных сетевых подключений для повторного использования на более позднем этапе.

Преимущества: Локально доступные данные, высокая скорость, простота обслуживания.

Недостатки: Высокое потребление памяти в одном узле, кеш делит память с приложением. Если несколько приложений используют один и тот же набор данных, может возникнуть проблема дублирования данных.

Вариант использования: Выберите эту стратегию, когда вы создаете автономные приложения, такие как мобильные приложения или веб-интерфейсные приложения, где вы хотите временно кэшировать данные веб-сайта, полученные из серверного API, или другие материалы, такие как изображения, css, java. содержимое скрипта. Эта стратегия также полезна, когда вы хотите совместно использовать объекты, которые, возможно, вы создали из ответа API, для разных методов в разных классах вашего внутреннего приложения.

Распределенное кэширование:

Когда мы говорим о веб-приложениях масштаба Интернета, мы на самом деле говорим о миллионах запросов в минуту, петабайтах или терабайтах данных в контексте. Таким образом, одна или две специализированные мощные машины не смогут справиться с такими огромными масштабами. Нам нужно несколько машин для обработки таких сценариев. Несколько машин от десятков до сотен составляют кластер, и в очень большом масштабе нам нужно несколько таких кластеров.

Основные требования к эффективному распределенному кэшированию:
Ниже приведены наиболее важные требования для распределенного кэширования.

Предоставлено Couchbase

1. Производительность: Кэш должен постоянно поддерживать требования к пропускной способности с точки зрения запросов чтения или записи от приложения. Таким образом, чем больше он может использовать ресурсы, такие как ОЗУ, SSD или флэш-память, процессор и т. д., тем лучше он производит результат.
2. Масштабируемость: Система кэширования должна поддерживать стабильную производительность, даже если количество операций, запросов, пользователей и объем потока данных увеличивается. Он должен иметь возможность масштабироваться линейно без каких-либо неблагоприятных последствий. Таким образом, эластичный рост вверх или вниз является важной характеристикой.
3. Доступность: Высокая доступность является важнейшим требованием современных систем. Получить устаревшие данные — это нормально (в зависимости от варианта использования), но нежелательны недоступные системы. Независимо от того, запланировано или незапланировано отключение, произошел сбой части системы или из-за стихийного бедствия какой-либо центр обработки данных не работает, кэш должен быть доступен все время.
4. Управляемость: Простое развертывание, мониторинг, удобная информационная панель, матрицы реального времени упрощают жизнь каждого разработчика и SRE.
5. Простота: При прочих равных простота всегда лучше. Добавление кэша в ваше развертывание не должно приводить к ненужной сложности или создавать дополнительную работу для разработчиков.
6. Доступность: При принятии любого ИТ-решения всегда учитываются затраты, как на начальное внедрение, так и на текущие расходы. Ваша оценка должна учитывать общую стоимость владения, включая лицензионные сборы, а также оборудование, услуги, обслуживание и поддержку.

Таким образом, в зависимости от ваших вариантов использования вы можете решить, какой тип кэширования использовать. В большинстве случаев корпоративные системы или хорошо зарекомендовавшие себя стартапы, которые обслуживают миллионы клиентов, используют распределенное кэширование с использованием нескольких кластеров. Малые и средние компании также используют несколько узлов для кэширования, но им не всегда нужны решения корпоративного уровня. Как уже упоминалось, внутрипроцессный кеш можно использовать только в автономных приложениях или локальном кешировании на устройствах пользователей.

Давайте рассмотрим некоторые популярные технологии кэширования в реальной жизни, которые могут решить наши повседневные потребности в кэшировании.

Memcached

Бесплатная высокопроизводительная система кэширования объектов с распределенной памятью с открытым исходным кодом , универсальная по своей природе, но предназначенная для использования в ускорении динамических веб-приложений за счет снижения нагрузки на базу данных. Memcached — это хранилище ключей и значений в памяти для небольших произвольных данных (строк, объектов).

Особенности:

1. Memcached разработан как высокопроизводительное решение для кэширования, которое может удовлетворить пропускную способность очень больших интернет-приложений.
2. Memcached очень прост в установке и развертывании, так как по замыслу он представляет собой кеш-память.
3. Очень недорогое решение, лицензированное в соответствии с пересмотренной лицензией BSD.
4. Простое хранилище значений ключей. Memcached не понимает, что сохраняет приложение — он может хранить значения String и Object, ключи всегда имеют тип String. Это позволяет хранить объект как значение в сериализованной форме. Поэтому перед сохранением любого объекта вы должны его сериализовать, после извлечения вы должны соответственно его десериализовать.
5. В распределенных настройках узлы Memcached не разговаривают друг с другом, нет ни синхронизации, ни репликации. Таким образом, по сути, он включает в себя простой дизайн, в котором клиент должен выбрать узел, на котором он должен читать/записывать определенные данные.
6. Это многопоточность. Таким образом, он может использовать преимущества нескольких ядер ЦП.
7. Все команды memcahed выполняются максимально быстро и без блокировок. Таким образом, скорость запроса почти детерминирована для всех случаев.
8. Клиент сохраняет логику для сопоставления ключей кэша с узлами, если доступно несколько узлов.
9. Помимо операций получения, установки и удаления, memcached предлагает другие функции, такие как истечение срока действия ключа (TTL), полная очистка базы данных, облегченные счетчики, поддерживающие операции увеличения и уменьшения, собственная структура данных списка, которая поддерживает добавление и начало операции с элементами, потокобезопасная операция CAS (Compare & Swap) с поддержкой множества.
10. Инвалидация кеша проста, так как клиент отслеживает, какой ключ идет к какому узлу, он может просто удалить этот ключ из этого узла.

Ниже приводится сводка всех операций:

Предоставлено: Heroku

Технология управления памятью: Memcached поддерживает только управление памятью LRU. Поэтому тщательно проанализируйте свой вариант использования, прежде чем выбирать это решение.

Подходящие варианты использования: Сохранение простых строковых пар ключ/значение. Хранить объект набора результатов базы данных, ответ HTTP API или сериализуемые объекты в памяти, документ JSON/XML в виде значения со строковым ключом, результаты рендеринга страницы и т. д.

Ограничения:

1. Поскольку постоянства нет, при каждом сбое или перезапуске вам необходимо каждый раз прогревать или пополнять данные.
2. Если вы хотите хранить большие объекты или наборы данных, сериализованное представление данных может занять больше места и привести к фрагментации памяти.
3. Memcached ограничивает размер данных до 1 МБ на ключ.
4. Избегайте вариантов использования операций чтения-изменения-записи. Поскольку вам нужно сериализовать/десериализовать объекты при вставке/извлечении данных, операции обновления кажутся очень затратными. Старайтесь как можно больше хранить неизменяемые объекты со сроком действия.
5. Memcached не подходит для корпоративных сценариев использования. Он не предлагает многих функций, таких как автоматическое управление эластичными кластерами, сложный высокий уровень доступности, автоматический переход на другой ресурс, перебалансировку нагрузки, репликацию между центрами обработки данных и т. д. Если вы столкнетесь с какой-либо проблемой, вам придется полагаться либо на свой ресурс, либо на сообщество Memcached, его не поддерживает коммерческая организация.

LinkedIn начали использовать Memcached в 2010 году, но к 2012 году они столкнулись со многими проблемами и были вынуждены избавиться от него. Следующие фрагменты взяты из инженерного блога LinkedIn, они дают хорошее представление о том, почему Memcached не подходит для предприятий:

Дни Memcached

Впервые Memcached был представлен LinkedIn в начале 2010-х годов как быстрое решение для распределенного кэширования в памяти, когда нам нужно было масштабировать наши хранилища данных, являющиеся источником достоверных данных, для обработки растущего трафика. Он хорошо работал для того, что он давал:

Одноразрядные миллисекундные GET и SET для приложений, которые нуждались в кэшировании перед своими хранилищами данных источника правды.

Предоставление кластера было простым, и процесс запуска был очень быстрым.

Однако по мере того, как количество кластеров Memcached росло вместе с количеством приложений, которые начали его использовать, мы быстро столкнулись с проблемами работоспособности, одними из основных из которых были:

Отсутствие постоянства. Memcached был хранилищем в памяти. Хотя быстрое время отклика было самой сильной стороной Memcached, оно также было жестоким, когда нам нужно было перезапустить процесс Memcached по причинам обслуживания, поскольку мы также теряли все содержимое кеша.

Разрыв хеш-кольца. Изменение размера кластеров (т. е. расширение кластера за счет большего количества узлов) было невозможно без разрыва хэш-кольца и аннулирования частей кэша. Последовательные алгоритмы хеширования помогли, но не решили проблему полностью.

Замена хостов. Наш алгоритм хеширования был основан на имени хоста узлов в кластере, поэтому каждый раз, когда мы заменяли хост другим именем хоста, это не только делало недействительным кеш на замененном узле, но и нарушало хеш-кольцо.

Отсутствие функции копирования кеша. Предположим, мы хотели создать новый центр обработки данных и скопировать содержимое кэша. Это было непросто. В итоге мы создали некоторые инструменты для перебора ключей для заполнения нового кеша, но это не было ни идеальным, ни элегантным.

Вы можете понять, почему Memcached был так легко принят в LinkedIn (обеспечивал быстрые и легкие победы), но в то же время, почему работать с ним в масштабе было так раздражающе.

Известные пользователи Memcached: YouTube, Reddit, Craigslist, Zynga, Facebook, Twitter, Tumblr, Wikipedia.

Redis

Один из самых популярных кешей в памяти, когда-либо известных на рынке.

Redis часто называют сервером структур данных . Это означает, что Redis предоставляет доступ к изменяемым структурам данных через набор команд, которые отправляются с использованием модели сервер-клиент с сокетами TCP и простым протоколом. Таким образом, разные процессы могут запрашивать и изменять одни и те же структуры данных общим способом.

Особенности:

1. Redis поддерживает собственные изменяемые структуры данных, а именно — список, набор, отсортированный набор, строку, хэш. Он также поддерживает запросы диапазона, растровые изображения, гиперлоги, геопространственные индексы с запросами радиуса.
2. Redis хранит все данные в памяти, по сути, Redis — это большой словарь в памяти. Так что это очень быстро. Он может запускать команды в конвейере.
3. Данные можно асинхронно сохранять на диск после заданного интервала или определенного количества операций.
4. Redis обычно называют однопоточным. Это означает, что логика приложения, которая напрямую обслуживает клиентов, представляет собой только один поток. При синхронизации данных на диске Redis запускает фоновый поток, который напрямую не работает с клиентами.
5. Redis поддерживает готовую репликацию master-slave. Это просто настройки конфигурации, и репликация запущена.
6. Redis поддерживает транзакции. Все команды в транзакции сериализуются и выполняются последовательно. Как обычно, транзакции Redis также гарантируют, что либо все команды будут пройдены, либо ни одна не будет обработана.
7. Поддерживаются ключи Redis TTL или срок действия.
8. Redis имеет встроенную поддержку механизма pub-sub. В нем есть команды, которые включают pub-sub.
9. Автоматический переход на другой ресурс поддерживается Redis Sentinel.
10. Redis поддерживает сценарии Lua на стороне сервера. Таким образом, пакет команд может выполняться без особых проблем со связью между сервером и клиентом.
11. Redis является переносимым, работает практически на всех версиях Linux, Windows, Mac и т. д.
12. Поддержка размера значения до 512 МБ на ключ.
13. Кроме того, корпоративная версия Redis поддерживает гораздо больше функций.

Техника управления памятью: Redis поддерживает следующие техники:

• allkeys-lru : Исключает наименее использовавшиеся ключи из всех ключей.
• allkeys-random : Случайным образом удаляет ключи из всех ключей.
• volatile-lru : удаляет наименее использовавшиеся ключи из всех ключей с установленным полем «expire».
• volatile-ttl : Удаляет ключи с самым коротким сроком действия (из всех ключей с установленным полем «expire»).
• volatile-random : Удаляет ключи с установленным полем «expire».
• без вытеснения : Redis не будет вытеснять какие-либо ключи, и запись будет невозможна до тех пор, пока не будет освобождено больше памяти.

Подходящие варианты использования: У Redis есть много-много прибыльных вариантов использования:

1. Хэш Redis можно использовать вместо реляционных таблиц, если вы можете соответствующим образом моделировать свои данные и ваши варианты использования не требуют каких-либо транзакционных гарантий.
2. pub-sub Redis можно использовать для рассылки сообщений нескольким подписчикам.
3. Список Redis можно использовать как очередь сообщений. Celery — распределенная система обработки задач, использующая структуры данных Redis для управления задачами.
4. Хранилище сеансов — очень популярный вариант использования Redis. Постоянная способность Redis делает его подходящим для такого случая.
5. Отсортированные наборы Redis можно использовать для управления списками лидеров в онлайн-играх.
6. Redis может хранить, увеличивать и уменьшать целые числа. Его можно использовать для генерации глобального идентификатора для любых вариантов использования.

Другие варианты использования можно найти здесь и здесь.

Ограничения:

1. Redis не поддерживает вторичный индекс.
2. Redis предлагает запрос/сканирование данных на основе поиска по регулярным выражениям по именам ключей. Поэтому, прежде чем решить использовать структуры данных Redis, такие как хэш, отсортированные наборы и т. д., подумайте о том, как ваши приложения вписываются в Redis и каков ваш шаблон доступа к данным, если вы используете эти структуры данных. Для простых вариантов использования ключ-значение это круто, вам не нужно много думать.

Известные пользователи Redis: Twitter, GitHub, Weibo, Pinterest, Snapchat, Craigslist, Digg, StackOverflow, Flickr Одним из важных преимуществ Aerospike является то, что он имеет гибридную модель памяти — это означает, что если ваш сервер максимально использует оперативную память, SSD (если сервер использует) можно использовать в качестве альтернативы. Встроенные возможности кластеризации, меньшие затраты на эксплуатацию и обслуживание, высокая доступность делают Aerospike отличным выбором для безумно масштабируемых систем.

Особенности:

1. Aerospike оптимизирован для флэш-накопителей, таких как SSD, PCI, NVMe. Aerospike использует флешки для вертикального масштабирования. SSD обеспечивает огромное вертикальное масштабирование при снижении общей стоимости владения в 5 раз по сравнению с чистой оперативной памятью. Как правило, количество операций ввода-вывода в секунду (ввод-вывод в секунду) для устройств продолжает увеличиваться. SSD могут хранить на порядок больше данных на узел, чем DRAM. Диски NVMe теперь могут выполнять 100 000 операций ввода-вывода в секунду на каждый диск. Aerospike использует эти возможности, поэтому он может постоянно выполнять до миллионов операций в секунду с задержкой менее миллисекунды.
2. Поддерживает хранение ключевых значений, пакетные запросы, сканирование, запросы вторичного индекса и агрегацию и т. д.
3. Поддерживает работу в кластерной среде. Он имеет возможность автоматически управлять кластером, добавление и удаление узлов автоматически идентифицируется, и распределение данных происходит соответствующим образом.
4. Не содержит схемы.
5. Поддерживает истечение TTL для всех записей.
6. Поддерживает строки, целые числа, большие двоичные объекты, списки, карты и сериализованные объекты.
7. Aerospike выполняет репликацию данных между центрами обработки данных (XDCR), она непрерывно копирует данные между узлами кластера, что помогает создать очень высокодоступную отказоустойчивую систему.
8. Aerospike выполняет запись больших блоков и чтение небольших блоков для повышения производительности.
9. Многопоточный.
10. Сценарии Lua на стороне сервера поддерживаются. Это ускоряет пакетные операции на стороне сервера.
11. AQL — язык запросов Aerospike поддерживается, чтобы помочь разработчикам запрашивать ключевые значения в хранилище данных.

Подходящие варианты использования:

1. Отрасль рекламных технологий: Различные варианты использования, такие как хранение профилей пользователей, история пользователей, данные о сеансах, счетчики показов рекламы, хорошо сочетаются с Aerospike благодаря возможности хранения ключевых значений.

При создании любой формы рекламного или маркетингового приложения вам потребуется хранить профили пользователей. Эти профили часто содержат недавнее поведение пользователей, сегменты, загруженные из аналитической системы, файлы cookie партнеров и множество других данных. Меньшие размеры — например, от 1 КБ до 10 КБ — на профиль являются обычным явлением. Помимо чистых профилей, вам потребуются сопоставление файлов cookie, бюджеты и статус кампаний, а также другие внешние данные.

2. Aerospike предлагает структуру данных под названием LDT — Large Data Type. Его можно использовать для хранения миллионов элементов (скажем, целых чисел или строк) для каждого ключа. Поэтому, если вы хотите сохранить список подписчиков знаменитости, сопоставленный с идентификатором знаменитости, вы можете сделать это с помощью LDT. Это просто очень простой и детальный вариант использования.

3. Aerospike может использоваться для хранения вложенных данных, т.е. структура данных под другой структурой данных. Таким образом, собственный список может содержаться на карте и так далее.

4. Если вы хотите кэшировать быстро меняющиеся динамические данные, Aerospike — хороший выбор.

5. Аналитика данных: Хранение поведения потребителей, как в финансовой индустрии, какие транзакции выполняет потребитель и идентификация, является ли это мошеннической транзакцией, система должна очень быстро записывать и извлекать данные потребителей, чтобы анализ мог происходить быстро путем анализа. правила или заинтересованная служба. Aerospike хорошо подходит для такого большого количества операций чтения и записи.

6. Механизм рекомендаций:

Механизм рекомендаций использует инновационную математику в сочетании со специфическими знаниями для повышения вовлеченности в Интернете. Если вы разрабатываете его, вам понадобится быстрый уровень данных — для поддержки нескольких запросов на рекомендацию — и гибкий, поскольку вам потребуется либо большая пропускная способность, либо больше данных по мере развития вашей системы. Вам понадобится тот, который поддерживает высокую пропускную способность записи при ETL-обработке данных от ваших специалистов по данным или если вы записываете недавнее поведение, которое будут использовать ваши алгоритмы.

Aerospike — отличная база данных для систем рекомендаций. Ключевыми функциями являются большие списки (для эффективной записи поведения), оптимизированная поддержка Flash для обработки наборов данных от терабайтов до петабайтов, запросы и агрегации для отчетов в реальном времени, а также мощная поддержка таких языков, как Python и Go.

7. Может использоваться для очень больших наборов данных, таких как хэш геолокации. Если вы хотите хранить данные о расстоянии и продолжительности времени между двумя местоположениями и хотите кэшировать миллионы таких точек данных, Aerospike может вам помочь.

Техника управления памятью: Можно найти здесь.

Известные пользователи Aerospike: InMobi, Flipkart, Adobe, Snapdeal, AppsFlyer, PubMatric, Swiggy.

Hazelcast

Hazlecast — это сетка данных в памяти, представляющая собой кластерную систему с высокой доступностью и масштабируемостью. Это очень быстро, потому что автоматически распределяет и реплицирует данные между узлами. Это система кэширования на основе Java, которая хорошо вписывается в экосистему Java, хотя клиенты Hazlecast доступны и на других основных языках.

Hazelcast — это хранилище данных в памяти без схемы, которое примерно в 1000 раз быстрее, чем реляционная СУБД, достигая времени запроса и обновления, измеряемого в микросекундах для больших объемов данных.

Особенности:

1. Hazlecast не имеет главного узла. Все узлы похожи на master. Они поддерживают информацию метаданных, называемую «таблицей разделов». В таблице разделов хранится информация о деталях участников, состоянии кластера, информации о резервном копировании, перераспределении разделов и т. д. Клиенты Hazlecast также имеют доступ к этой «таблице разделов», поэтому они могут напрямую запрашивать связанный узел, где находятся данные.
2. Hazlecast распределяет копии данных по всем узлам в кластере. Поэтому, если узел выходит из строя, данные не теряются.
3. По мере появления все большего количества данных Hazlecast может расти и масштабироваться по горизонтали.
4. Это многопоточность. Следовательно, потенциально могут использоваться все ядра процессора.

Дополнительные функции здесь.

Подходящие варианты использования:

1. Hazlecast повторно реализует List, Map, Set, AtomicLong, AtomicReference, Countdown lath, чтобы их можно было безопасно использовать в кластерной/распределенной среде при доступе из приложений, работающих на нескольких узлах .
2. Hazlecast можно использовать для создания уникального идентификатора для многораздельных баз данных или других вариантов использования.
3. Он также реализует несколько распределенных вычислений, таких как запланированный исполнитель, служба исполнителя и т. д., которые будут использоваться в распределенной среде.

4.

Hazelcast IMDG обеспечивает кластеризацию веб-сеансов. Сеансы пользователей поддерживаются в кластере Hazelcast с использованием нескольких копий для обеспечения избыточности. В случае сбоя сервера приложений балансировщик нагрузки перенаправляется на новый сервер приложений, который имеет доступ к сеансу пользователя. Переход к новому серверу приложений для пользователя не вызывает затруднений. Это обеспечивает высочайший уровень клиентского опыта. Пример использования кластеризации веб-сеансов доступен для Tomcat и Jetty с использованием встроенной интеграции и любого сервера приложений с использованием фильтров.

5. Hazlecast также предпочтительнее в финансовой сфере. Подробнее здесь.

Здесь также больше вариантов использования.

Технология управления памятью: Hazlecast поддерживает LRU, LFU или ни один из них.

Известные пользователи Hazelcast: Ola cabs (Индия), American Express, Credit Suisse, Hyperwallet Systems, PayPal, Atlassian, Apache Camel, Twilio, Vert.x и т. д. хранилище документов NoSQL корпоративного уровня (можно использовать как ключ-значение или хранилище документов), которое представляет собой нечто большее, чем просто решение для кэширования, и предлагает функции, которые делают его менее сложным и адаптируемым большим количеством корпоративных игроков.

Couchbase был разработан для решения основных проблем, которые часто связаны с кэшированием, но на самом деле являются просто стандартными проблемами производительности и масштабируемости. Кроме того, Couchbase решает проблемы, связанные с высокой доступностью приложений, а также всесторонней надежностью данных с вариантами аварийного переключения.

Особенности:

1. Couchbase имеет архитектуру памяти в первую очередь, вся база данных может работать в памяти, что делает ее пригодной для сценариев кэширования. Couchbase создан для высокой производительности, он обеспечивает задержку менее миллисекунды.

Он также может обслуживать данные за пределами памяти, используя эффективные методы доступа к данным, которые поддерживают загрузку памяти последними обновлениями.

2. Couchbase также предлагает постоянство. Поэтому, если узел выходит из строя, данные не теряются.

3. Эластичная масштабируемость — это то, что если у вас есть много данных и вы хотите распределить их по узлам или кластерам, Couchbase может сделать это без большой нагрузки.

4. Couchbase предлагает репликацию между кластерами и центрами обработки данных (XCDR) для обеспечения высокой доступности.

5. Couchbase поддерживает запросы данных JSON с помощью собственного языка запросов N1QL.

6. Он также предлагает аналитические запросы в реальном времени, полнотекстовый поиск, обработку событий на стороне сервера.

7. Поддерживает автоматическое переключение приложений между кластерами.

8. Couchbase предлагает автоматическое сегментирование и использует клиентов с поддержкой кластера. Поэтому, когда вводится новая нода или нода уходит, вам не нужно делать шардинг, все будет происходить за кулисами.

9. Доступна корпоративная поддержка.

Подходящие варианты использования : Крупные предприятия, которым требуется кэширование + варианты использования NoSQL с простотой обслуживания, высокой доступностью и отказоустойчивостью, высокой пропускной способностью с автоматическим переключением при отказе, автоматическим сегментированием, простым мониторингом и административной поддержкой и т. д.

Ограничения : Можно найти здесь.

Некоторые известные пользователи: PayPal, Intuit, Viber, Tesco, AT&T, Verizon, Ebay и т. д.

На крупных предприятиях используется распределенный общий кэш. Таким образом, вы можете напрямую добавить зависимость для конкретного кеша в свое приложение, чтобы начать его использовать. Но это не очень подходящий метод, так как может случиться так, что в ближайшем будущем появится еще одно фантастическое решение для кэширования, и ваша организация решит его использовать. Таким образом, чтобы абстрагировать уровень кэширования от будущих проблем, кеш можно скрыть за службой. Все различные приложения могут взаимодействовать с кешем через вызовы API. Он инкапсулирует внутренние детали кеша, и команда кэширования сможет быстро вносить любые необходимые изменения, не меняя открытый интерфейс. Но как только вы решите пойти по этому пути, вы должны убедиться, что служба кэширования работает круглосуточно и без выходных. Таким образом, все проблемы, связанные с архитектурой микросервисов, будут справедливы для этого случая, но, тем не менее, вид абстракции и гибкости, которые должен предлагать сервис, бесценны для крупной организации.

В этом посте мы рассмотрели различные параметры при выборе и разработке собственной службы кэширования. Это не только большое / популярное название технологии или ваше знакомство с технологией, которая решает, что вы выберете, но и больше вариантов использования наших приложений, шаблон доступа к данным, тип объектов, которые мы хотим кэшировать, желаемая продолжительность данных, политика вытеснения , требования к инфраструктуре, желательное сохранение данных, требования к масштабируемости и кластеризации, доступность, объем данных и т. д., которые решают, какую технологию выбрать. Инженеры сами решают, как много внимания они хотят иметь, прежде чем выбрать что-то — это вполне нормальное поведение, когда люди выбирают технологию, к которой они уже привыкли, но точное знание всех этих параметров поможет вам принять лучшее дизайнерское решение.

Пожалуйста, дайте мне знать, если вы можете что-то добавить к этому сообщению, или я могу что-то улучшить, добавив комментарий ниже.

Ссылка:

[1] https://dzone.com/articles/introduction-amp-assimilating-caching-quick-read-fo

[2] https://www.itpro.co.uk /virtualisation/30271/our-5-minute-guide-to-distributed-caching

[3] https://docs.oracle.com/cd/E15357_01/coh.360/e15723/cache_rtwtwbra.htm#COHDG5181

[4] https://blogs.dropbox.com/tech/2012/10/caching-in-theory-and-practice/

[5] https://stackoverflow.com/questions/17759560/какая-есть-разница-между-lru-and-lfu

[6] https://stackoverflow.com/questions/44343510/in -what-case-lfu-is-better-than-lru

[7] https://devcenter.heroku.com/articles/advanced-memcache

[8] https://www.quora.com/What -use-cases-is-Redis-suitable-not-suitable-for-in-a-high-traffic-web-application-as-of-early-2016

[9] http://www.tothenew.com /блог/кеширование-что-почему-и-как-с-hazelcast/

[10] https://blog.hazelcast.com/hazelcast-use-cases/

[11] https://hazelcast.com/why-hazelcast/imdg/

[12] https://www . aerospike.com/products/features/

Что такое кэширование? | Microsoft Azure

Разработчики и ИТ-специалисты используют кэширование для сохранения и доступа к данным типа «ключ-значение» во временной памяти быстрее и с меньшими усилиями, чем данные, хранящиеся в обычном хранилище данных. Кэши полезны в нескольких сценариях с несколькими технологиями, такими как кэширование компьютера с оперативной памятью (ОЗУ), сетевое кэширование в сети доставки контента, веб-кэш для веб-мультимедийных данных или облачный кеш, чтобы помочь сделать облачные приложения более отказоустойчивыми. . Разработчики часто разрабатывают приложения для кэширования обработанных данных, а затем переназначают их для обслуживания запросов быстрее, чем при стандартных запросах к базе данных.

Вы можете использовать кэширование для снижения затрат на базу данных, обеспечения более высокой пропускной способности и меньшей задержки, чем может предложить большинство баз данных, а также для повышения производительности облачных и веб-приложений.

Как кэширование работает для баз данных?

Разработчики могут дополнить первичную базу данных кэшем базы данных, который они могут поместить в базу данных или приложение или настроить как отдельный уровень. Хотя они обычно полагаются на обычную базу данных для хранения больших, надежных и полных наборов данных, они используют кэш для хранения временных подмножеств данных для быстрого поиска.

Вы можете использовать кэширование со всеми типами хранилищ данных, включая базы данных NoSQL, а также реляционные базы данных, такие как SQL Server, MySQL или MariaDB. Кэширование также хорошо работает со многими конкретными платформами данных, такими как База данных Azure для PostgreSQL, База данных SQL Azure или Управляемый экземпляр Azure SQL. Мы рекомендуем изучить, какой тип хранилища данных лучше всего соответствует вашим требованиям, прежде чем вы начнете настраивать архитектуру данных. Например, вы хотели бы понять, что такое PostgreSQL, прежде чем использовать его для объединения реляционных и неструктурированных хранилищ данных.

Преимущества слоев кэша и что такое Redis?

Разработчики используют многоуровневые кэши, называемые уровнями кэша, для хранения различных типов данных в отдельных кэшах в соответствии с требованиями. Добавляя слой кэша или несколько, вы можете значительно улучшить пропускную способность и показатели задержки уровня данных.

Redis — это популярная структура данных в памяти с открытым исходным кодом, используемая для создания высокопроизводительных слоев кэша и других хранилищ данных. Недавнее исследование показало, что добавление кэша Azure для Redis к образцу приложения увеличило пропускную способность данных более чем на 800 % и уменьшило задержку более чем на 1000 %9.0972 1 .

Кэши также могут снизить совокупную стоимость владения (TCO) для уровня данных. Используя кэши для обслуживания наиболее распространенных запросов и снижения нагрузки на базу данных, вы можете снизить потребность в избыточном выделении экземпляров базы данных, что приведет к значительной экономии средств и снижению совокупной стоимости владения.

Типы кэширования

Ваша стратегия кэширования зависит от того, как ваше приложение читает и записывает данные. Ваше приложение требует интенсивной записи или данные записываются один раз и часто считываются? Всегда ли возвращаемые данные уникальны? Различные шаблоны доступа к данным будут влиять на то, как вы настраиваете кэш. К распространенным типам кэширования относятся резервное кэширование, сквозное чтение/сквозная запись и отложенная/обратная запись.

Cache-aside

Для приложений с большими рабочими нагрузками по чтению разработчики часто используют шаблон программирования без кэширования, или «побочный кэш». Они размещают дополнительный кэш за пределами приложения, которое затем может подключаться к кешу для запроса и извлечения данных или напрямую к базе данных, если данных нет в кеше. Когда приложение извлекает данные, оно копирует их в кеш для будущих запросов.

Дополнительный кэш можно использовать для повышения производительности приложений, обеспечения согласованности между кэшем и хранилищем данных и предотвращения устаревания данных в кэше.

Кэш со сквозной записью/чтением

Кэш со сквозной записью постоянно обновляется, а при кэшировании со сквозной записью приложение записывает данные в кеш, а затем в базу данных. Оба кеша находятся на одной линии с базой данных, и приложение рассматривает их как основное хранилище данных.

Кэш сквозного чтения помогает упростить приложения, в которых одни и те же данные запрашиваются снова и снова, но сам кэш сложнее, а двухэтапный процесс сквозной записи может создавать задержки. Разработчики объединяют их, чтобы обеспечить согласованность данных между кешем и базой данных, уменьшить задержку кеша сквозной записи и упростить обновление кеша сквозного чтения.

С помощью кэширования со сквозной записью и чтением разработчики могут упростить код приложения, повысить масштабируемость кэша и минимизировать нагрузку на базу данных.

Кэш отложенной/обратной записи

В этом сценарии приложение записывает данные в кэш, что немедленно подтверждается, а затем сам кеш записывает данные обратно в базу данных в фоновом режиме. Кэши с отложенной записью, иногда называемые кэшами с обратной записью, лучше всего подходят для рабочих нагрузок с интенсивной записью и повышают производительность записи, поскольку приложению не нужно ждать завершения записи, прежде чем переходить к следующей задаче.

Распределенный кэш и хранилище сеансов

Люди часто путают распределенные кэши с хранилищами сеансов, которые похожи, но имеют разные требования и цели. Вместо использования распределенного кеша для дополнения базы данных разработчики реализуют хранилища сеансов, которые являются временными хранилищами данных на пользовательском уровне для профилей, сообщений и других пользовательских данных в приложениях, ориентированных на сеансы, таких как веб-приложения.

Что такое хранилище сеансов?

Приложения, ориентированные на сеанс, отслеживают действия пользователей, когда они вошли в приложения. Чтобы сохранить эти данные при выходе пользователя из системы, вы можете хранить их в хранилище сеансов, что улучшает управление сеансами, снижает затраты и повышает производительность приложений.

Чем использование хранилища сеансов отличается от кэширования базы данных?

В хранилище сеансов данные не распределяются между разными пользователями, а при кэшировании разные пользователи могут получить доступ к одному и тому же кэшу. Разработчики используют кэширование для повышения производительности базы данных или экземпляра хранилища, а хранилища сеансов — для повышения производительности приложений за счет записи данных в хранилище в памяти, что устраняет необходимость доступа к базе данных вообще.

Данные, записанные в хранилище сеансов, обычно недолговечны, в то время как данные, кэшированные в первичной базе данных, обычно предназначены для гораздо более длительного хранения. Хранилище сеансов требует репликации, высокой доступности и надежности данных, чтобы гарантировать, что транзакционные данные не будут потеряны, а пользователи останутся вовлеченными. С другой стороны, если данные в стороннем кеше теряются, их копия всегда есть в постоянной базе данных.

Преимущества кэширования

Улучшена производительность приложений

Чтение данных из кэша в памяти выполняется намного быстрее, чем доступ к данным из дискового хранилища данных. А благодаря более быстрому доступу к данным общая работа с приложением значительно улучшается.

Сокращение использования базы данных и затрат

Кэширование приводит к меньшему количеству запросов к базе данных, повышению производительности и снижению затрат за счет ограничения необходимости масштабирования инфраструктуры базы данных и снижения платы за пропускную способность.

Масштабируемая и предсказуемая производительность

Один экземпляр кэша может обрабатывать миллионы запросов в секунду, предлагая уровень пропускной способности и масштабируемости, с которым не могут сравниться базы данных. Кэширование также обеспечивает гибкость, которая вам нужна, независимо от того, масштабируете ли вы свои приложения и хранилища данных. Тогда ваше приложение может разрешить нескольким пользователям одновременный доступ к одним и тем же файлам без увеличения нагрузки на серверные базы данных. И если приложение часто испытывает пики использования и высокую пропускную способность, кэши в памяти могут уменьшить задержку.

Для чего используется кэширование?

Кэширование вывода

Кэширование вывода помогает повысить производительность веб-страницы за счет сохранения полного исходного кода страниц, такого как HTML и клиентские сценарии, которые сервер отправляет в браузеры для отображения. Каждый раз, когда пользователь просматривает страницу, сервер кэширует выходной код в памяти приложения. Это позволяет приложению обслуживать запросы без запуска кода страницы или взаимодействия с другими серверами.

Кэширование данных и кэширование базы данных

Скорость и пропускная способность базы данных могут быть ключевыми факторами общей производительности приложения. Кэширование базы данных используется для частых обращений к данным, которые редко меняются, например к данным о ценах или запасах. Это помогает веб-сайтам и приложениям загружаться быстрее, увеличивая пропускную способность и снижая задержку при извлечении данных из серверных баз данных.

Хранение данных сеанса пользователя

Пользователи приложений часто создают данные, которые необходимо хранить в течение коротких периодов времени. Хранилище данных в памяти, такое как Redis, идеально подходит для эффективного и надежного хранения больших объемов данных сеанса, таких как пользовательский ввод, записи в корзине покупок или настройки персонализации, при меньших затратах, чем хранение или базы данных.

Брокеры сообщений и архитектуры публикации/подписки

Облачным приложениям часто необходимо обмениваться данными между службами, и они могут использовать кэширование для реализации архитектур публикации/подписки или брокера сообщений, которые уменьшают задержку и ускоряют управление данными.

Приложения и API

Как и браузеры, приложения сохраняют важные файлы и данные для быстрой перезагрузки этой информации при необходимости. Кэшированные ответы API устраняют потребность или нагрузку на серверы приложений и базы данных, обеспечивая более быстрое время отклика и лучшую производительность.

¹ Заявления о производительности основаны на данных исследования, которое было заказано Microsoft и проведено GigaOm в октябре 2020 года. В исследовании сравнивалась производительность тестового приложения с использованием базы данных Azure с использованием и без использования кэширования Azure Cache для Redis. решение. В качестве элемента базы данных в исследовании использовались База данных SQL Azure и База данных Azure для PostgreSQL. Экземпляр базы данных SQL Azure общего назначения с 2 виртуальными ядрами Gen5 и экземпляр базы данных Azure общего назначения с 2 виртуальными ядрами для PostgreSQL использовались с 6-гигабайтным экземпляром P1 Premium Azure для Redis.