REST сервис и Memcache

Question

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

Настройка:

• Оболочка базы данных, которая имеет функции для выбора, обновления и т. Д.
• Среда REST, которая содержит все функции API (getUser, createUser и т. Д.)

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

На мой взгляд, у меня есть несколько способов справиться с этим:

• Реализация Memcache в инфраструктуре REST для каждой функции (getUser, createUser и т. Д.) И, таким образом, явная обработка обновления кеша и т. Д., Если пользователи обновляются. Это может привести к избыточному коду.
• Пусть кэшированные значения очень быстро истекают и соответствуют тому факту, что некоторые запросы показывают старые кэшированные значения.
• Выполните более продвинутую реализацию Memcache в оболочке базы данных, чтобы я мог определить, какие части (например, пользователи) обновлять, например, в. поисковый запрос.

Не могли бы вы подсказать мне, какой из следующих или совершенно другой подход выбрать? Заранее спасибо.

Answer 1

Включение кэша для веб-приложения не является чем-то легким.

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

• http://en.wikipedia.org/wiki/Performance_tuning

Я обычно использую инструменты профилирования, такие как HXProf (от Facebook).

• https://github.com/facebook/xhprof

Кэширование всех ваших данных для зеркалирования базы данных может быть не лучшим подходом.

Узнайте, насколько большой вы можете выделить для вашего кэша. Если ваша архитектура позволяет вам выделить 100 МБ для кэша памяти, это повлияет на ваше решение о том, что вы кэшируете и как долго вы его кэшируете.

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

Всегда старайтесь убедиться, что вы не работаете над улучшением того, что принесет вам небольшое улучшение.

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

Может быть, вам следует вместо этого кэшировать выходные данные ваших веб-сервисов? Например, используя обратный прокси-сервер (о чем говорит @Darrel) или используя буферизацию вывода ...

• http://en.wikipedia.org/wiki/Reverse_proxy
• http://php.net/manual/en/book.outcontrol.php

Оптимизируйте запросы к базе данных, прежде чем думать о кэшировании. Убедитесь, что вы используете кэш PHP Op (например, APC) и все те вещи, которые являются стандартной практикой.

• http://phplens.com/lens/php-book/optimizing-debugging-php.php
• http://blog.digitalstruct.com/2008/01/31/performance-tuning-overview/

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

<?php
// After inserting into DB, you can also put it in the cache
$memcache->set($userId, $userData);

// After updating or deleting the user, you update or delete the data
$memcache->delete($userId);

На многих сайтах будут отображаться устаревшие данные. Когда я нахожусь на stackoverflow, и моя репутация увеличивается, а затем я попал в чат stackoverflow, показанная репутация - моя старая репутация. Когда я приобрел репутацию 20 (репутация необходима для чата), я все еще не мог общаться в течение еще 5 минут, потому что система чата имела мои старые данные о репутации и еще не знала, что моя репутация достаточно увеличилась, чтобы позволить мне общаться. Некоторые данные могут быть устаревшими, в то время как другие типы данных никогда не должны устаревать. Учтите, что при кешировании данных.

Заключение

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