В чем преимущество 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 позволяет получить список ключей по маске, поэтому в моем примере я удаляю все ключи, соответствующие маске удаляемого уровня, а потом уже удаляю саму запись
К сожалению у меня нет задач с огромным количеством кэшей, чтобы замерить сильно ли упадет производительность при очистке. Если есть необходимость использовать классический подход битрикса, то можно оставить только
ну свои то решения типа облачного bitrix24 они хотят не на шаредах наверное. так что зря не внедряют redis это почти БД - для всяких быстрых индексов и фасетов самое то.
правда сама архитектура кеширования у них не оптимальная. используется сериализация и десериализация средствами PHP. вместо того чтобы оперировать "нативными сущностями". получать готовые значения (одиночные значения, списки, множества, словари ) по ключу
Виталий Окунев, за взаимодействие с редисом отвечает php-redis extension для php соответствующей версии. В гитхабе https://github.com/phpredis/phpredis пишут, что 5-я версия поддерживается (добавляется возможность кроме сети подключиться через сокет). На практике не пробовал.
подключил redis по вашей статье. Для подключения модуля php_igbinary хостинг перевел php в режим cgi. Php-cgi технология устаревшая. Если не подключать php_igbinary, будет ли все работать?
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».