Redis Configuration for 1C-Bitrix

Redis Configuration for 1C-Bitrix

On a highly concurrent project, Memcached cannot handle tag-based cache invalidation: invalidating by tag requires scanning all keys, which with 50,000+ keys in cache takes hundreds of milliseconds and blocks other operations. Redis solves this through native Set structures — a tag stores a set of keys, and invalidation is an atomic SMEMBERS + DEL operation.

Beyond caching, Redis is used in 1C-Bitrix for sessions, business process queues, and pub/sub in the Bitrix24 on-premise edition.

Installation and Basic Configuration

apt install redis-server php-redis

/etc/redis/redis.conf — key parameters for 1C-Bitrix:

# Network access
bind 127.0.0.1
port 6379
protected-mode yes

# Memory
maxmemory 2gb
maxmemory-policy allkeys-lru

# Persistence (can be disabled for cache)
save ""           # disable RDB snapshot
appendonly no     # disable AOF

# For sessions — enable persistence
# save 900 1
# appendonly yes

# Performance
tcp-backlog 511
tcp-keepalive 300
hz 20

# Logging
loglevel notice
logfile /var/log/redis/redis-server.log

maxmemory-policy allkeys-lru — when the memory limit is reached, evict the least recently used keys. This is the correct policy for a cache. For sessions, use noeviction — it is better to get an error than to lose a user's session.

Disabling persistence (save "", appendonly no) for Redis used purely as cache — there is no point in writing to disk data that will be invalidated anyway.

Connecting Redis to 1C-Bitrix

Via the sprint.migration module or directly in .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,  // separate DB from cache
                ],
            ],
        ],
    ],
];

Separate cache (db:0) and sessions (db:1) — different eviction policies, independent monitoring.

Redis Sentinel for High Availability

A single Redis server is a point of failure. Redis Sentinel provides automatic failover:

redis-master (10.0.0.10:6379)
redis-replica (10.0.0.11:6379)
sentinel-1, sentinel-2, sentinel-3 (port 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

Quorum 2 — when the master becomes unavailable, two out of three sentinels must agree to initiate failover.

1C-Bitrix connects to Sentinel rather than directly to the master — this requires a custom cache class implementation or using Predis with Sentinel support.

Monitoring

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 — severe memory fragmentation. Run redis-cli memory purge or restart Redis during a maintenance window.

evicted_keys is growing — maxmemory is too small. Increase it or analyze what is consuming memory:

redis-cli --bigkeys

Using Redis for Bitrix24 Queues

In the Bitrix24 on-premise edition, Redis is used for push notification queues and real-time features:

// Check for push-server module
\Bitrix\Main\Loader::includeModule('pull');
\CPullOptions::SetQueueServerType('redis');
\CPullOptions::SetRedisConfig(['host' => '127.0.0.1', 'port' => 6379]);