В чем преимущество redis’а в качестве хранилища кэша?
быстрое хранилище в памяти;
несколько серверов redis могут быть объединены в кластер;
несколько web-серверов могут подключаться к одному серверу redis;
можно сбросить кэш на диск, чтобы не потерять его при перезагрузке;
различные модели вытеснения лишнего кэша;
В общем redis послужит отличной заменой memcached. Собственно, исходники bitrix/modules/main/classes/general/cache_memcache.php и послужили болванкой для данных экспериментов. Посмотрел в исходники битрикса, обнаружил, что ничего не мешает и все довольно просто.
Redis
Итак, для начала устанавливаем redis. (если у вас windows, то можно скачать инсталлятор отсюда https://github.com/MSOpenTech/redis/releases) Поскольку сервер будет использоваться для хранения кэша данных, то настроим в конфиге максимальный объем используемой памяти:
maxmemory 100mb
и политику вытеснения из памяти:
maxmemory-policy volatile-ttl
данная политика означает, что при нехватке выделенной памяти для новой записи, будут выброшены записи, время жизни которых наиболее приближено к окончанию.
Если нет возможности установить дополнительные модули, то можно через composer установить https://github.com/nrk/predis. Использование Predis не требует никаких дополнительных модулей, но надо будет изменить несколько строк в примере. Мне показалось, что работа с скомпилированными библиотеками будет быстрее, чем полностью интерпретаторная реализация общения с редисом.
Bitrix
Создаем php файл (отдельный или в составе собственного модуля) где будет размещаться наш класс ‘CPHPCacheRedis’. В файле .settings, в разделе ‘cache’ вместо строки ‘type’ указываем массив:
При кешировании в битриксе используются три уровня:
basedir
initdir
filename
когда мы в первый раз делаем запись в кэш, то создаются 3 записи:
запись с ключом basedir, которая содержит рандомный хэш basedir_version
запись с ключом basedir_version . "|" . init_dir , которая содержит рандомный хэш initdir_version
и собственно наша запись с ключом basedir_version . "|" . initdir_version . "|" filename , содержащая кэшируемые данные
При массовой очистке кэша, например функцией cleanDir или кнопкой очистки кэша из админки, битрикс поступает следующим образом:
очищает запись с ключом basedir_version . "|" . init_dir (в случае с cleanDir)
очищает запись с ключом basedir (в случае с «очистить кэш» из админки)
Таким образом записи типа filename остаются «бесхозными» и продолжают висеть в памяти пока не истечет их время жизни или они не будут вытеснены политикой ограничения размера памяти. Однако redis позволяет получить список ключей по маске, поэтому в моем примере я удаляю все ключи, соответствующие маске удаляемого уровня, а потом уже удаляю саму запись
К сожалению у меня нет задач с огромным количеством кэшей, чтобы замерить сильно ли упадет производительность при очистке. Если есть необходимость использовать классический подход битрикса, то можно оставить только
При переходе на PHP7 обнаружилось «страшное». Под новую версию PHP не оказалось рабочих версий акселераторов. APC стал нерабочим еще с версии 5.5, ... родной opcache не кэширует данные.
Не совсем корректное утверждение и решение этой проблемы - выше.
Всегда считал количество кэшируемых данных в битриксе неоправданно большим (например при работе с каталогом) и хранение такого кэша в ОЗУ - это просто расточительно.
Александр Аваков, все зависит от целей и задач. Все регулируется. Памяти на кэш используется не так много и в сравнении с постоянными запросами к БД - это наименьшее зло
Евгений Микулич, зачастую Гигабайты кэша - следствие неправильной настройки кэширования. Если используется файловый кэш, то зачастую объем создает старый кэш с большим TTL В других бэкендах максимальный объем кэша в памяти регулируется настройками и лишнее чистится автоматом
уже как года полтора использую редиску для кеширования выборок собственных классов. Объем кешированных данных около 1гб, написан свой класс обертка по аналогии с https://habrahabr.ru/post/137536/
есть одна проблема иногда, при интенсивной обработке, теряется соединение с редиской, причем при включенном сохранении кеша проблема проявляется чаще
Дмитрий Свиридов, в конфиге частота сброса на диск выставляется в зависимости от частоты добавления данных. Может нагрузка возросла настолько, что он непрерывно пишет на диск? Попробовать оттюнинговать записи save в конфиге?
Caught exception: "read error on connection" call[1] get(... Caught exception: "read error on connection" call[1] setex(...
вот примеры ошибок которые иногда выскакивают.
причем внешний модуль обвязки построен следующим образом.
вызов сразу отдается редису если возникает исключение, ловим его, логируем, курим usleep(1000), реконектимся к редису, и повторяем запрос (и так до трех попыток) обычно со второй все срастается.
на данный момент вот так $this->timeout=0; .... $this->obj=new Redis; $this->obj->connect($this->ip, $this->port, $this->timeout); $this->setOption(Redis::OPT_READ_TIMEOUT, -1);
в основном ошибки появляются когда работает "консольный" демон php-cli
Крутяк. Давно руки чесались научить битркис работать с редисом. Как раз сел изучать исходники и подумал - может кто-то уже пробовал? И вот, свежая статейка. Спасибо, попробую.
ну свои то решения типа облачного bitrix24 они хотят не на шаредах наверное. так что зря не внедряют redis это почти БД - для всяких быстрых индексов и фасетов самое то.
правда сама архитектура кеширования у них не оптимальная. используется сериализация и десериализация средствами PHP. вместо того чтобы оперировать "нативными сущностями". получать готовые значения (одиночные значения, списки, множества, словари ) по ключу
Виталий Окунев, за взаимодействие с редисом отвечает php-redis extension для php соответствующей версии. В гитхабе https://github.com/phpredis/phpredis пишут, что 5-я версия поддерживается (добавляется возможность кроме сети подключиться через сокет). На практике не пробовал.
подключил redis по вашей статье. Для подключения модуля php_igbinary хостинг перевел php в режим cgi. Php-cgi технология устаревшая. Если не подключать php_igbinary, будет ли все работать?
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».