PHP7. Двухуровневое кеширование + форк?

Question

[zaartix]

Думаю как сделать не тормозное обновление кеша. Сейчас есть 2 уровня кеширования: redis + filecache. Когда redis кеш протухает я инициирую обновление кеша, но перед этим в редис записываю значение из второго уровня кеша для того, чтоб на время подсчета нового значения не генерировались новые запросы к протухшему кешу.

Получается, что только одна сессия будет тормозить во время обновления кеша, а не все. Собственно теперь вопрос. Как бы еще и на эту сессию устранить тормоза? Идея в том, что можно было бы в этой сессии тоже возвращать значение из второго уровня кеша, а процесс обновления значения как-то форкнуть, чтоб он не влиял на текущую сессию и по-завершению работы просто записал бы актуальное значение в кеш. В PHP7 вроде были какие-то инструменты для подобных целей?

Answer 1

[rPman]

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

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

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

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

В некоторых случаях скорость может подняться тысячекратно.

Классический же подход позволяет 'из коробки' использовать многопоточность и даже кластерную реализацию чуть ли не на администраторском уровне.

upd. исправил в ответе redis на react (глупо попутал термины)

Answer 2

[Алексей Арх]

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

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

Comments

[zaartix]

так в этом и вопрос. как реализовать 3 пункт, когда пользователю отдаются устаревшие данные и при этом инициировать обновление кеша. Вопрос в том, позволяет ли пхп7 форкнуть кусок кода, который бы выполнился асинхронно.

$cache = $this->cacheRedis->get($key);
if (!$cache) {
$cache = $this->cacheFile->get($key);
$this->cacheRedis->set($key,$cache,$time);
// дальше в идеале разделить выполнение на 2 потока
// поток 1 продолжает работу со значением $cache из файлового

// поток 2
function(){
// тяжелый запрос к базе и его обработка для записи в кеш
$this->cacheRedis->set($key,$cache,$time);
$this->cacheFile->set($key,$cache,$time);
}
}

[Алексей Арх]

zaartix, ну у нас такое делается на фронте на lua. На пыхе можно попробовать с помощью register_shutdown_function, но я бы сделал через демона.

[zaartix]

Алексей Арх, Демон - видимо это менеджер вроде Gearman ?

[Алексей Арх]

zaartix, нет, это отдельный скрипт, который в бесконечном цикле крутится.
Он будет проверять, есть ли задачи на обновление кэша и выполнять их. (обработчик очереди)
Для реализации очереди можно использовать rabbitmq или другой брокер.
Но у него нету уникальности, то есть можно понаставить в очередь одних и тех же задач. Тут лучше наверное редис использовать.

То есть твоё приложение будет получать данные только когда такого кэша нет физически. (пункт 1)
А когда надо будет обновить кэш, твоё приложение только поставит задачу, например в том же редисе, что нужно обновить кэш для такого то материала.
Демон, который крутится в бесконечном цикле, постоянно мониторит этот список с задачами, если что то есть, он выполняет задачу и удаляет её из редиса.

[Алексей Арх]

zaartix, получится у тебя данные будут обновляется не каждым запросом от пользователя, а по очереди, пока обработчик не разгребёт всё.
Нужно разгребать быстрее - запускаешь больше демонов.

Answer 3

[Константин]

Очереди в редис есть, основной скрипт, когда надо кеш обновить кидает в очередь сообщение.
2й скрипт работает как демон, слушает очередь постоянно. Получив сообщение обновляет