Memcached: a distributed memory object caching system

Кэширование и memcached / Хабр

Этим постом хочу открыть небольшую серию постов по материалам доклада на HighLoad++-2008. Впоследствии весь текст будет опубликован в виде одной большой PDF-ки.

Введение

Memcached и кэширование

Принцип локальности

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

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

Memcached

Самые простые операции – получить значение указанного ключа (get), установить значение ключа (set) и удалить ключ (del). Для реализации цепочки атомарных операций (при условии конкурентного доступа к memcached со стороны параллельных процессов) используются дополнительные операции: инкремент/декремент значения ключа (incr/decr), дописать данные к значению ключа в начало или в конец (append/prepend), атомарная связка получения/установки значения (gets/cas) и другие.

Memcached был реализован Брэдом Фитцпатриком (Brad Fitzpatrick) в рамках работы над проектом ЖЖ (LiveJournal). Он использовался для разгрузки базы данных от запросов при отдаче контента страниц. Сегодня memcached нашел своё применение в ядре многих крупных проектов, например, Wikipedia, YouTube, Facebook и другие.

Общая схема кэширования

В общем случае схема кэширования выглядит следующим образом: frontend’у (той части проекта, которая формирует ответ пользователю) требуется получить данные какой-то выборки. Frontend обращается к быстрому как гепард серверу memcached за кэшом выборки (get-запрос). Если соответствующий ключ будет обнаружен, работа на этом заканчивается. В противном случае следует обращение к тяжелому, неповоротливому, но мощному (как слон) backend’у, в роли которого чаще всего выступает база данных. Полученный результат сразу же записывается в memcached в качестве кэша (set-запрос). При этом обычно для ключа задается максимальное время жизни (срок годности), который соответствует моменту сброса кэша.

Такая стандартная схема кэширования реализуется всегда. Вместо memcached в некоторых проектах могут использоваться локальные файлы, иные способы хранения (другая БД, кэш PHP-акселератора и т.п.) Однако, как будет показано далее, в высоконагруженном проекте данная схема может работать не самым эффективным образом. Тем не менее, в нашем дальнейшем рассказе мы будем опираться именно на эту схему.

Архитектура memcached

Во-первых, memcached спроектирован так, чтобы все его операции имели алгоритмическую сложность O(1), т.е. время выполнения любой операции не зависит от количества ключей, которые хранит memcached. Это означает, что некоторые операции (или возможности) будут отсутствовать в нём, если их реализация требует всего лишь линейного (O(n)) времени.

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

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

По сути, можно сказать, что время отклика сервера memcached определяется только сетевыми издержками и практически равно времени передачи пакета от frontend’а до сервера memcached (RTT). Такие характеристики позволяют использовать memcached в высоконагруженных web-проектов для решения различных задач, в том числе и для кэширования данных.

Потеря ключей

1. Ключ был удален раньше окончания его срока годности в силу нехватки памяти под хранение значений других ключей. Memcached использует политику LRU, поэтому такая потеря означает, что данный ключ редко использовался и память кэша освобождается для хранения более популярных ключей.
2. Ключ был удален, так как истекло его время жизни. Такая ситуация строго говоря не является потерей, так как мы сами ограничили время жизни ключа, но для клиентского по отношению к memcached кода такая потеря неотличима от других случаев – при обращении к memcached мы получаем ответ «такого ключа нет».
3. Самой неприятной ситуацией является крах процесса memcached или сервера, на котором он расположен. В этой ситуации мы теряем все ключи, которые хранились в кэше. Несколько сгладить последствия позволяет кластерная организация: множество серверов memcached, по которым «размазаны» ключи проекта: так последствия краха одного кэша будут менее заметны.

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

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

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

«Совсем не должны терять». Memcached удобен для хранения сессий пользователей – все сессии равнодоступны со всех серверов, входящих в кластер frontend’ов. Так вот содержимое сессий не хотелось бы терять никогда – иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно дублировать ключи сессий на нескольких серверах memcached из кластера, так вероятность потери снижается.

Memcached | Распределенное хранилище данных типа «ключ-значение» | AWS

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

Время отклика на уровне долей миллисекунды

Простота и удобство

Простота и универсальность делают Memcached мощным и очень удобным решением для разработки приложений. При работе с Memcached разработчики получают в распоряжение множество готовых клиентов с открытым исходным кодом. Поддерживаемые языки программирования включают Java, Python, PHP, C, C++, C#, JavaScript, Node.js, Ruby, Go и многие другие.

Возможность масштабирования

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

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

Модуль ngx_http_memcached_module

Модуль ngx_http_memcached_module

Модуль ngx_http_memcached_module позволяет получать ответ из сервера memcached. Ключ задаётся в переменной $memcached_key. Ответ в memcached должен быть предварительно помещён внешним по отношению к nginx’у способом.

Пример конфигурации

server {
    location / {
        set            $memcached_key "$uri?$args";
        memcached_pass host:11211;
        error_page     404 502 504 = @fallback;
    }

    location @fallback {
        proxy_pass     http://backend;
    }
}

Директивы

Эта директива появилась в версии 0. 8.22.

Задаёт локальный IP-адрес с необязательным портом (1.11.2), который будет использоваться в исходящих соединениях с сервером memcached. В значении параметра допустимо использование переменных (1.3.12). Специальное значение off (1.3.12) отменяет действие унаследованной с предыдущего уровня конфигурации директивы memcached_bind, позволяя системе самостоятельно выбирать локальный IP-адрес и порт.

Параметр transparent (1.11.0) позволяет задать нелокальный IP-aдрес, который будет использоваться в исходящих соединениях с сервером memcached, например, реальный IP-адрес клиента:

memcached_bind $remote_addr transparent;

Для работы параметра обычно требуется запустить рабочие процессы nginx с привилегиями суперпользователя. В Linux этого не требуется (1.13.8), так как если указан параметр transparent, то рабочие процессы наследуют capability CAP_NET_RAW из главного процесса. Также необходимо настроить таблицу маршрутизации ядра для перехвата сетевого трафика с сервера memcached.

memcached_buffer_size 4k|8k;

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

memcached_connect_timeout 60s;

Задаёт таймаут для установления соединения с сервером memcached. Необходимо иметь в виду, что этот таймаут обычно не может превышать 75 секунд.

memcached_force_ranges off;

Эта директива появилась в версии 1.7.7.

Включает поддержку диапазонов запрашиваемых байт (byte-range) для кэшированных и некэшированных ответов сервера memcached вне зависимости от наличия поля “Accept-Ranges” в заголовках этих ответов.

Эта директива появилась в версии 1. 3.6.

Включает проверку указанного флага в ответе сервера memcached и установку поля “Content-Encoding” заголовка ответа в “gzip”, если этот флаг установлен.

memcached_next_upstream error timeout;

Определяет, в каких случаях запрос будет передан следующему серверу:

error

произошла ошибка соединения с сервером, передачи ему запроса или чтения заголовка ответа сервера;

timeout

произошёл таймаут во время соединения с сервером, передачи ему запроса или чтения заголовка ответа сервера;

invalid_response

сервер вернул пустой или неверный ответ;

not_found

сервер не нашёл ответ;

off

запрещает передачу запроса следующему серверу.

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

Директива также определяет, что считается неудачной попыткой работы с сервером. Случаи error, timeout и invalid_response всегда считаются неудачными попытками, даже если они не указаны в директиве. Случай not_found никогда не считается неудачной попыткой.

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

memcached_next_upstream_timeout 0;

Эта директива появилась в версии 1. 7.5.

Ограничивает время, в течение которого возможна передача запроса следующему серверу. Значение 0 отключает это ограничение.

memcached_next_upstream_tries 0;

Эта директива появилась в версии 1.7.5.

Ограничивает число допустимых попыток для передачи запроса следующему серверу. Значение 0 отключает это ограничение.

Задаёт адрес сервера memcached. Адрес может быть указан в виде доменного имени или IP-адреса, и порта:

memcached_pass localhost:11211;

или в виде пути UNIX-сокета:

memcached_pass unix:/tmp/memcached.socket;

Если доменному имени соответствует несколько адресов, то все они будут использоваться по очереди (round-robin). И, кроме того, адрес может быть группой серверов.

memcached_read_timeout 60s;

Задаёт таймаут при чтении ответа сервера memcached. Таймаут устанавливается не на всю передачу ответа, а только между двумя операциями чтения. Если по истечении этого времени сервер memcached ничего не передаст, соединение закрывается.

memcached_send_timeout 60s;

Задаёт таймаут при передаче запроса серверу memcached. Таймаут устанавливается не на всю передачу запроса, а только между двумя операциями записи. Если по истечении этого времени сервер memcached не примет новых данных, соединение закрывается.

memcached_socket_keepalive off;

Эта директива появилась в версии 1.15.6.

Конфигурирует поведение “TCP keepalive” для исходящих соединений к серверу memcached. По умолчанию для сокета действуют настройки операционной системы. Если указано значение “on”, то для сокета включается параметр SO_KEEPALIVE.

Встроенные переменные

$memcached_key

Задаёт ключ для получения ответа из сервера memcached.

Установка и настройка Memcached в Ubuntu

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

Также вы можете установить данное приложение при оформлении заказа в один клик.
Подробное описание данного One-Click-Apps

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

Перед установкой обновим систему:

# apt-get update && apt-get upgrade

Теперь используйте следующую команду для установки Memcached и модуля memcache для PHP:

# apt-get install memcached php5-memcache

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

# netstat -tap | grep memcached
tcp 0 0 localhost:11211 *:* LISTEN 21488/memcached  

По умолчанию порт memcached 11211 с IP:127. 0.0.1 (localhost).

Также есть возможность отредактировать эти настройки, например вы хотите открыть доступ из внешнего IP, то нужно отредактировать файл настроек memcached — /etc/memcached.conf.

-l 127.0.0.1

параметр отвечает за IP адрес, который слушает демон memcached.

-m 256

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

-p 11211

стандартный порт, который слушает демон memcached.

Далее требуется перегрузить веб сервер для подключения модуля memcache

/etc/init.d/apache2 restart

Или перезагрузить сам конфигурационный файл:

/etc/init.d/memcached restart

Настройка фаэрвола для Memcached

Добавьте следующие правила для разрешения соединения (для работы memcached):

iptables -A INPUT -p tcp --destination-port 11211 -m state --state NEW -m iprange --src-range 111. 161.1.10-111.161.1.15 -j ACCEPT  
iptables -A INPUT -p udp --destination-port 11211 -m state --state NEW -m iprange --src-range 111.161.1.10-111.161.1.15 -j ACCEPT  

открыть все исходящие порты

iptables -P OUTPUT ACCEPT  

открыть порт 80 для всех входящих соединений

iptables -A INPUT —dport 80 -j ACCEPT  

открыть 22 и 5432 порты только для конкретного IP

iptables -A INPUT -m multiport —dports 22,5432 -s IP_ADDRESS -j ACCEPT  

Установка и настройка memcached в CentOS 7 и Debian 9

1. Установка сервиса memcached

Сама по себе установка Memcached не вызовет проблем. Вам достаточно выполнить такую команду:

Установка memcached в Centos 7

yum install memcached -y

Установка memcached в Debian 9

apt-get install memcached -y

Настройка memcached

Вся настройка выполняется через изменение файла конфигурации /etc/memcahced.conf. В этом файле содержаться опции, которые будут переданы сервису при запуске:

• -d — работать в режиме сервиса;
• -v — режим более подробного вывода информации;
• -vv — ещё более подробный вывод информации;
• -m — количество оперативной памяти, которую будет использовать сервис, рекомендую увеличить этот параметр, так как значения 64 мегабайта, установленных по умолчанию, будет мало;
• -p — порт, на котором будет работать сервис;
• -u — пользователь, от имени которого запущен сервис;
• -l — IP-дрес, на котором Memcached будет ожидать соединения, лучше использовать 127. 0.0.1, чтобы из внешней сети ни у кого не было доступа к вашим данным;
• -с — количество одновременных подключений;
• -P — путь к PID-файлу сервиса в файловой системе.

Таким образом, большинство опций можно оставить по умолчанию. Изменить нужно только объём оперативной памяти (не забудьте что оперативная память не бесконечная) и IP-адрес (но для Битрикса хватит и 127.0.0.1).
После изменения конфигурации не забудьте перезапустить сам сервис командой:

systemctl restart memcached

Сбор статистики использования memcached

memcstat --servers="127.0.0.1"

Как видите установить и настроить memcached для работы совершенно не сложно. Осталось только выполнить настройки на стороне Битрикса: 

1. Включить хранение сессий в memcached
2. Настроить хранение файлов композита 1С-Битрикс на memcached

Почему Redis превосходит Memcached по кешированию

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

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

Redis и Memcached для кеширования

Начнем с общих черт. И Memcached, и Redis служат хранилищами данных «ключ-значение» в памяти, хотя Redis более точно описывается как хранилище структур данных. И Memcached, и Redis принадлежат к семейству решений для управления данными NoSQL, и оба основаны на модели данных «ключ-значение». Они оба хранят все данные в ОЗУ, что, конечно же, делает их чрезвычайно полезными в качестве уровня кэширования.С точки зрения производительности два хранилища данных также удивительно похожи, демонстрируя почти идентичные характеристики (и показатели) в отношении пропускной способности и задержки.

И Memcached, и Redis — зрелые и очень популярные проекты с открытым исходным кодом. Memcached был первоначально разработан Брэдом Фитцпатриком в 2003 году для веб-сайта LiveJournal. С тех пор Memcached был переписан на C (исходная реализация была на Perl) и помещен в общественное достояние, где он стал краеугольным камнем современных веб-приложений.Текущая разработка Memcached ориентирована на стабильность и оптимизацию, а не на добавление новых функций.

Redis был создан Сальваторе Санфилиппо в 2009 году, и сегодня Санфилиппо остается ведущим разработчиком проекта. Redis иногда называют «Memcached на стероидах», что неудивительно, учитывая, что некоторые части Redis были созданы с учетом уроков, извлеченных из использования Memcached. Redis имеет больше функций, чем Memcached, и поэтому он более мощный и гибкий.

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

Почему так популярны Memcached и Redis? Они не только чрезвычайно эффективны, но и относительно просты. Начало работы с Memcached или Redis считается легкой работой для разработчика. Их настройка и подготовка к работе с приложением занимает всего несколько минут. Таким образом, небольшие затраты времени и усилий могут оказать немедленное драматическое влияние на производительность — обычно на порядки.Простое решение с огромной пользой; это настолько близко к магии, насколько это возможно.

Когда использовать Memcached

Memcached может быть предпочтительнее при кэшировании относительно небольших и статических данных, таких как фрагменты кода HTML. Управление внутренней памятью Memcached, хотя и не такое сложное, как у Redis, более эффективно в простейших случаях использования, поскольку оно потребляет сравнительно меньше ресурсов памяти для метаданных. Строки (единственный тип данных, поддерживаемый Memcached) идеально подходят для хранения данных, которые только читаются, поскольку строки не требуют дальнейшей обработки.

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

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

Когда использовать Redis

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

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

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

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

Redis для сохранения данных

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

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

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

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

Redis Репликация данных в памяти

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

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

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

Redis для анализа данных

На ум сразу приходят три сценария аналитики. В первом сценарии при использовании чего-то вроде Apache Spark для итеративной обработки больших наборов данных вы можете использовать Redis в качестве уровня обслуживания для данных, ранее рассчитанных Spark. Во втором сценарии использование Redis в качестве общего распределенного хранилища данных в памяти может повысить скорость обработки Spark в 45–100 раз. Наконец, очень распространенный сценарий — это сценарий, в котором отчеты и аналитика должны настраиваться пользователем, но получение данных из изначально пакетных хранилищ данных (таких как Hadoop или СУБД) занимает слишком много времени. В этом случае хранилище структуры данных в памяти, такое как Redis, является единственным практическим способом получить субмиллисекундное время подкачки и ответа.

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

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

—

Итамар Хабер (@itamarhaber) — главный защитник разработчиков в Redis Labs, которая предлагает Memcached и Redis в качестве полностью управляемых облачных сервисов для разработчиков. Его разнообразный опыт включает разработку и управление программными продуктами, а также руководящие должности в Xeround, Etagon, Amicada и MNS Ltd. Итамар имеет степень магистра делового администрирования по совместной программе Kellogg-Recanati Северо-Западного и Тель-Авивского университетов, а также степень бакалавра. наук в области компьютерных наук.

Форум новых технологий предоставляет площадку для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор является субъективным и основан на нашем выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы для публикации и оставляет за собой право редактировать весь предоставленный контент. Все запросы отправляйте на [email protected].

Авторские права © IDG Communications, Inc., 2017.

Что такое Memcached? — Поддержка KeyCDN

Обновлено 4 октября 2018 г.

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

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

Что такое Memcached?

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

• Результаты вызовов базы данных
• Вызовы API
• Отрисовка страницы

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

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

Как работает Memcached?

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

1. Клиент запрашивает часть данных, которые Memcached проверяет, хранятся ли они в кэше.
2. Здесь есть два возможных результата:
   1. Если данные хранятся в кеше: вернуть данные из Memcached (нет необходимости проверять базу данных).
   2. Если данные не хранятся в кэше: запросите базу данных, получите данные и впоследствии сохраните их в Memcached.
3. Каждый раз при изменении информации или истечении срока действия элемента Memcached обновляет свой кэш, чтобы гарантировать доставку нового содержимого клиенту.

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

• Данные отправляются только на один сервер.
• Серверы не обмениваются данными.
• Серверы хранят значения в ОЗУ. Если RAM заканчивается, самое старое значение отбрасывается.

Установка Memcached

Есть несколько способов установить Memcached. В зависимости от того, какую систему вы используете, метод будет отличаться. Как указано в официальной вики установки Memcached, установка из пакета проста.Если вы используете Debian или Ubuntu, используйте следующий фрагмент:

  apt-get install memcached
  

Для пользователей Redhat / Fedora используйте следующее:

  yum install memcached
  

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

Сводка

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

Обзор Memorystore для Memcached | Google Cloud

На этой странице представлена ​​служба Memorystore для Memcached, включая варианты использования, ключевые концепции и преимущества использования Memcached.

Memorystore for Memcached — это хорошо масштабируемая, полностью управляемая служба Memcached для Google Cloud. Служба построена на базе Memcached с открытым исходным кодом и совместима с двоичным кодом и протоколом ASCII. Доступ к этой службе можно получить с помощью стандартных клиентских библиотек OSS Memcached на всех языках, что позволяет легко поднимать и переносить существующие приложения практически без изменений кода.

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

Чтобы узнать больше о Memcached, см. Страницу о программном обеспечении с открытым исходным кодом (OSS), посвященном Memcached.

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

Ключевые концепции

Memorystore for Memcached позволяет создать полностью управляемый кластер Memcached. Перед использованием сервиса важно понять некоторые ключевые понятия и термины.

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

• Узел Memcached — это основная единица экземпляра Memcached. Перед созданием кластера важно определить количество узлов, объем памяти на узел и количество виртуальных ЦП на узел, которые будут использоваться для создания кластера Memcached. Конфигурация узла и количество узлов зависит от размера набора данных, допуска к потере ключа и характеристик рабочей нагрузки.У каждого узла есть IP-адрес и порт. Вы можете получить список IP-адресов всех узлов вручную или с помощью службы Auto Discovery.

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

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

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

• Авторизованная сеть VPC указывает, какую сеть Google VPC использует ваш экземпляр. Авторизованная сеть устанавливается во время создания экземпляра и не может быть изменена позже. Для работы с Memorystore для Memcached в сети VPC необходимо установить соединение для доступа к частным службам. Только ресурсы и пользователи, имеющие доступ к авторизованной сети VPC, могут получить доступ к экземпляру.

• Доступ к частным службам необходимо установить соединение для авторизованной сети VPC, которую использует экземпляр Memcached, прежде чем вы сможете создать экземпляр Memcached.Мы рекомендуем вам связаться с вашей группой по сети / безопасности для настройки соединения перед созданием экземпляра. Соединение для доступа к частным службам позволяет создавать экземпляры с использованием внутренних IP-адресов и предоставляет администраторам контроль над диапазоном внутренних IP-адресов, используемых экземплярами Memorystore. Для получения дополнительной информации см. Сеть.

• Конфигурации позволяют устанавливать определенные конфигурации Memcached во время создания экземпляра, а также позволяют изменять конфигурации во время выполнения. Список поддерживаемых конфигураций см. В разделе Конфигурации Memcache.

• Служба автоматического обнаружения предоставляет клиентам Memcached программный способ обнаружения всех узлов в кластере. Клиенты могут периодически запрашивать конечную точку обнаружения, чтобы получить список IP-адресов узлов. Список обычно используется для распределения ключей по всем узлам с использованием согласованного хеширования. Использование службы Auto Discovery особенно полезно для сред, в которых периодически увеличивается количество узлов в экземпляре.Дополнительные сведения см. В разделе Служба автоматического обнаружения.

В следующей таблице представлены различные функции и возможности, доступные Memorystore для Memcached:

Функции и возможности	Описание
Версия Memcached	В настоящее время сервис поддерживает версию 1.5.16
Размер экземпляра	Экземпляр может иметь максимум 20 узлов. Все узлы имеют одинаковую конфигурацию.Узел может иметь минимум 1 виртуальный ЦП и максимум 32 виртуальных ЦП. Минимальный объем памяти на узел составляет 1 ГБ, а максимальный поддерживаемый объем памяти на узел — 256 ГБ. Память может быть указана с шагом 1 ГБ. Максимальный размер экземпляра — 5 ТБ.
Масштабирование экземпляра	Вы можете масштабировать экземпляр по горизонтали, увеличивая или уменьшая количество узлов. Вертикальное масштабирование ваших узлов требует воссоздания экземпляра.
Конфигурации Memcached	Вы можете настроить экземпляр для своей конкретной рабочей нагрузки.Список конфигураций см. В разделе Конфигурации Memcached.
Безопасность и контроль доступа	Доступ к экземпляру ограничен клиентами, подключенными к VPC вашего проекта. Сеть. Если экземпляр использует общую сеть VPC, все клиенты в Общая сеть VPC может получить доступ к экземпляру. Аутентификация на уровне экземпляра недоступна. Операции администратора контролируются с помощью ролей управления идентификацией и доступом, перечисленных на Контроль доступа страница.
Опора платформы	Доступ к Memorystore для Memcached можно получить со следующих платформ. Поддерживаемые платформы: Не поддерживается:
Клиентские библиотеки	Поддерживаются все стандартные клиентские библиотеки Memcached на всех языках.
Сервис Auto Discovery	Включает программное обнаружение узлов в экземпляре. Поддержка автоматического обнаружения в настоящее время доступна в следующих клиентах: Вы также можете изменить любые существующие клиенты Memcached, чтобы добавить автоматическое обнаружение служба поддержки.Для получения дополнительной информации см. Сервис Auto Discovery. Служба Auto Discovery также совместима с большинством клиентов, поддерживающих Автоматическое обнаружение AWS Elasticache.
Мониторинг	Memorystore для Memcached предоставляет метрики и информационные панели в облачной консоли для мониторинга экземпляра. Дополнительные сведения см. В разделе Мониторинг экземпляров Memcached.

Что дальше

Memcache | Стандартная среда App Engine для Python 2

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

Когда использовать кэш памяти

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

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

Уровни обслуживания

App Engine поддерживает два уровня службы memcache:

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

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

Оба уровня обслуживания memcache используют один и тот же API. Чтобы настроить службу memcache для вашего приложения см. Использование Memcache.

В следующей таблице приведены различия между двумя классами. службы memcache:

Плата за выделенный кэш памяти взимается с шагом 15 минут.6 байтов).

Ключ не может быть больше 250 байт. В среде выполнения Python ключи, которые являются строками более 250 байт будут хешированы. (Другие среды выполнения ведут себя иначе.)

Срок действия кэшированных данных

Memcache содержит пары ключ / значение.Пары в памяти в любой момент меняются как элементы записываются и извлекаются из кеша.

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

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

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

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

Вы можете стереть весь кеш приложения через API или в кэше памяти. раздел Google Cloud Console.

Статистика кеша

Операций в секунду по размеру элемента

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

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

Приложение, настроенное на несколько ГБ кеш-памяти, теоретически может достичь совокупного скорость работы вычисляется как количество ГБ, умноженное на скорость за ГБ.Например, приложение, настроенное на 5 ГБ кеш-памяти, может достичь 50 000 кешей памяти. операций / сек для элементов размером 1 КБ. Достижение этого уровня требует хорошей раздачи. нагрузки через пространство ключей кэша памяти.

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

Вычислительные блоки Memcache (MCU)

Memcache может варьироваться в зависимости от размера элемента, к которому вы обращаетесь. и операцию, которую вы хотите выполнить с элементом. Вы можете примерно связать стоить с операциями и оценить пропускную способность трафика, которую вы можете ожидать от выделенный кэш памяти с использованием модуля, называемого Memcache Compute Unit (MCU). MCU — это определены таким образом, что вы можете ожидать 10 000 MCU в секунду на 1 ГБ выделенного кэш памяти. Консоль Google Cloud показывает, сколько MCU в настоящее время использует ваше приложение.

Обратите внимание, что MCU — это приблизительная статистическая оценка, а также не линейная Блок.Каждая операция кеширования, которая читает или записывает значение, имеет соответствующий MCU. Стоимость, которая зависит от размера стоимости. MCU для набора зависит от размер значения: это в 2 раза превышает стоимость успешной операции get-hit .

Операции, которые не читают и не записывают значение, имеют фиксированную стоимость MCU:

Обратите внимание, что операция get-miss — это операция get , которая обнаруживает, что значение отсутствует хранится с указанным ключом.

Сравнить и установить

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

Ключевые логические компоненты сравнения и установки

Если вы обновляете значение ключа кэша памяти, который может получить другой одновременных запросов на запись, вы должны использовать объект memcache Client , который хранит определенную информацию о состоянии, используемую методами которые поддерживают сравнить и установить. Вы не можете использовать функции memcache get () или set () , потому что они не имеют состояния. Сам класс Client не является потокобезопасный, поэтому вам не следует использовать один и тот же объект Client более чем в одном нить.

Когда вы извлекаете ключи, вы должны использовать методы memcache Client , которые поддерживают сравнить и установить: gets () или get_multi () с параметром for_cas , установленным на Правда .

При обновлении ключа необходимо использовать методы memcache Client , которые поддерживают сравните и установите: cas () или cas_multi () .

Другой ключевой логический компонент — это служба кэша памяти App Engine и ее поведение в отношении сравнения и набора. Сам сервис memcache в App Engine ведет себя атомарно. То есть, когда два параллельных запроса (для одного и того же идентификатора приложения) использовать memcache, они перейдут к тому же экземпляру службы memcache, а Служба memcache имеет достаточную внутреннюю блокировку, так что одновременные запросы для тот же ключ правильно сериализован. В частности, это означает, что два cas () запросы на один и тот же ключ фактически не выполняются параллельно — служба обрабатывает первый поступивший запрос до завершения (то есть обновление значения и timestamp) перед тем, как он начнет обрабатывать второй запрос.

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

Лучшие практики

Ниже приведены некоторые рекомендации по использованию memcache:

• Изящно обрабатывать сбои API memcache. Операции с Memcache могут завершиться ошибкой по разным причинам. Приложения должны быть разработаны так, чтобы ловить неудачные операций, не подвергая эти ошибки конечным пользователям. Это руководство особенно относится к операциям Set.

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

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

  Например, вы можете разделить часто обновляемый счетчик между несколько ключей, считывая их и суммируя только тогда, когда вам нужна сумма.Точно так же вы можете разделить 500 КБ данных, которые должны быть прочитаны на каждом HTTP-запрос по нескольким ключам и считывание их с помощью одного пакета Вызов API. (Еще лучше было бы кэшировать значение в памяти экземпляра.) Для выделенного кэша памяти пиковая скорость доступа для одного ключа должна быть 1-2. на несколько порядков меньше, чем рейтинг на гигабайт.

Что дальше

Эффективное кэширование в распределенных приложениях — Real Python

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

Python предлагает встроенные возможности для кэширования, от простого словаря до более полной структуры данных, такой как functools.lru_cache . Последний может кэшировать любой элемент, используя алгоритм Least-Recently Used для ограничения размера кеша.

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

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

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

Установка memcached

Memcached доступен для многих платформ:

• Если вы используете Linux , вы можете установить его с помощью apt-get install memcached или yum install memcached . Это установит memcached из предварительно созданного пакета, но вы также можете собрать memcached из исходного кода, как описано здесь.
• Для macOS использование Homebrew — самый простой вариант. Просто запустите brew install memcached после установки диспетчера пакетов Homebrew.
• В Windows вам придется скомпилировать memcached самостоятельно или найти предварительно скомпилированные двоичные файлы.

После установки memcached можно просто запустить, вызвав команду memcached :

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

Сохранение и получение кэшированных значений с использованием Python

Если вы никогда не использовали memcached , это довольно легко понять.По сути, это огромный словарь, доступный в сети. Этот словарь имеет несколько свойств, которые отличаются от классического словаря Python, в основном:

• Ключи и значения должны быть байтами
• Ключи и значения автоматически удаляются по истечении времени

Следовательно, две основные операции для взаимодействия с memcached : set и get . Как вы могли догадаться, они используются для присвоения значения ключу или для получения значения из ключа соответственно.

Моя любимая библиотека Python для взаимодействия с memcached — pymemcache — я рекомендую ее использовать. Вы можете просто установить его с помощью pip:

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

  >>> из базы импорта pymemcache.client

# Не забудьте запустить `memcached 'перед запуском следующей строки:
>>> client = base.Client (('локальный хост', 11211))

# После создания экземпляра клиента вы можете получить доступ к кешу:
>>> клиент.set ('some_key', 'какое-то значение')

# Снова получить ранее установленные данные:
>>> client.get ('some_key')
'некоторая ценность'
  

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

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

Автоматическое истечение срока хранения кэшированных данных

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

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

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

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

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

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

Звучит сложнее, чем есть на самом деле. Обычно при работе с memcached в Python можно использовать следующий шаблон:

  из pymemcache.клиентская база импорта


def do_some_query ():
    # Заменить фактическим кодом запроса к базе данных,
    # удаленный REST API и т. д.
    возврат 42


# Не забудьте запустить `memcached 'перед запуском этого кода
client = base.Client (('локальный хост', 11211))
результат = client.get ('some_key')

если результат None:
    # Кеш пуст, нужно получить значение
    # из канонического источника:
    результат = do_some_query ()

    # Кешировать результат для следующего раза:
    client.set ('some_key', результат)

# Нужно ли нам обновлять кеш или нет,
# на этом этапе вы можете работать с данными
# хранится в переменной `result`:
печать (результат)
  

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

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

Разогрев холодного кэша

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

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

pymemcache предоставляет класс с именем FallbackClient , который помогает в реализации этого сценария, как показано здесь:

  из pymemcache.клиентская база импорта
из резервной копии импорта pymemcache


def do_some_query ():
    # Заменить фактическим кодом запроса к базе данных,
    # удаленный REST API и т. д.
    возврат 42


# Установите `ignore_exc = True`, чтобы можно было завершить работу
# старый кеш перед удалением его использования из
# программа, если когда-нибудь понадобится.
old_cache = base.Client (('localhost', 11211), ignore_exc = True)
new_cache = base.Client (('локальный хост', 11212))

client = fallback.FallbackClient ((новый_кэш, старый_кэш))

результат = client.get ('some_key')

если результат None:
    # Кеш пуст, нужно получить значение
    # из канонического источника:
    результат = do_some_query ()

    # Кешировать результат для следующего раза:
    клиент.set ('some_key', результат)

печать (результат)
  

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

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

Проверка и установка

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

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

  def on_visit (клиент):
    result = client.get ('посетители')
    если результат None:
        результат = 1
    еще:
        результат + = 1
    client.set ('посетители', результат)
  

Однако что произойдет, если два экземпляра приложения попытаются обновить этот счетчик одновременно?

Первый вызов client.get ('Посетители') вернет одинаковое количество посетителей для них обоих, скажем, 42.Затем оба прибавят 1, вычисят 43 и установят количество посетителей на 43. Это число неверно, и результат должен быть 44, то есть 42 + 1 + 1.

Для решения этой проблемы параллелизма удобна операция CAS memcached . Следующий фрагмент кода реализует правильное решение:

  def on_visit (клиент):
    в то время как True:
        результат, cas = client.gets ('посетители')
        если результат None:
            результат = 1
        еще:
            результат + = 1
        если клиент.cas ('посетители', результат, cas):
            перерыв
  

Метод gets возвращает значение, как и метод get , но также возвращает значение CAS .

То, что находится в этом значении, не имеет значения, но оно используется для следующего вызова метода cas . Этот метод эквивалентен операции set , за исключением того, что он не работает, если значение изменилось, поскольку получает операцию . В случае успеха цикл разрывается.В противном случае операция возобновляется с самого начала.

В сценарии, когда два экземпляра приложения пытаются обновить счетчик одновременно, только одному удается переместить счетчик с 42 на 43. Второй экземпляр получает значение False , возвращаемое вызовом client.cas , и нужно повторить цикл. На этот раз он получит 43 как значение, увеличит его до 44, и его вызов cas завершится успешно, тем самым решив нашу проблему.

Увеличение счетчика интересно в качестве примера, объясняющего, как работает CAS, потому что это упрощенно.Однако memcached также предоставляет методы incr и decr для увеличения или уменьшения целого числа в одном запросе, вместо того, чтобы выполнять несколько вызовов get / cas . В реальных приложениях получает и cas используются для более сложных типов данных или операций

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

Помимо кэширования

Простые методы, проиллюстрированные в этой статье, показали, насколько легко использовать memcached для повышения производительности вашего приложения Python.

Просто используя две основные операции «установить» и «получить», вы часто можете ускорить извлечение данных или избежать повторного вычисления результатов снова и снова. С memcached вы можете совместно использовать кеш среди большого количества распределенных узлов.

Другие, более сложные шаблоны, которые вы видели в этом руководстве, например, операция Check And Set (CAS) , позволяют обновлять данные, хранящиеся в кэше, одновременно в нескольких потоках или процессах Python, избегая при этом повреждения данных.

Если вам интересно узнать больше о продвинутых методах написания более быстрых и масштабируемых приложений Python, ознакомьтесь с Scaling Python. Он охватывает множество сложных тем, таких как сетевое распределение, системы очередей, распределенное хеширование и профилирование кода.

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

 КЭШИ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        "МЕСТОПОЛОЖЕНИЕ": "127.0.0.1:11211",
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.memcached.PyMemcacheCache ',
        'МЕСТОПОЛОЖЕНИЕ': 'unix: /tmp/memcached.sock',
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'МЕСТО РАСПОЛОЖЕНИЯ': [
            '172.19.26.240:11211',
            '172.19.26.242:11211',
        ]
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'МЕСТО РАСПОЛОЖЕНИЯ': [
            '172.19.26.240:11211',
            '172.19.26.242:11212',
            '172.19.26.244:11213',
        ]
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.db.DatabaseCache',
        'LOCATION': 'my_cache_table',
    }
}
 

 управление питоном.py createcachetable
 

 класс CacheRouter:
    "" "Маршрутизатор для управления всеми операциями с кешем базы данных" ""

    def db_for_read (сам, модель, ** подсказки):
        «Все операции чтения из кеша переходят в реплику»
        если модель._meta.app_label == 'django_cache':
            вернуть 'cache_replica'
        return None

    def db_for_write (сам, модель, ** подсказки):
        «Все операции записи в кэш переходят в основной»
        если model._meta.app_label == 'django_cache':
            вернуть 'cache_primary'
        return None

    def allow_migrate (self, db, app_label, model_name = None, ** подсказки):
        «Устанавливать модель кеша только на основной»
        если app_label == 'django_cache':
            вернуть db == 'cache_primary'
        return None
 

 КЭШИ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.filebased.FileBasedCache ',
        'МЕСТОПОЛОЖЕНИЕ': '/ var / tmp / django_cache',
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'МЕСТОПОЛОЖЕНИЕ': 'c: / foo / bar',
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.locmem.LocMemCache',
        "МЕСТО": "уникальная снежинка",
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'BACKEND': 'path.to.backend',
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.filebased.FileBasedCache ',
        'МЕСТОПОЛОЖЕНИЕ': '/ var / tmp / django_cache',
        «ТАЙМ-АУТ»: 60,
        'ПАРАМЕТРЫ': {
            "MAX_ENTRIES": 1000
        }
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
        "МЕСТО": "127.0.0.1: 11211 ',
        'ПАРАМЕТРЫ': {
            'двоичный': Верно,
            'имя пользователя': 'пользователь',
            'пароль': 'пароль',
            'behavior': {
                "ketama": Верно,
            }
        }
    }
}
 

 КЭШИ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.memcached.PyMemcacheCache ',
        "МЕСТОПОЛОЖЕНИЕ": "127.0.0.1:11211",
        'ПАРАМЕТРЫ': {
            'no_delay': Верно,
            ignore_exc: Верно,
            'max_pool_size': 4,
            'use_pooling': Верно,
        }
    }
}
 

 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ = [
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
]
 

 из django.views.decorators.cache import cache_page

@cache_page (60 * 15)
def my_view (запрос):
    ...
 

 urlpatterns = [
    путь ('foo /  /', my_view),
]
 

 @cache_page (60 * 15, cache = "special_cache")
def my_view (запрос):
    ...
 

 @cache_page (60 * 15, key_prefix = "site1")
def my_view (запрос):
    ...
 

 urlpatterns = [
    путь ('foo /  /', my_view),
]
 

 из django.views.decorators.cache import cache_page

urlpatterns = [
    путь ('foo /  /', cache_page (60 * 15) (my_view)),
]
 

 {% загрузки кеша%}
{% cache 500 боковая панель%}
    .. боковая панель ..
{% endcache%}
 

 {% загрузки кеша%}
{% cache 500 sidebar request.user.username%}
    .. боковая панель для вошедшего в систему пользователя ..
{% endcache%}
 

 {% load i18n%}
{% загрузки кеша%}

{% get_current_language как LANGUAGE_CODE%}

{% cache 600 добро пожаловать LANGUAGE_CODE%}
    {% translate "Добро пожаловать в пример.com "%}
{% endcache%}
 

 {% cache 600 sidebar%} ... {% endcache%}
{% cache my_timeout боковая панель%} ... {% endcache%}
 

 {% cache 300 local-thing ... using = "localcache"%}
 

 >>> из django.кеш импорта core.cache
>>> из django.core.cache.utils import make_template_fragment_key
# ключ кеша для {% cache 500 имя пользователя боковой панели%}
>>> key = make_template_fragment_key ('боковая панель', [имя пользователя])
>>> cache.delete (key) # делает недействительным кешированный фрагмент шаблона
Правда
 

 >>> # Подождите 30 секунд, пока истечет срок действия my_key ...
>>> cache.get ('my_key')
Никто
 

 >>> часовой = объект ()
>>> кеш.get ('my_key', sentinel) - дозорный
Ложь
>>> # Подождите 30 секунд, пока истечет срок действия my_key ...
>>> cache.get ('my_key', sentinel) - дозорный
Правда
 

 >>> cache.get ('my_key', 'истек')
'истек'
 

 >>> кеш.set ('add_key', 'Начальное значение')
>>> cache.add ('add_key', 'Новое значение')
>>> cache.get ('add_key')
'Начальное значение'
 

 >>> cache.get ('my_new_key') # не возвращает None
>>> cache.get_or_set ('my_new_key', 'мое новое значение', 100)
"моя новая ценность"
 

 >>> дата и время импорта
>>> cache.get_or_set ('ключ-отметка времени', datetime.datetime.now)
datetime.datetime (2014, 12, 11, 0, 15, 49, 457920)
 

 >>> cache.set ('а', 1)
>>> cache.set ('b', 2)
>>> cache.set ('c', 3)
>>> cache.get_many (['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}
 

 >>> cache.set_many ({'a': 1, 'b': 2, 'c': 3})
>>> cache.get_many (['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}
 

 >>> cache.delete ('а')
Правда
 

 >>> cache.delete_many (['a', 'b', 'c'])
 

 >>> cache.touch ('а', 10)
Правда
 

 >>> cache.set ('число', 1)
>>> cache.incr ('число')
2
>>> cache.incr ('число', 10)
12
>>> cache.decr ('число')
11
>>> cache.decr ('число', 5)
6
 

 >>> # Установить версию 2 ключа кеширования
>>> cache.set ('my_key', 'привет, мир!', версия = 2)
>>> # Получить версию по умолчанию (при условии, что версия = 1)
>>> cache.get ('my_key')
Никто
>>> # Получить 2 версию того же ключа
>>> cache.get ('my_key', версия = 2)
'Привет мир!'
 

 >>> # Увеличить версию my_key
>>> cache.incr_version ('my_key')
>>> # Версия по умолчанию все еще недоступна
>>> cache.get ('my_key')
Никто
# Версия 2 тоже недоступна
>>> cache.get ('my_key', версия = 2)
Никто
>>> # Но есть версия 3 * *
>>> cache.get ('my_key', версия = 3)
'Привет мир!'
 

 def make_key (ключ, префикс ключа, версия):
    вернуть '% s:% s:% s'% (префикс_ключа, версия, ключ)
 

 предупреждения об импорте

из django.core.cache import CacheKeyWarning

предупреждения.simplefilter ("игнорировать", CacheKeyWarning)
 

 из django.core.cache.backends.locmem импорт LocMemCache

класс CustomLocMemCache (LocMemCache):
    def validate_key (сам, ключ):
        "" "Пользовательская проверка, создание исключений или предупреждений по мере необходимости."" "
        ...
 

 из django.views.decorators.vary импортировать var_on_headers

@vary_on_headers ("Пользователь-агент")
def my_view (запрос):
    ...
 

 @vary_on_headers ('User-Agent', 'Cookie')
def my_view (запрос):
    ...
 

 @vary_on_cookie
def my_view (запрос):
    ...

@vary_on_headers ('Cookie')
def my_view (запрос):
    ...
 

 из django.shortcuts import render
из django.utils.cache импортировать patch_vary_headers

def my_view (запрос):
    ...
    response = render (запрос, 'имя_шаблона', контекст)
    patch_vary_headers (ответ, ['Cookie'])
    ответ на ответ
 

 из django.views.decorators.cache импорт cache_control

@cache_control (частный = Истина)
def my_view (запрос):
    ...
 

 из django.views.decorators.cache импортировать patch_cache_control
из джанго.views.decorators.vary import var_on_cookie

@vary_on_cookie
def list_blog_entries_view (запрос):
    если request.user.is_anonymous:
        response = render_only_public_entries ()
        patch_cache_control (ответ, общедоступный = True)
    еще:
        response = render_private_and_public_entries (request.user)
        patch_cache_control (ответ, частный = True)

    ответ на ответ
 

 из django.views.decorators.cache импорт cache_control

@cache_control (max_age = 3600)
def my_view (запрос):
    ...
 

 из django.views.decorators.cache импорт never_cache

@ Never_cache
def myview (запрос):
    ...
 

 memcached_buffer_size 4k | 8k; 

 memcached_connect_timeout 60 с; 

 memcached_force_ranges выключено; 

 время ожидания ошибки memcached_next_upstream; 

 memcached_next_upstream_timeout 0; 

 memcached_next_upstream_tries 0; 

 memcached_read_timeout 60 с; 

 memcached_send_timeout 60 с; 

 memcached_socket_keepalive выключен;