zaartix
@zaartix

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

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

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

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

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

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

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

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

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

То есть если не сильно важно на сколько свежие данные получит пользователь, то не заставлять его ждать их обновления, а отдавать те что есть сразу, а потом запускать обновление.
Ответ написан
@armenka29
Программист, бизнесмен
Очереди в редис есть, основной скрипт, когда надо кеш обновить кидает в очередь сообщение.
2й скрипт работает как демон, слушает очередь постоянно. Получив сообщение обновляет
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы