SaveTheRbtz Dec 3 2011 at 17:36

Борьба с одновременным перестроением кеша с помощью RED

6 min

PHP*

+39

Comments 23

UFO just landed and posted this here

frig Dec 3 2011 at 22:05

В топике тоже упоминается вариант с блокировками. И даже написано, что это «правильный подход».

UFO just landed and posted this here

frig Dec 3 2011 at 22:40

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

AndryX Dec 3 2011 at 21:32

Мне ваш дисклеймер понравился, нужно добавить себе это в резюме :).

+10

squint Dec 3 2011 at 21:35

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

mipxtx Dec 3 2011 at 22:11

Интересная идея, спасибо вам за нее.
Правда у нас кеш не протухает, а перетирается обновлениями. те мы проблему решили железом — больше мемкешей, меньше вытеснения и неограниченное время жизни. В нашем случае еще меньше обращений к бд (по сути только запись) и еще меньше время ответа

akalend Dec 4 2011 at 19:27

а патч автопролонгейт не пробовали?
очень помогает во многих случаях

mipxtx Dec 4 2011 at 20:58

Не вижу в нем смысла. Инвалидация кеша должна происходить по изменению сущностей, а не по времени. А наименее запрашиваемые объекты мемкеш и так вытеснит. Я не утверждаю, что инвалидация по времени — зло. Но в абсолютном большинстве случаев она порождает нарушение целостности данных

akalend Dec 5 2011 at 22:29

согл. если сущность изменилась — то данные долны быть инвалидированы. Это можно сделать сразу после изменения сущности, а не при запросе данных.

fisher Dec 4 2011 at 00:50

а можно подробнее, почему приведенный первый график описывает именно ту самую проблему одновременного доступа к кешу? казалось бы, трафик вырос — и число соединений тоже.

SaveTheRbtz Dec 4 2011 at 01:53

Проблему одновременного перестроения кеша описывают «маленькие красные горбики», которые после применения патча исчезли.

fisher Dec 4 2011 at 16:11

writing из nginx_stub_status? в том смысле, что за мгновения до «горбиков» все лочили друг друга, а потом разом отдали? имхо с натяжкой, writing может скакать по куче других причин, а вот если бы вы привели одновременно latency и cpu usage — можно было бы смотреть предметнее.

SaveTheRbtz Dec 4 2011 at 23:35

Учитывая, что больших файлов у нас не водится, writing очень хорошо коррелирует с тормозами backend'а. Вообще, когда мы разбирались в проблеме мы строили графы на основе php-fpm-slow.log'а — там всё было как на ладони.

egorinsk Dec 4 2011 at 12:22

Идея отличная. Рализация отвратительная, на двойку — для применения этого подхода надо не патчить APC (happy debugging, bitches), а реализовать функционал на уровне приложения. У вас же в приложении есть какой-нибудь MyFramework_Cache, вот туда и вписывайте.

CSharpRU Dec 4 2011 at 13:22

Полностью согласен с оратором выше.

-1

SaveTheRbtz Dec 4 2011 at 13:36

Перечитайте «Disclaimer» и второй абзац «Варианты решения проблемы»

DjOnline Dec 4 2011 at 14:28

Лучшим вариантом решения было бы обновлять данные в кэше в фоне. Например, видим что данные устарели, отдаём клиенту быстро старые данные (мгновенное), и не задерживая посетителя, начинаем в фоне ложить в кэш новые данные (конечно запуская эту процедуру только один раз, продолжая другим посетителям отдавать старые данные до завершения операции обновления).
Вопрос — как это лучше сделать, какие есть варианты?

SaveTheRbtz Dec 4 2011 at 23:11

Может быть научить кеш общаться с какой-нить очередью и при протухании кеша добавлять туда job?

persona Dec 5 2011 at 09:20

Ну так и делать, сам же всё описал. У нас например вот так:
$value = PersistentCache::getInstance(cache_key, time = 60, callback, callback_params)->getValue();
Внутри когда начинает подходить время отдаем старое значение, ставим флаг о начале перегенерации и запускаем её по окончанию генерации страницы.

DjOnline Dec 5 2011 at 11:58

Вот о последней строчке поподробней пожайлуста.
Обязательно для этого использовать php_fpm? Используется какая-нибудь ещё очередь сообщений?

persona Dec 5 2011 at 12:44

Обычный register_shutdown_function(). Кажется, работает везде и всегда.
Ключ регенерации ставится в тот же самый кэш с каким-то небольшим временем жизни.
Т.е. если

Show the best of all time