zaartix
@zaartix

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

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

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

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

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

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

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

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

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

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

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

Войти через центр авторизации
Похожие вопросы
от 150 000 до 250 000 ₽
Depcon Екатеринбург
от 100 000 до 170 000 ₽
ManyChat Москва
от 150 000 ₽
19 окт. 2021, в 19:13
15000 руб./за проект
19 окт. 2021, в 19:02
300 руб./за проект
19 окт. 2021, в 18:45
5000 руб./за проект