Комментарии 9
Почему сложно гарантировать, что при изминение админки будет сброшен кешь? В чем сложность?
Необходимо, чтобы кэш гарантированно сбрасывался в случае успешного редактирования кампании. Для этого придется делать что-то вроде распределенной транзакции между Redis'ом и MS-SQL. В принципе можно редактирование кампании сделать так:
Так как и редактирование кампании и загрузка кэша происходит в транзакции с уровнем изоляции Serializable, то загрузка кэша будет ждать завершения редактировании кампании. Однако такой подход добавляет зависимость админки от кэша (кэш не работает — редактировании кампании не работает) и сервисов от админки (пока редактируется кампания — все запросы сервисов ждут).
Альтернативный вариант — по окончании редактирования кампании добавлять в очередь Rabbit сообщение с командой на сброс кэша. Затем в windows-сервисе, где у нас обрабатываются сообщения, будет гарантированно сброшен кэш, но с некоторой задержкой, что в принципе приемлемо. При этом надо еще гарантировать, что команда на сброс кэша будет добавлена в очередь (правда распределенные транзакции между SQL и Rabbit мы уже сделали — об этом в следующей статье напишем).
- считываем кампанию
- сбрасываем кэш (если не получилось, откатываем SQL транзакцию)
- изменяем кампанию и завершаем транзакцию
Так как и редактирование кампании и загрузка кэша происходит в транзакции с уровнем изоляции Serializable, то загрузка кэша будет ждать завершения редактировании кампании. Однако такой подход добавляет зависимость админки от кэша (кэш не работает — редактировании кампании не работает) и сервисов от админки (пока редактируется кампания — все запросы сервисов ждут).
Альтернативный вариант — по окончании редактирования кампании добавлять в очередь Rabbit сообщение с командой на сброс кэша. Затем в windows-сервисе, где у нас обрабатываются сообщения, будет гарантированно сброшен кэш, но с некоторой задержкой, что в принципе приемлемо. При этом надо еще гарантировать, что команда на сброс кэша будет добавлена в очередь (правда распределенные транзакции между SQL и Rabbit мы уже сделали — об этом в следующей статье напишем).
А зачем вы такие вещи как сброс кеша делаете асинхронными (т.е. используете очереди команда, вместо прямого общение сервис ту сервис)? И почему ожидается, что очередь на сброс кеша будет работать с задержкой?
Сброс кэша мы не делали асинхронным. Его можно бы было сделать через очередь, чтобы кэш был сброшен даже в случае падения запроса к Redis (если не удалось сбросить кэш, повторяем пока не получится). В случае использовании очереди будет задержка, но в общем то совсем небольшая — максимум несколько миллисекунд, так что можно было про это и не упоминать, наверное.
Если мы просто дергаем сброс кэша после редактирования кампании, то в случае если запрос на сброс кэша упадет, у нас останется старая версия кампании до тех пор пока кэш не устареет, что не очень приятно. Причем хотелось бы, чтобы период устаревания кэша был побольше (в текущей реализации кэш вообще не устаревает со временем — он обновляется, только если кампания изменилась).
Если мы просто дергаем сброс кэша после редактирования кампании, то в случае если запрос на сброс кэша упадет, у нас останется старая версия кампании до тех пор пока кэш не устареет, что не очень приятно. Причем хотелось бы, чтобы период устаревания кэша был побольше (в текущей реализации кэш вообще не устаревает со временем — он обновляется, только если кампания изменилась).
А от куда взялись опасения, что запрос на сброс кеша может провалиться? На моем опыте не было случаев, чтоб сервисы кеширования, работающие в штатном режиме давали отбой на сброс кеша.
Может упасть timeout, могут быть проблемы с сетью, сервер кэша может не ответить из-за слишком большой нагрузки и т.д. Мы логируем все ошибки и случаи падения запросов к Redis'у имеются. Проблем со сбросом кэша может не быть только при использовании InMemory кэша. Если кэш хранится на другом сервере, полагаться на то, что запрос к нему обработается в 100% случаев, не стоит.
> Если кэш хранится на другом сервере, полагаться на то, что запрос к нему обработается в 100% случаев, не стоит.
Ну, вообще не на что не стоит полагаться на 100%. Но я обычно стараюсь оставить приложение отвественным за бизнес логику, а отвественным за отказоустойчивость сделать сторонние приложения логирования-оповещения. Я предполагаю, что описанные вами ситуации с проблемами с сетью и т.п. — это исключительные ситуации, требующие реакции специалистов. Во первых специалисты устраняют причину проблемы, а во вторых на основание логов принимают ришение по актуализации системы — в данном случае частичного или полного сброса кеша, если есть основания полагать, что по факту поломки он стал не актуален.
Ну, вообще не на что не стоит полагаться на 100%. Но я обычно стараюсь оставить приложение отвественным за бизнес логику, а отвественным за отказоустойчивость сделать сторонние приложения логирования-оповещения. Я предполагаю, что описанные вами ситуации с проблемами с сетью и т.п. — это исключительные ситуации, требующие реакции специалистов. Во первых специалисты устраняют причину проблемы, а во вторых на основание логов принимают ришение по актуализации системы — в данном случае частичного или полного сброса кеша, если есть основания полагать, что по факту поломки он стал не актуален.
+ Я бы использовал ваш алгоритм в отдельном сервисе отвественном за востановление кеша в случае форс-мажоров. Если есть подозрения на неактуальность, не сбрасывать его полностью, а сверить даты и обновить записи в которых даты не совпадают.
Получается сложновато, не хотелось бы столько сложностей добавлять к и так не простой архитектуре кэширования.
У нас есть места, где кэшируются данные для отдельных потребителей. Этот кэш у нас сбрасывается простым вызовом Redis'а, так как даже если сбросить кэш не удастся — он сам устареет через 5 минут и нас это устраивает. В большинстве случаев это наиболее хороший подход к кэшированию.
Можно бы было кэш кампаний также сделать устаревающим раз в 5 минут, но тогда у нас было бы значительно больше перезагрузок кэша по сравнению с кэшированием в памяти процесса.
У нас есть места, где кэшируются данные для отдельных потребителей. Этот кэш у нас сбрасывается простым вызовом Redis'а, так как даже если сбросить кэш не удастся — он сам устареет через 5 минут и нас это устраивает. В большинстве случаев это наиболее хороший подход к кэшированию.
Можно бы было кэш кампаний также сделать устаревающим раз в 5 минут, но тогда у нас было бы значительно больше перезагрузок кэша по сравнению с кэшированием в памяти процесса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Слой кэширования поверх Linq to SQL