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

Question

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

• Magento CE 1.8
• Бэкэнд-сервер и NFS(медиа) на Amazon AWS EC2 по адресу http://admin.example.com/
• База данных на серверах приложений AWS RDS MySQL 2 (масштабируемая до большего количества) в AWS Elastic Beanstalk по адресу http://www.example.com/(route53)
• обычный кеш-сервер (база данных 0), Lesti-FPC(база данных 0) и redis_session (база данных 1) при перетаскивании эластичной боли AWS

Первоначально у меня был Lesti-FPC, настроенный на использование базы данных 2 в кэше Redis. Я думал, что это работает довольно хорошо, насколько я могу судить, пока не понял, что вообще не могу очистить кеш со страницы администратора> Система управления кешем. "Flush Magento Cache", "Flush Cache Storage", "отключить" и "обновить" ничего не сделали. Я мог очистить его, только перезагрузив узел redis или зайдя с помощью redis-cli и используя команды redis.

Затем я попытался настроить Lesti-FPC для использования базы данных 0, как описано выше. Это сработало лучше. Теперь я мог очистить FPC с помощью "Flush Cache Storage", хотя другие опции все еще не работали. В то время я предполагал, что это проблема именно с Lesti-FPC. Но в любом случае использование "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?

Answer 1

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

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

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

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