Pull to refresh

Comments 12

>необходимость накатывать миграционные скрипты на работающий сервер

Например?
Ха, миграционный скрипты… Проблема с кэшем возникает гораздо чаще, чем кажется.

Многие программисты, разрабатывающие ПО на заказ, не имеют опыта практической эксплуатации собственного ПО. Сдали проект, получили деньги, забыли. А практика — великая вещь! На практике такие ситуации бывают, какие программисту при разработке и не снились.

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

Попав несколько раз в подобные ситуации я стал использовать кэширование крайне, крайне осторожно.
Немного промахнулся. Ответил Вам ниже
Ну, например, возьмем простой случай — у Вас в приложении для новой сущности проставляется флаг DRAFT. А заказчик хочет изменить DRAFT на NEW (не только labels но и внутри кода).
Тогда делаем update и сбрасываем кеш.
У сущности переименовывается поле с draft на new и еще код изменяется? Так тут точно перезагрузка сервера нужна, а если она не приемлема, то делается два сервера с одним балансировщиком и эти два сервера по очереди перезагружаются: так поступают все сайты, которые должны работать 24x7. Никак не могу понять зачем что-то с кешем делать, бизнес-логике должно быть без разницы: есть или нет кеша, она должна в обоих случаях работать одинаково.
Ну ок, код пока трогать не будем, допустим просто выполнили

update plan set status = 'new' where status = 'draft'

объекты в кеше при этом остались со значениями draft
Такие запросы можно из админки сайта выполнять через сессию, тогда кеш, если он есть, сам обновится. Эти миграционные скрипты какие-то особенные, что их надо через sql проводить? Так sql-запросы можно и через сессию проводить тоже.
Ну так я как раз и описал в статье возможные варианты. Каждый выбирает то, что ему больше всего подходит.
Для сброса кеша есть решения, которые я описал в начале статьи, делается это за час максимум. Потом можно использовать во всех проектах.
По поводу удаления данных — в своих проектах я всегда использую флаг — deleted. Реально из базы не удаляю. Как раз для решения таких проблем как Вы описали.
Ну в общем-то мне надо было чётче сказать: тема, поднятая в статье, на самом деле весьма актуальна.

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

А вообще в плане кэширования мне нравится подход, реализованный в iBatis. Там можно гибко настроить время жизни данных в кэше. Для справочников сделать побольше, для оперативных данных — поменьше. В результате сторонние изменения сервер подхватывает достаточно быстро, и в пике нагрузке даёт хорошую производительность.

А из базы я тоже ничего не удаляю, потому восстановление сводится к операции типа «update orders set deleted = null where id = ?». Главное, чтобы сервер в курсе был )
По поводу iBatis — в EHCache такая же гибкая настройка с помощью регионов. Нужен кеш для статики — пожалуйста, нужен кеш для одного типа объектов — пожалуйста. Все гибко. Статика, кстати, у меня не сбрасывается.
Хорошо описали проблемы…
Думал внедрить в проект, сейчас уже думаю «А надо?»
Спасибо
Sign up to leave a comment.

Articles