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

Обновлено: 07.07.2024

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

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

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

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

Начните работу с кэшированием: ускорьте рабочие нагрузки вашего приложения

Обзор кэширования

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

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

Рекомендации по кэшированию. При реализации уровня кэша необходимо принимать во внимание достоверность кэшируемых данных. Эффективный кэш обеспечивает высокую частоту попаданий, то есть наличия в кэше запрашиваемых данных. Промах кэша происходит, когда запрашиваемых данных в кэше нет. Для удаления из кэша неактуальных данных применяются такие механизмы, как TTL (время жизни). Следует также понимать, требуется ли для среды кэширования высокая доступность. Если она необходима, можно использовать сервисы в памяти, такие как Redis. В ряде случаев уровень в памяти можно использовать как отдельный уровень хранения данных, в отличие от кэширования из основного хранилища. Чтобы решить, подходит ли такой вариант, необходимо определить для данных в сервисе в памяти соответствующие значения RTO (требуемое время восстановления, то есть сколько времени требуется системе на восстановление после сбоя) и RPO (требуемая точка восстановления, то есть последняя восстанавливаемая точка или транзакция). Для соответствия большинству требований RTO и RPO можно применять характеристики и проектные стратегии разных сервисов в памяти.

Ускорение получения веб-контента от веб-сайтов (браузеры или устройства)

Кэширование с помощью Amazon ElastiCache

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

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

Повышение производительности приложений

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

Сокращение затрат на базы данных

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

Снижение нагрузки на серверную часть

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

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

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

Устранение проблемных мест в базах данных

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

Повышение пропускной способности операций чтения (количество операций ввода-вывода в секунду)

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

Алгоритм сохранения музыки из ВКонтакте в кэш-память.

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

ВНИМАНИЕ. В последнем обновлении, утилита ВКонтакте для портативных устройств, лишилась возможности кэширования треков. Если вам всё же нужно кэшировать её — установите более старую версию приложения и отключите обновления, или слушайте музыку онлайн.

Кэшируем аудио в приложении

Для кэширования, сложных манипуляций не требуется, стоит только прослушать аудио онлайн с программы (или просто включить и дождаться пока шкала загрузки дойдёт до конца). После файл отмечается флажком у вас в списке, что означает его сохранение в кэш-память. Прослушать кэшированный трек, можно просто зайдя в раздел «Музыка – Сохранённые» (при отсутствии интернет сети раздел открывается автоматически при входе в аудио).

Сохраняем аудио файлом с кэша приложения (Android)

Извлекаем прослушанную вами мелодию аудиофайлом:

Сохраняем аудиофайлом с приложения кэш (IOS)

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

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

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

Кэширование работает практически во всех программах и приложениях. Некоторые данные очищаются автоматически, а другие копятся на жестком диске. Это создает дополнительную нагрузку на память устройства. Замедляется работа смартфона, ноутбука, компьютера. Интернет «зависает». Некоторые уверены: дело — в провайдере. Но даже если вы подключите самую высокую скорость (например, 1 Гб/с от МТС ), сайты все равно не будут грузиться быстрее, пока вы не очистите кэш.

Как чистить кэш, сколько раз в месяц это нужно делать

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

Рассказываем, как чистить кэш на Android:

Откройте настройки смартфона.
Перейдите в раздел «Устройство».
Выберите вкладку «память» или «хранилище» (в зависимости от модели смартфона).
Кликните на «данные кэша» или «cache».
Нажмите «Очистить» либо «clear cache».
Подтвердите действие.

Как очистить кэш на iOS:

Откройте настройки.
Найдите вкладку браузера Safari.
Нажмите на вкладку и выберите «Очистить историю и данные».
Подтвердите действие.

Имейте в виду: вместе с кэшем в айфоне удалится вся история посещений.

Как очистить кэш на компьютере или ноутбуке

Кэш на компьютере обычно чистят через данные локального диска:

Откройте системный диск (как правило это локальный диск C).
Кликните по нему правой кнопкой мышки и выберите вкладку «Свойства».
В разделе «Общие» есть пункт «Очистка диска». Нажмите на эту кнопку.
Выберите «Очистить системные файлы». Поставьте галочки напротив основных разделов, где хранится кэш:

— временные файлы интернета;

— файлы для отчетов об ошибках;

Нажмите «Ок» и дождитесь, пока система удалит ненужные данные.

Процесс может занять некоторое время.

Есть еще один вариант: очистить кэш не в самом устройстве, а в браузере. Зайдите в тот, которым обычно пользуетесь (Mozilla Firefox, Google Chrome, Opera). Нажмите в правом верхнем углу на три точки или три горизонтальные полоски (в разных браузерах разные значки). Откроются настройки. Найдите вкладку «История» и нажмите «Очистить». Хотите, чтобы некоторые сайты сохранились в памяти? Добавьте их в закладки (для этого зайдите на страницу и нажмите комбинацию клавиш Ctrl+D).

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

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

Давайте прокрутим полный оборот ситуаций.

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

И в шаблонах в нужном месте вставляем что-нибудь вроде:

(ну или даже <?=sprintf(".2f", get_current_rate("USD","EUR"))?> , но это прошлый век).

Вот тут на сцену выходит его величество Кэш

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

Сказано – сделано! Добавляем несколько строчек:

Это самый главный аспект кэша: хранение последнего результата.

И вуаля! Сайт снова становится для нас почти бесплатным… До конца месяца, когда мы обнаруживаем от внешней системы счет на 4 евро. Конечно, не 6, но мы ожидали намного большей экономии!

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

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

В случае с memcache это можно реализовать, например, так:

И вот, наконец, потребление сравнялось с ожидаемым — 1 запрос в 5 секунд, расходы сократились до 2 евро в месяц.

Почему 2? Было 6 без кэширования для тысячи человек, мы же всё закэшировали, а сократилось всего в 3 раза? Да, стоило просчитать пораньше… 1 раз в 5 секунд = 12 в минуту = 72 в час = 576 за рабочий день = 17 тысяч в месяц, а ещё не все ходят по расписанию, есть странные личности заглядывающие поздней ночью… Вот и получается, в пике вместо сотни обращений одно, а в тихое время — по-прежнему запрос почти на каждое обращение проходит. Но всё равно, даже в худшем случае счёт должен быть 31×86400÷5 = 5.36 евро.

Так мы познакомились с еще одной гранью: кэш помогает, но не устраняет нагрузку.

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

Упражнение для читателя: посмотреть внимательно предыдущий код и найти причину.

Кстати, это грабли отнюдь не только кэша, это общий аспект распределённых блокировок: важно освобождать блокировки и иметь таймауты, во избежание дедлоков. Если бы мы добавляли "?" вообще без времени жизни, всё б замирало при первой же ошибке связи с внешней системой. К сожалению, memcache не предоставляет хороших способов для создания распределённых блокировок, использование полноценной БД с блокировками на уровне строк лучше, но это было просто лирическое отступление, необходимое просто потому, что на эти грабли наступили.

Итак, мы исправили проблему, вот только ничего не изменилось: всё равно изредка начинались тормоза. Что примечательно, они совпадали по времени с информационным бюллетенем от внешней системы о технических работах…

Ну-ка ну-ка… Давайте сделаем краткую передышку и пересчитаем, что мы насобирали уже сейчас, что должен уметь кэш:

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

Отсюда: кэш обязан уметь какое-то время хранить отрицательный результат. Наше наивное исходное предположение по сути подразумевает хранение отрицательного результата 0 секунд (но передачу этого самого отрицания всем, кто уже ждёт его). К сожалению, в случае с Memcache реализация нулевого времени ожидания весьма проблематична (оставлю как домашнее задание въедливому читателю; cовет: используйте механизм CAS; и да, в AppEngine можно использовать и Memcache и Memcached).

Мы же просто добавим сохранение отрицательного значения с 1 секундой жизни:

Казалось бы, ну теперь-то уже всё, и можно успокоиться? Как бы не так. Пока мы росли, наш любимый внешний сервис тоже рос, и в какой-то момент начал иногда тормозить и отвечать аж по секунде… И что примечательно – вместе с ним начал тормозить и наш сайт! Причем снова для всех! Но почему? Мы же всё кэшируем, в случае ошибок запоминаем ошибку и тем самым отпускаем всех ожидающих сразу, разве нет?

…А вот и нет. Внимательно посмотрим на код еще раз: запрос ко внешней системе будет исполняться столько, сколько позволит file_get_contents() . На время исполнения запроса все остальные ждут, поэтому каждый раз, когда кэш устаревает, все потоки ждут исполнения главного, и получат новые данные только, когда они поступят.

Что ж, мы можем вместо ожидания, добавить ветку else<> у условия вокруг memcache->add … Правда, стоит, наверное, вернуть последнее известное значение, да? Ведь мы кэшируем ровно затем, что мы согласны получить устаревшие сведения, если нет свежих; итак, еще одно требование к кэшу: пусть подтормаживает не более одного запроса.

Итак, мы снова победили: даже если тормозит внешний сервис, подтормаживает не более одной страницы… То есть как бы среднее время ответа сократилось, но пользователи всё равно немного недовольны.

Примечание: обычный PHP по умолчанию пишет сессии в файлы, блокируя параллельные запросы. Чтобы избежать этого поведения, можно передать в session_start параметр read_and_close либо принудительно закрывать через session_close сессию после совершения всех необходимых изменений, иначе тормозить будет не одна страница, а один пользователь: так как скрипт, обновляющий значение, будет блокировать открытие сессии другим запросом от того же пользователя. При исполнении на AppEngine по умолчанию включено хранение сессий в memcache, то есть без блокировок, поэтому будет проблема не так заметна.

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

Что же мы можем сделать в такой постановке вопроса? Мы можем:

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

В числе прочих побочных эффектов участились случаи показа устаревшего курса. [Мда… в общем, представьте, что мы сейчас говорим не про наш случай, а про что-нибудь более сложное, где устаревание видно невооруженным глазом :) на самом деле, даже в простом случае обязательно найдётся пользователь, который заметит такие совершенно неочевидные косяки].
Смотрите, что получается:

Пришел запрос 1, данных в кэше нет, так что добавили маркер '?' на 5 секунд и пошли за курсом.
Спустя 1 секунду пришел запрос номер 2, увидел маркер '?', вернул данные из stale записи.
Спустя 3 секунды пришел запрос номер 3, увидел маркер '?', вернул stale.
Спустя 1 секунду маркер '?' устарел, несмотря на то, что запрос 1 всё еще ждет ответа.
Спустя еще 2 секунды пришел запрос номер 4, маркера нет, добавляет новый маркер и отправляется за курсом.
…
Запрос 1 получил ответ, сохранил результат.
Пришел запрос X, получил актуальный ответ из кэша 1-го вопроса (а когда пришел тот ответ? На момент запроса, или момент ответа? –, этого никто не знает…).
Запрос номер 4 получил ответ, сохранил результат – причем снова непонятно, был ли этот ответ более новый или более старый.

Итак, давайте подведём промежуточный итог. В бытовом понимании кэш:

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

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

кэш может быть потерян в любой момент времени. Даже наши маркеры блокировки исполнения '?' могут быть потеряны, если параллельно еще 10 тысяч пользователей гуляет по сайту, все сохраняя что-то (зачастую время последнего обращения на сайт) в сессию, которая лежит на том же кэш-сервере; после того как маркер потерян («кэш отравлен»), следующий запрос опять начнёт процедуру обновления значения в кэше;
чем быстрее исполняется запрос в удалённой системе, тем меньше запросов будет дедуплицировано в случае отравления кэша.

Рассмотрим простейший случай:

Мы смотрим на систему в спокойном состоянии, и видим среднее время исполнения 0.05 сек.
Вывод: 1 процесс может обслужить 20 запросов в секунду, значит, для 100 запросов в секунду достаточно 5 процессов.
Вот только если время обновления запроса возрастает до 2 секунд, то получается:
1 процесс занят обновлением (в течение 2 секунд);
в течение этих 2 секунд у нас доступно только 4 процесса = 80 запросов в секунду.

3600. Что означает, что если отравление наступило на 5000 запросах в минуту, до тех пор, пока нагрузка не упадёт с 5000 до 3000 система нестабильна. То есть любой (даже пиковый!) всплеск трафика потенциально может вызвать длительную нестабильность системы.

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

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

Читайте также: