Проблемы с очисткой Magento Redis Cache при установке с отдельным внутренним сервером

Моя проблема в том, что я не думаю, что смогу обновить кеш Magento Redis со страницы администратора. Я понимаю, что проблема может исходить из многих источников, но моя интуиция подсказывает мне, что это как-то связано с тем, что серверная часть находится на отдельном сервере. Моя установка magento выглядит следующим образом:

Изначально мой Lesti-FPC был настроен на использование базы данных 2 в кеше Redis. Насколько я мог судить, я думал, что это работает довольно хорошо, пока не понял, что вообще не могу очистить кеш со страницы администратора «Система»> «Управление кешем». «Очистить кэш Magento», «Очистить хранилище кэша», «отключить» и «обновить» ничего не сделали. Я мог только сбросить его, перезагрузив узел redis или войдя в redis-cli и используя команды redis.

Затем я попытался настроить Lesti-FPC для использования базы данных 0, как описано выше. Это работало лучше. Теперь я мог сбросить FPC с помощью «Flush Cache Storage», хотя другие варианты по-прежнему не работали. В то время я предполагал, что это проблема именно с Лешти-ФПК. Но в любом случае, использование «Flush Cache Storage» было достаточно для меня в то время, особенно после того, как я обнаружил, что могу сбросить кеш с помощью кода, используя

Mage::app()->getCacheInstance()->flush();

Недавно я узнал, что проблема может быть не только в Lesti-FPC. Пытаясь решить проблему с Lesti, я попытался отслеживать redis. Я ничего не знаю о Redis или кэшировании, но когда я пытаюсь обновить FPC, я вижу такие команды:

“del” “zc:ti:403_FPC”
“srem” “zc:tags” “403_FPC”

Но этих тегов никогда не существовало. Делает:

keys *FPC*

в Redis дал бы мне

“zc:ti:109_FPC”

но ничего с 403. ТАК, это означает, что мои кеши fpc не становятся недействительными, как это должно быть после изменения продукта / категории и переиндексации. Я обошел это, вручную очищая кеш после изменений и запуская задания cron для очистки и заполнения fpc каждые несколько часов.

Но это вызвало у меня подозрения. Я попытался обновить другие кеши от администратора и обнаружил, что magento всегда пытается удалить и прочитать 403 ключа (некоторые из которых существуют, а некоторые нет), но никогда не 109 ключей (которых много).

Я предполагаю, что ключи 403 относятся к серверу администратора, а ключи 109 относятся к серверам приложений. Сервер администратора, возможно, из-за того, что он находится в другом субдомене, не касается кэшированных данных серверов приложений. Но серверы приложений могут нормально находить свои собственные ключи, о чем свидетельствует тот факт, что FPC работает очень хорошо.

Имеет ли это смысл? Могу ли я что-то сделать, чтобы исправить это? Я что-то неправильно настроил или это ошибка magento?


person The Phil Lee    schedule 22.08.2014    source источник
comment
stackoverflow.com/a/31283821/1902828 может помочь.   -  person chuangbo    schedule 08.07.2015


Ответы (1)


Оказывается, префикс кеша Zend — это первые три символа хэша md5 пути к вашей папке etc.

Мой сервер приложений имеет корень документа в /var/www/html. Полный путь к /var/www/html/app/etc дает идентификатор 403. Серверы приложений, работающие на эластичном beanstalk, имеют свои корни документов в /var/app/current, что выполняется автоматически при развертывании.

Это кажется довольно глупым. Почему бы не хэш адреса базы данных и имени базы данных или что-то в этом роде? Это имело бы больше смысла.

В любом случае, я надеюсь, что это поможет кому-то.

person The Phil Lee    schedule 28.08.2014
comment
У меня такая же установка и такая же проблема. Вы когда-нибудь выясняли, как заставить корректно работать сброс ElastiCache Redis из Magento? - person Tyler V.; 24.10.2014
comment
Вы можете либо переделать свой сервер администратора, чтобы он использовал тот же путь, что и ваши серверы приложений (или наоборот), либо сделать ленивую, unmagento вещь, которую я сделал, и переписать часть, которая приходит с префиксом, чтобы всегда использовать /var/app /Текущий. Я думаю, что это в Cache.php - person The Phil Lee; 25.10.2014