Паттерны проектирования PHP memcache

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

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

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

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

}

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

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

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