Redis + PostgreSQL: оптимальная стратегия кэширования для БилингПро

Инструменты и условия:

• sysbench — для PostgreSQL и MySQL (point-select workload)
• memtier_benchmark — для Redis, Valkey и Memcached
• redis-benchmark — дополнительно для Redis
• Данные: 10M ключей × 256 байт = ~2.5 ГБ данных, полностью в RAM
• Диск не участвует (appendonly off, save "")

# Тест Redis с 8 io-threads
redis-benchmark -h 127.0.0.1 -p 6379 -c 256 -n 10000000 \
  -t get -d 256 --threads 8

# Тест PostgreSQL (sysbench point-select)
sysbench oltp_point_select \
  --db-driver=pgsql \
  --pgsql-host=127.0.0.1 \
  --pgsql-port=5432 \
  --pgsql-db=bench \
  --table-size=10000000 \
  --tables=1 \
  --threads=64 \
  --time=300 \
  run

# Тест Memcached
memtier_benchmark -s 127.0.0.1 -p 11211 \
  --protocol=memcache_binary \
  --data-size=256 --key-maximum=10000000 \
  --threads=8 --clients=32 --requests=1000000 \
  --ratio=0:1

Результаты на одном сервере (Xeon Gold 6312U, 128 ГБ RAM):

Ключевое открытие: оптимизированный PostgreSQL на чистом point-select workload показывал ~1M RPS — сопоставимо с Valkey и значительно больше, чем Redis. Но это лишь часть картины.

Чистый ReadOnly point-select — синтетика, не отражающая реальность. Мы повторили тесты с профилем нагрузки клиента (70/20/10):

При смешанной нагрузке PostgreSQL деградировал на 82%, Redis — лишь на 25%. Кэш-слой стал необходимостью, а не опцией.

Для операций с балансами, транзакциями и расчётами мы сознательно не использовали кэш. Причина — strong consistency requirement. Любое расхождение баланса в кэше и БД для биллинговой системы недопустимо.

Вместо кэша мы оптимизировали PostgreSQL:

# postgresql.conf — оптимизация для point-select
shared_buffers = 32GB              # 25% RAM
effective_cache_size = 96GB        # 75% RAM
work_mem = 256MB
maintenance_work_mem = 2GB

# Connection pooling (pgbouncer)
[pgbouncer]
pool_mode = transaction
default_pool_size = 100
max_client_conn = 5000
server_check_query = SELECT 1

# Партиционирование таблицы транзакций по месяцам
CREATE TABLE transactions (
    id BIGSERIAL,
    account_id BIGINT NOT NULL,
    amount DECIMAL(15,2) NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
) PARTITION BY RANGE (created_at);

CREATE TABLE transactions_2026_01
    PARTITION OF transactions
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');
-- и т.д. для каждого месяца

Для тарифных планов, каталогов услуг и конфигураций мы внедрили паттерн cache-aside:

# Конфигурация Redis для кэш-слоя
# redis.conf
bind 0.0.0.0
port 6379
protected-mode yes
requirepass ${REDIS_PASSWORD}

# Отключение персистентности (чистый кэш)
appendonly no
save ""

# Многопоточный I/O
io-threads 8
io-threads-do-reads yes

# Политика вытеснения
maxmemory 16gb
maxmemory-policy allkeys-lfu

# Оптимизация для кэш-сценария
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes

Пример реализации cache-aside на стороне приложения (Python):

import redis
import json
import psycopg2
from functools import wraps

redis_client = redis.Redis(
    host='redis-cache.internal',
    port=6379,
    password=os.environ['REDIS_PASSWORD'],
    decode_responses=True,
    socket_connect_timeout=2,
    socket_timeout=1,
    retry_on_timeout=True
)

def cached(ttl=120, key_prefix=''):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            cache_key = f"{key_prefix}:{func.__name__}:{hash(str(args)+str(kwargs))}"
            
            # 1. Пробуем получить из кэша
            try:
                cached_value = redis_client.get(cache_key)
                if cached_value:
                    return json.loads(cached_value)
            except redis.RedisError:
                # Redis недоступен — идём напрямую в БД
                pass
            
            # 2. Cache miss — запрос к PostgreSQL
            result = func(*args, **kwargs)
            
            # 3. Записываем в кэш
            try:
                redis_client.setex(
                    cache_key, 
                    ttl, 
                    json.dumps(result, default=str)
                )
            except redis.RedisError:
                pass  # Не ломаем основной flow при проблемах с кэшом
            
            return result
        return wrapper
    return decorator

@cached(ttl=300, key_prefix='tariff')
def get_tariff_plan(tariff_id: int) -> dict:
    with get_db_connection() as conn:
        with conn.cursor() as cur:
            cur.execute(
                "SELECT * FROM tariff_plans WHERE id = %s", 
                (tariff_id,)
            )
            return dict(cur.fetchone())

Каждый ключ имеет TTL от 60 до 300 секунд в зависимости от частоты изменений данных:

• Тарифные планы: TTL 300 сек (меняются раз в месяц)
• Списки услуг: TTL 120 сек
• Конфигурации: TTL 60 сек

Для немедленной инвалидации при изменении данных мы использовали PostgreSQL LISTEN/NOTIFY:

-- Триггер на таблице тарифов
CREATE OR REPLACE FUNCTION notify_tariff_change()
RETURNS TRIGGER AS $$
BEGIN
    PERFORM pg_notify(
        'cache_invalidate',
        json_build_object(
            'table', TG_TABLE_NAME,
            'operation', TG_OP,
            'id', COALESCE(NEW.id, OLD.id)
        )::text
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER tariff_change_trigger
    AFTER INSERT OR UPDATE OR DELETE ON tariff_plans
    FOR EACH ROW EXECUTE FUNCTION notify_tariff_change();

# Python-listener для инвалидации Redis
import select

def cache_invalidation_listener():
    conn = psycopg2.connect(DSN)
    conn.set_isolation_level(
        psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT
    )
    cur = conn.cursor()
    cur.execute("LISTEN cache_invalidate;")
    
    while True:
        if select.select([conn], [], [], 5) != ([], [], []):
            conn.poll()
            while conn.notifies:
                notify = conn.notifies.pop(0)
                payload = json.loads(notify.payload)
                pattern = f"{payload['table']}:*:{payload['id']}*"
                
                # Удаляем все ключи, связанные с изменённой записью
                for key in redis_client.scan_iter(match=pattern):
                    redis_client.delete(key)

При истечении TTL популярного ключа десятки инстансов одновременно обращаются к БД. Мы реализовали паттерн «probabilistic early expiration»:

# Вероятностное раннее обновление кэша
import random
import time

def get_with_early_refresh(key, ttl, fetch_func):
    value = redis_client.get(key)
    remaining_ttl = redis_client.ttl(key)
    
    if value and remaining_ttl > 0:
        # С вероятностью, растущей к концу TTL,
        # обновляем кэш фоновым запросом
        refresh_probability = max(0, 1 - (remaining_ttl / ttl))
        if random.random() < refresh_probability * 0.1:
            # Фоновое обновление через Celery task
            refresh_cache_task.delay(key, ttl)
        return json.loads(value)
    
    # Cache miss — обновляем синхронно
    # Используем Redis SETNX для lock
    lock_key = f"lock:{key}"
    if redis_client.set(lock_key, 1, nx=True, ex=5):
        result = fetch_func()
        redis_client.setex(key, ttl, json.dumps(result, default=str))
        redis_client.delete(lock_key)
        return result
    
    # Другой инстанс уже обновляет — ждём
    time.sleep(0.1)
    return get_with_early_refresh(key, ttl, fetch_func)