Шаблоны проектирования PHP memcache

Question

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

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

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

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

Мой вопрос ..

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

Я использую компонент Zend Cache (вам не нужно использовать весь фреймворк только для Zend-кэша, если хотите). Он абстрагирует некоторые элементы кэширования (он поддерживает группировку кэша по «тегам», хотя эта функция не поддерживается для серверной части memcache. Я относительно легко применил собственную поддержку «тегов»). Итак, шаблон, который я использую для функций, обращающихся к кешу (как правило, в моей модели):

public function getBySlug($ignoreCache = true)
{
    if($ignoreCache || !$result = $this->cache->load('someKeyBasedOnQuery'))
    {
        $select = $this->select()
                ->where('slug = ?', $slug);
        $result = $this->fetchRow($select);

        try
        {
            $this->cache->save($result,'someKeyBasedOnQuery');
        }
        catch(Zend_Exception $error)
        {
          //log exception
        }
    }
    else
    {
        $this->registry->logger->info('someKeyBasedOnQuery came from cache');
    }
    return $result;

}

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

Answer 4

Мы также храним результаты запроса из нашей базы данных (PostgreSQL) в memcache, и мы используем триггеры для таблиц, чтобы сделать недействительным кеш - там есть несколько API (например, pgmemcache , я думаю, что MySQL что-то подобное тоже, но я точно не знаю). Преимущество заключается в том, что база данных self (триггеры) может обрабатывать аннулирование данных об изменениях (обновление, вставка, удаление), вам не нужно записывать все эти вещи в ваше «приложение».

Answer 5

mysqlnd_qc, который вставляет кэширование памяти на уровне возврата результатов запроса к базе данных, авто кеширует наборы результатов из mysql ФАНТАСТИЧЕСКИЙ и автоматический.