Налаштування Redis для 1С-Бітрікс

Налаштування Redis для 1С-Бітрікс

На проекті з високою конкурентністю Memcached не справляється з тегованим кешем: інвалідація за тегом потребує сканування всіх ключів, що при 50 000+ ключах у кеші займає сотні мілісекунд і блокує інші операції. Redis вирішує це завдання через нативні структури Set — тег зберігає множину ключів, інвалідація — атомарна операція SMEMBERS + DEL.

Окрім кешу, Redis використовується в 1С-Бітрікс для сесій, черг у бізнес-процесах і pub/sub у коробковій версії Бітрікс24.

Встановлення та базова конфігурація

apt install redis-server php-redis

/etc/redis/redis.conf — ключові параметри для 1С-Бітрікс:

# Мережевий доступ
bind 127.0.0.1
port 6379
protected-mode yes

# Пам'ять
maxmemory 2gb
maxmemory-policy allkeys-lru

# Персистентність (для кешу можна вимкнути)
save ""           # вимикаємо RDB snapshot
appendonly no     # вимикаємо AOF

# Для сесій — вмикаємо персистентність
# save 900 1
# appendonly yes

# Продуктивність
tcp-backlog 511
tcp-keepalive 300
hz 20

# Логування
loglevel notice
logfile /var/log/redis/redis-server.log

maxmemory-policy allkeys-lru — при досягненні ліміту пам'яті витісняємо найменш використовувані ключі. Для кешу це правильна політика. Для сесій використовуйте noeviction — краще отримати помилку, ніж втратити сесію користувача.

Вимкнення персистентності (save "", appendonly no) для Redis, що використовується лише як кеш — немає сенсу писати на диск те, що і так буде інвалідовано.

Підключення до 1С-Бітрікс

Через модуль sprint.migration або напряму в .settings.php:

// /bitrix/.settings.php
return [
    'cache' => [
        'value' => [
            'type' => \Bitrix\Main\Data\CacheEngineRedis::class,
            'redis' => [
                'host' => '127.0.0.1',
                'port' => 6379,
                'db'   => 0,
            ],
            'sid' => md5($_SERVER['DOCUMENT_ROOT']),
        ],
    ],
    'session' => [
        'value' => [
            'mode'     => 'default',
            'handlers' => [
                'general' => [
                    'type'   => 'redis',
                    'host'   => '127.0.0.1',
                    'port'   => 6379,
                    'db'     => 1,  // окрема БД від кешу
                ],
            ],
        ],
    ],
];

Розділяємо кеш (db:0) і сесії (db:1) — різні політики витіснення, роздільний моніторинг.

Redis Sentinel для відмовостійкості

Один сервер Redis — точка відмови. Redis Sentinel забезпечує автоматичний failover:

redis-master (10.0.0.10:6379)
redis-replica (10.0.0.11:6379)
sentinel-1, sentinel-2, sentinel-3 (порт 26379)

sentinel.conf:

sentinel monitor bitrix-master 10.0.0.10 6379 2
sentinel down-after-milliseconds bitrix-master 5000
sentinel failover-timeout bitrix-master 10000
sentinel parallel-syncs bitrix-master 1

Кворум 2 — при недоступності мастера два з трьох сентинелів мають домовитися про failover.

1С-Бітрікс підключається до Sentinel, а не напряму до мастера — потрібна кастомна реалізація класу кешу або використання Predis з підтримкою Sentinel.

Моніторинг

redis-cli info stats | grep -E "keyspace_hits|keyspace_misses|evicted_keys|connected_clients"
redis-cli info memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio"

mem_fragmentation_ratio > 1.5 — сильна фрагментація пам'яті. Виконуємо redis-cli memory purge або перезапускаємо Redis у вікні обслуговування.

evicted_keys зростає — maxmemory занадто малий. Збільшуємо або аналізуємо, що займає пам'ять:

redis-cli --bigkeys

Використання Redis для черг Бітрікс24

У коробковій версії Бітрікс24 Redis використовується для черг push-сповіщень і реального часу:

// Перевіряємо наявність модуля push-server
\Bitrix\Main\Loader::includeModule('pull');
\CPullOptions::SetQueueServerType('redis');
\CPullOptions::SetRedisConfig(['host' => '127.0.0.1', 'port' => 6379]);