PHP шаблоны дизайна memcache

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

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

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

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

Мой вопрос:

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

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

}

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

Ответ 4

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

Ответ 5

mysqlnd_qc, который вставляет memcaching на уровне возврата результатов запроса базы данных, автоматически устанавливает кеш-ответы из mysql. Это FANTASTIC и автоматический.