Рубрики
Uncategorized

Основное введение и принцип работы MemCache

Автор оригинала: David Wong.

Официальная записка:

MemCache-это бесплатная, с открытым исходным кодом, высокопроизводительная система кэширования объектов распределенной памяти для динамических веб-приложений с целью снижения нагрузки на базу данных. Кэшируя данные и объекты в памяти, он может сократить время чтения базы данных, тем самым повышая скорость доступа к веб-сайту. MemCaChe-это хэш-карта, в которой хранятся пары ключ-значение для любых данных в памяти (таких как строки, объекты и т.д.). Данные могут поступать из вызовов базы данных, вызовов API или результатов рендеринга страниц. Концепция дизайна Memcache небольшая и мощная. Его простой дизайн способствует быстрому развертыванию, простой разработке и решению многих сложных проблем, стоящих перед крупномасштабным кэшированием данных. Открытый API позволяет использовать MemCache в большинстве популярных языков программирования, таких как Java, C/C++/C#, Perl, Python, PHP, Ruby и так далее.

Дополнение:

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

MemCache и MemCached:

MemCache-это имя проекта, а MemCached-это имя основной программы на стороне сервера.

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

В приложениях мы обычно используем MemCached на следующих узлах:

  1. Частый доступ к данным базы данных (токен идентификации, динамика домашней страницы)
  2. Условия и результаты часто используемых запросов
  3. Хранение в виде сеанса (Повышение производительности доступа к сеансу)
  4. Кэш страниц
  5. Частое обновление несущественных данных (объем посетителей, количество кликов)
  6. Много горячих данных

Общий рабочий процесс (как показано ниже):

  1. Клиент запрашивает данные
  2. Проверьте, есть ли соответствующие данные в MemCached
  3. Некоторые слова возвращаются прямо и заканчиваются.
  4. Если нет, перейдите в базу данных и запросите данные.
  5. Запишите данные в MemCached для использования при следующем запросе
  6. Возвращаемые данные, конец

(Примечание: Данные базы данных, кэшированные в MemCached, должны обновляться одновременно с обновлением базы данных)

MemCached использует архитектуру C/S для мониторинга клиентских запросов в виде демонов после запуска сервера. При запуске вы можете указать IP (ip-адрес сервера в интрасети/ip-адрес экстранета), номер порта (поэтому при распределенном тестировании сервер может запускать несколько процессов MemCached с разными номерами портов), объем памяти и другие ключевые параметры. После запуска услуга останется доступной. Для повышения производительности все данные, кэшированные MemCached, хранятся в памяти, управляемой MemCached, поэтому кэшированные данные будут пустыми после перезапуска сервера, и сохранение не поддерживается.

(1) Управление памятью в памяти

Структура памяти

  1. В slab_class вы храните набор плит одинакового размера
  2. Каждая плита содержит несколько страниц. Размер страниц по умолчанию-1 м. Если размер сляба составляет 100 м, он содержит 100 страниц.
  3. Каждая страница содержит несколько блоков, которые являются фактическими единицами хранения данных. Куски в каждой плите одинакового размера.

Выделение памяти

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

Пример:

Расположение значения в MemCache определяется размером значения. Значение хранится в слябе, который ближе всего к размеру куска. Например, размер блока сляба [1] составляет 88 байт, размер блока сляба [2] составляет 112 байт, а размер блока сляба [3] составляет 144 байта.( По умолчанию куски в соседних плитах растут в соотношении 1,25, которое может быть указано – F при запуске MemCache. Затем значение в 100 байт будет помещено в таблицу 2.

Способ переработки памяти

  1. Когда объем данных исчерпывается памятью, выделенной MemCached, он основан на алгоритме LRU (Наименее текущем) Используемом), очищающем недопустимые кэшированные данные( Время сбоя может быть установлено при вводе данных Или очистке наименее недавно использованных кэшированных данных и вводе новых данных.
  2. В LRU MemCached использует стратегию отложенного истечения срока действия, которая не отслеживает, истекает ли срок действия сохраненной пары ключ/vlue, но проверяет метку времени записи при получении значения ключа и проверяет, истекает ли срок действия пары ключ/значение. Это может снизить нагрузку на сервер.
  3. Обратите внимание, что если загрузка MemCache не добавляет – M, LRU отключен, и в этом случае недостаточно памяти, чтобы сообщить об ошибке нехватки памяти.

В соответствии с алгоритмом выделения и восстановления памяти MemCache суммируются три пункта:

  1. Блок выделения памяти Memcache тратит память впустую. выделение 88-байтового значения в 128-байтовом блоке теряет 30 байт, но это также позволяет избежать проблемы управления фрагментацией памяти.
  2. Алгоритм LRU MemCache является не глобальным, а слэбовым.
  3. Должно быть понятно, почему размер значения MemCache ограничен, потому что при поступлении новых данных slab сначала подаст заявку на часть памяти в страницах. Максимальный объем используемой памяти составляет всего 1 м, поэтому размер значения MemCache, естественно, не может быть больше 1 м.

(2) Распределенные MemCached

In order to improve the storage capacity and performance of MemCached, our client may provide services corresponding to multiple MemCached servers, which is the distribution of MemCached.

Принцип распределенной реализации

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

Клиентская сторона указывает серверную сторону по IP-адресу и номеру порта. Данные, которые будут кэшироваться, будут храниться на стороне сервера в виде пар ключ – > значение. Значение ключа преобразуется с помощью хэша, и значение передается на определенный сервер в соответствии со значением хэша. Когда необходимо получить данные об объекте, это также делается в соответствии с ключом. Сначала ключ хэшируется, и полученное значение может определить, на каком сервере он хранится, а затем на Сервер отправляется запрос. Клиенту нужно только знать, на каком сервере сохраняется значение хэша (ключа).

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

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

  1. Остаточный алгоритм: Этот метод прост и эффективен, но почти все кэши выходят из строя, когда memcached серверы увеличиваются или уменьшаются.
  2. Алгоритм хэширования: Сначала вычислите хэш-значение сервера MemCached и распределите его по кругу с 32 мощностями 0-2. Затем используйте тот же метод для вычисления хэш-значения ключа, хранящего данные, и сопоставьте его с кругом. Наконец, поиск по часовой стрелке запускается с места сопоставления данных, и данные сохраняются на первом найденном сервере. Если 32-мощность 2 превышена, а сервер все еще не найден, данные сохраняются. Сохраните его на первом сервере MemCached. Если будет добавлен сервер MemCached, будут затронуты ключи на первом сервере, который добавляет сервер только в направлении против часовой стрелки на круге.

(3) Управление потоками MemCached

MemCached network model is a typical single-process multi-threaded model. It uses libevent to process network requests. The main process is responsible for assigning new connections to the work thread, and the work thread is responsible for handling connections. It is similar to load balancing, and is distributed to the corresponding worker threads through the main process.

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

  1. Основной поток отвечает за инициализацию сервера MemCached и прослушивание запросов на подключение к домену TCP и Unix.
  2. Пул рабочих потоков, MemCached по умолчанию содержит четыре рабочих потока, которые могут быть изменены параметрами запуска для обработки запросов по ссылкам интерфейса сокетов домена TCP, UDP и Unix.
  3. Assoc поддерживает потоки, а в памяти MemCached поддерживается огромная хэш-таблица, которая отвечает за динамический рост хэш-таблиц.
  4. Slb поддерживает потоки, то есть модуль управления памятью поддерживает потоки, отвечающие за баланс блоков в классе, которые могут быть закрыты в опции запуска MemCached.

Подробнее: MemCache – Модель сетевого потока – Анализ примитивного кода

  1. Нет ограничений на объем данных элементов, которые могут быть сохранены в MemCache, если в нем достаточно памяти
  2. Один процесс Memcache использует 2 ГБ памяти на 32-разрядных компьютерах, о чем много раз упоминалось в предыдущих статьях, в то время как 64-разрядные компьютеры не имеют ограничений.
  3. Ключ имеет максимум 250 байт и не может быть сохранен сверх этой длины
  4. Максимальное количество данных для одного элемента составляет 1 МБ, а данные более 1 МБ не сохраняются.
  5. Сервер MemCache небезопасен. Например, если известен узел Memcached, он может напрямую сообщить о прошлом, и flush_all немедленно сделает существующие значения ключей недействительными. Поэтому сервер MemCache лучше всего настраивается для среды интрасети, обеспечивая доступ к клиентам через брандмауэры.
  6. Невозможно просмотреть все элементы в MemCache, поскольку эта операция выполняется относительно медленно и блокирует другие операции.
  7. Высокая производительность MemCached обеспечивается двухэтапной структурой хэша: первый этап выполняется на стороне клиента, где узел вычисляется с помощью алгоритма хэширования на основе значения ключа; второй этап выполняется на стороне сервера, где внутренний алгоритм хэширования используется для поиска реального элемента и возврата его клиенту. С точки зрения реализации MemCache-это неблокирующая серверная программа, основанная на событиях
  8. Когда значение ключа добавляется в параметр MemCache, передача значения истечения срока действия 0 указывает на то, что значение Ключа является постоянным, и срок действия значения ключа также истечет через 30 дней. Смотрите исходный код memcache.c:__________
#define REALTIME_MAXDELTA 60*60*24*30
static rel_time_t realtime(const time_t exptime) {
       if (exptime == 0) return 0;
       if (exptime > REALTIME_MAXDELTA) { 
              if (exptime <= process_started) 
                     return (rel_time_t)1; 
              return (rel_time_t)(exptime - process_started); 
       } else { 
              return (rel_time_t)(exptime + current_time); 
       }
}

Читайте ещё по теме: