Технології та Інфраструктура → Redis: in-memory-рішення

Redis: in-memory-рішення

1) Де Redis доречний

• Кеш (read-through/aside, TTL, SWR) і сесії.
• Лічильники та квоти: rate limiting, антифрод, ліміти кампаній.
• Лідерборди/рейтинги (ZSet), рекомендації «топ-N».
• Черги/шини подій (Streams/PubSub), outbox/inbox, ретраї.
• Ідемпотентність (ключі з TTL), de-dup вебхуків.
• Geo (пошук найближчих точок), Bitmap (прапори, DAU).
• Псевдоніми/токени і короткоживучі кеші авторизації.

2) Структури даних і коли їх застосовувати

String: значення/лічильники ('INCRBY'), ідемпотентні ключі.
Hash: агрегати профілів/конфігів, зберігання «легких» об'єктів.
List: прості черги (але без replay/offset-семантики).
Set: унікальні елементи, дедуплікація.
ZSet: сортування по швидкості (лідерборди, TTL-календар - «відкладені» події).
Stream: стійкі черги c споживчими групами,'XREADGROUP '/replay - для вебхуків, CDC, ретраїв.
Geo: 'GEOADD/GEORADIUS'- найближчі точки/мерчантів.
Bitmap/Bitfield: серії прапорів (логіни по днях, DAU/WAU).
HyperLogLog: приблизні унікальні (UU) дешево по пам'яті.
Bloom/Cuckoo (модулі): швидкі перевірки наявності, знижують «MISS» до джерела.

• RedisJSON (JSON документи), RediSearch (індексація/пошук), RedisBloom (ймовірнісні структури), TimeSeries (метрики/агрегації).

3) Ключі, TTL і політики пам'яті

tenant:{t}:domain:{d}:{entity}:{id}:v{schema}    region={R}    currency={C}    lang={L}

Версіонуйте ('vN'), включайте тільки значущі вимірювання (регіон/валюта/мова/тенант).
Ізолюйте простори ключів per-tenant.

• Використовуйте TTL-матрицю (сек/хв/год), додавайте джиттер (± 10-20%) щоб уникати stampede.
• Для гарячих ключів - refresh-ahead і single-flight (один лідер оновлює).

• 'allkeys-lru/lfu'- загальний кеш без TTL-залежності.
• 'volatile-lru/lfu'- тільки ключі з TTL.
• «noeviction» - відмова запису при переповненні (безпечніше для критичних черг/лічильників).
• Підбирати під сценарій і завжди моніторити'evicted _ keys'.

4) Транзакції, пайплайни та скрипти

Пайплайни: знижують RTT, групуйте 10-100 команд.
Транзакції (MULTI/EXEC): не ізолюють читання, але атомарно виконують пакет.
Optimistic locking: 'WATCH key'→ перевірка →'MULTI/EXEC'.
Lua-скрипти: атомарна логіка на стороні сервера (rate limit, locks, composite-операції).

5) Черги і шини: List vs Stream

List +'BRPOP'- просто, але немає consumer groups, offset/replay, слабка стійкість до падінь.
Stream: 'XADD → XREADGROUP → XACK', retry-deadletter (незяті за N хвилин), партіонування по ключу. Рекомендується для вебхуків PSP/KYC, відкладених виплат/повідомлень.

Пріоритетні черги: кілька стрімів за пріоритетами, споживачі «висмоктують» з високого в першу чергу.
Відкладені завдання: ZSet где score=timestamp; періодичний'ZRANGEBYSCORE'≤ now → перенесення в Stream.

6) Висока доступність і масштабування

Реплікація: master→replica (read-scale).
Sentinel: автоматичний failover master'a, виявлення, клієнтські URI.
Redis Cluster: шардування на 16384 слота, горизонтальний scale-out. Ключі, що використовують кілька структур, загорніть в хеш-теги'{ order:123}`.

• Для кешу/сесій - кластер/репліки,'client-side hashing'підтриманий SDK.
• Для черг/стрімів - мінімізуйте крос-слотові операції; партіонуйте за ключами домену.

7) Персистентність: RDB, AOF і бекапи

RDB (знімки): швидше, економніше; ризик втрати останніх секунд/хвилин.
AOF (журнал): менше втрат; режими'everysec/always'. Стиснення AOF і періодична перепакування.
Гібрид: RDB + AOF → швидке відновлення + помірні втрати.
Бекапи: снапшоти і копії AOF в об'єктне сховище; перевіряйте відновлення регулярно.

Для критичних черг/ідемпотентності вибирайте AOF'everysec'+ реплікацію.

8) Безпека та комплаєнс

AUTH/ACL: ролі per-додаток, заборона «небезпечних» команд ('FLUSHALL','KEYS').
TLS на клієнт-сервер і міжвузлових лінках; фіксовані egress-IP.
Сегментація мережі: приватні підмережі, SG/NACL; доступ тільки з потрібних сервісів/неймспейсів.
Секрети не логуйте; PAN/PII в Redis - тільки токени/деривативи.
Команди ключів: уникайте'KEYS'- використовуйте'SCAN'.

9) Спостережуваність і SLO

• Latency (P95/P99), `instantaneous_ops_per_sec`, `connected_clients`.
• Hit ratio, evicted_keys, expired_keys.
• Memory: used, fragmentation ratio, RSS, allocator stats.
• Replication lag, AOF/RDB частоти і розміри, fork time.
• Streams: PEL (pending entries list), delivery latency, retry count.

• Операції Redis P99 ≤ 5-10 мс.
• Evictions ≤ 1 %/год (кеш-простору).
• Stream delivery P99 ≤ 500 мс, retry rate < 2%.

10) FinOps і планування ресурсів

Пам'ять дорога: вимірюйте $/GB-міс RAM vs економія запитів до origin/БД.
Вмикайте компресію значень> 1-2 КБ (дивіться на CPU).
LFU може дати кращий hit при меншому обсязі.
Для зображень/великих блобів - не Redis: використовуйте CDN + об'єктне сховище.

11) Патерни для iGaming/фінтех

11. 1 Rate limiting (ковзне вікно, Lua)

Ідея: 'INCRBY'в ключі вікна + TTL; Lua атомарно перевіряє ліміт і збільшує.

lua
-- KEYS[1]=key ARGV[1]=limit ARGV[2]=ttlSec ARGV[3]=inc local cur = redis. call('INCRBY', KEYS[1], ARGV[3])
if cur == tonumber(ARGV[3]) then redis. call('EXPIRE', KEYS[1], ARGV[2]) end if cur > tonumber(ARGV[1]) then return {0, cur} else return {1, cur} end

11. 2 Ідемпотентність запитів

Ключ'idemp:{request_id}' з TTL 24h, значення - результат/статус. Перед виконанням операції - перевіряємо наявність.

11. 3 Лідерборди

`ZINCRBY leaderboard:game:{g} score user:{u}` → `ZREVRANGE... WITHSCORES`.
Для топ-N по регіону/тенанту - окремі ZSet або префікси.

11. 4 Черга вебхуків PSP

`XADD psp:webhooks...'→ групи споживачів'XGROUP CREATE psp:webhooks g1 $`.
Ретраї «завислих» повідомлень через PEL-сканування ('XPENDING'→'XCLAIM').

11. 5 Відкладені виплати

ZSet `payout:due'( score = epoch) → воркер періодично переносить готові елементи в Stream'payout:exec'з дедуплікацією.

11. 6 Антифрод-лічильники

Комбінація'PFADD'( унікальні) +'INCR'( інтенсивність) + гео/ASN-мітки; тригери для ручної перевірки.

12) Робота з пам'яттю та продуктивністю

Пули з'єднань клієнтів; зменшуйте RTT (keep-alive).
Віддайте перевагу пайплайнам до пачки команд.
Слідкуйте за big keys ('MEMORY USAGE','SCAN') - краще дробити об'єкти.
Hash з малим числом полів економічніше багатьох окремих ключів.
Вмикайте io-threads (read-heavy), якщо профіт підтверджено тестами.
Уникайте частих'FLUSHDB/ALL'в проді; керуйте через префікси і'UNLINK'для безпечного видалення.

13) Мульти-тенант та ізоляція

Окремі кластери/інстанси або logical DB per-tenant (якщо навантаження мале).
Квоти на ключі/пам'ять, роздільні ACL.
Префікси в ключах і метрики по namespace.

14) Locking і узгодженість

SET key val NX PX = ttl - простий mutex.
Redlock: використовуйте акуратно; для розподілених критичних транзакцій краще спиратися на «джерело істини» (БД/ledger) та ідемпотентні операції.
Віддайте перевагу атомарним операціям і Lua замість «довгих» блокувань.

15) Анти-патерни

Зберігання великих блобів/зображень - перевантаження RAM і мереж.
Фінансові інваріанти (баланс) тільки в Redis.
'KEYS'і «сканування світу» в проді.
Відсутність TTL/джиттера - dogpile на закінченні.
Політика «allkeys-» на критичних чергах → втрата даних при тисках.
Змішування черг, кешу і сесій в одному інстансі без квот і пріоритетів.
Lua-скрипти, що працюють за ключами різних слотів в Cluster.

16) Чек-лист впровадження

1. Визначте ролі: кеш/сесії, черги/стріми, лічильники/ліміти - рознесіть по інстансам/кластерам.
2. Виберіть maxmemory-policy під завдання; задайте ліміти та моніторинг evictions.
3. Неймінг ключів, версії схем, TTL-матриця + джиттер; single-flight для топ-ключів.
4. Для черг - Streams (групи, ретраї, DLQ), для відкладених - ZSet + перенесення.
5. HA: реплікація + Sentinel або Redis Cluster; перевірте failover клієнта.
6. Персистентність: RDB/AOF під сценарій; регулярні бекапи і тест відновлення.
7. Безпека: ACL, TLS, приватні мережі, заборона небезпечних команд.
8. Спостережуваність: latency, ops/sec, memory, evictions, replication lag, stream PEL.
9. FinOps: профілі пам'яті, великі ключі, компресія, LFU; уникайте Redis для великих блобів.
10. Документація патернів (rate-limit, ідемпотентність, лідерборди) і тести навантажень.

Підсумок

Redis - це «багатофункціональний швейцарський ніж» швидкості: кеш, черги, лічильники, лідерборди, гео і ймовірнісні структури. Його сила - у правильному виборі структур даних, дисципліні TTL/інвалідації, атомарності операцій, а також у продуманій НА/персистентності та спостережуваності. Використовуйте Redis там, де важливі мілісекунди і високий RPS, при цьому залишаючи критичні інваріанти (гроші, облік) «джерелу істини» - так платформа залишиться і швидкою, і надійною.