Redis & Caching Vocabulary: 25 Terms Every Backend Developer Needs (англійською)

Вивчіть Redis і словниковий запас кешування — кешування hits/ miss, TTL, правила евакуації, структури даних Redis, pub/ sub, кластеризацію і шаблони кешування з поясненнями для розробників серверів.

Кешування є одним з найефективніших інструментів продуктивності, доступних для розробників, а Redis є найбільш широко використовуваною технологією кешування в виробничих системах. Незалежно від того, чи ви переглядаєте стратегію кешування, зневаджуєте інциденти, пов’ язані з кешуванням, або розробляєте нову функціональність, цей словник допоможе вам ясно і впевнено спілкуватися.


Фундаментальні дослідження

Захоплення і знищення скарбів

** Пошук у кеші ** відбувається, коли запит на дані знаходиться у кеші. ** кеш пропуск ** відбувається, коли це не так — система повинна отримати дані з повільнішого первинного джерела (зазвичай, бази даних).

«Наш кеш-рейтинг становить 92 % — тільки 8 % запитів надходять до бази даних» “Після розгортання, кеш був холодним і кількість попадань впала до нуля. База даних не могла обробляти повне навантаження»

Потепління

** Загрів кешу ** (також відомий як * заповнення кешу *) є процесом активного завантаження даних до кешу до того, як вони стануть потрібні — зазвичай, після розгортання або перезапуску — щоб система не страждала від громового стада помилок у кешу.

«Ми нагріваємо кеш при запуску, попередньо завантажуючи найчастіше доступні сторінки продукту.»

Стадіон «Стадіон»

** Кеш- стампед ** (також називається * громовими стадами *) відбувається, коли багато запитів одночасно пропускають кеш для одного і того ж ключа і всі поспішають відновити його відразу, переповнюючи базу даних. Зазвичай, це відбувається, коли закінчується термін дії популярного кешованого елемента.

«Ключ кешу для домашньої сторінки закінчився в той самий момент, коли ми мали пік трафіку — класичний кеш-штампеді. Ми виправили це з пробабельним раннім закінченням терміну дії»

ТТЛ (Time to Live)

** TTL ** — це час, після якого кешований елемент втрачає чинність і його вилучають з кешу. Вибір правильного TTL балансує актуальність (короткий TTL) з швидкістю і навантаженням бази даних (довгий TTL).

«Встановіть TTL 5 хвилин для профілю користувача — це не обов’язково має бути в реальному часі, і це значно зменшить запити до бази даних» «TTL занадто короткий — він закінчується, перш ніж більшість користувачів зробить другий запит, тому ми ледве отримуємо користь від кешу»

Політика вигнання

** Правила вилучення ** визначають, які елементи Redis вилучає, коли пам’ ять заповнюється. Спільні правила:

  • ** LRU (Least Recently Used) ** — вилучає елемент, який не використовувався протягом найдовшого часу.
  • ** LFU (найменш часто використовувані) ** — вилучає елемент, до якого було найменше доступу за певний час.
  • ** volatile- lru ** — застосовує LRU лише до ключів, що мають встановлений TTL; ніколи не вилучає ключі без TTL.
  • ** allkeys- lru ** — застосовує LRU до всіх ключів.
  • ** noeviction ** — повертає помилку замість виключення. Використовувати лише, якщо ви бажаєте запобігти втрати даних.

«Налаштувати політику висилання на allkeys-lru, щоб Redis міг автоматично звільнити пам’ять під тиском» «Ми вдарили по Redis OOM помилку — політика висилки була noeviction. Перейти до allkeys-lru. “


Структури даних Redis

String

string є найпростішим типом даних Redis — ключом, який відповідає безпечному двійковому значення. Рядки можуть містити текст, числа або послідовний JSON. Максимальний розмір: 512 МБ.

«Зберігати серіалізовану сеансу користувача як рядок Redis з 30-хвилинним TTL.»

Hash

** Хеш ** зберігає карту пар поля- значення під одним ключем — подібно до словника або об’ єкта. Ефективний для представлення об’ єктів, де ви можете бажати оновити окремі поля.

«Зберігати профіль користувача як Redis-геш, щоб ми могли оновити поле lastLogin без перезапису всього об’єкта»

List

** список ** є впорядкованою збіркою рядків. Ви можете натискати і відкидати з обох кінців (LPUSH/ RPUSH, LPOP/ RPOP), що робить цю функцію корисною для черг і стеків.

«Ми використовуємо список Redis як просту чергу роботи — працівники вибирають завдання зліва»

Set

** Набір ** є неупорядкованою збіркою унікальних рядків. Корисно для перевірки членства, міток або відстеження унікальних відвідувачів.

«Зберігати набір можливостей, ввімкнених для кожного користувача в наборі Redis — перевірка членства є O(1).»

Впорядкований набір (ZSet)

** Впорядкований набір ** відображає унікальні елементи у рахунках з рухомою комою і зберігає їх упорядкованими за рахунками. Відмінно підходить для таблиць лідерів, обмеження швидкості і даних часових рядів.

«Ми використовуємо сортований набір для таблиці лідерів — рахунок є загальною кількістю очок користувача, і Redis зберігає їх сортовані автоматично»

Stream

** Потік ** — це журнал повідомлень, який можна лише додавати, подібно до Kafka. Споживачі можуть читати повідомлення в порядку і відстежувати їх положення з групою споживачів.

«Ми перейшли від черги списку Redis до потоку, щоб декілька груп споживачів могли обробляти ті ж події незалежно.»


Публікації / Упоряд

Публікації / Упоряд

Pub/ Sub (опублікувати/ підписатися) надає змогу видавцям надсилати повідомлення на канали з назвами, а підписникам отримувати їх у реальному часі. Redis Pub/Sub є fire-and-forget — повідомлення не зберігаються.

«Ми використовуємо Redis Pub/Sub для відсилання повідомлень у реальному часі до підключених клієнтів WebSocket» «Пам’ятайте, що Pub/Sub повідомлення втрачені, якщо ніхто з підписників не слухає в момент публікації — використовуйте потоки, якщо вам потрібна довговічність»

Скриптування Lua

** Скрипти Lua ** виконуються атомарно на сервері Redis. Вони корисні для складних операцій, які потребують читання і запису декількох ключів без ризику зміни даних іншим клієнтом.

«Ми використовуємо скрипт Lua для атомарної перевірки лічильника обмеження швидкості і збільшення його — без умови гонки»


Надійність і масштаб

Кластер Redis

** Redis Cluster ** — вбудований розв’ язок для шардингу. Дані автоматично розподіляються між декількома вузлами за допомогою геш-слотів. Вона забезпечує як горизонтальну масштабованість, так і високу доступність.

«Ми перейшли на Redis Cluster, тому що один вузол не може зберігати всі наші дані в пам’яті»

Редіс Сентінел

** Redis Sentinel ** забезпечує високу доступність для окремого екземпляра Redis (не кластера). Sentinels моніторять основний вузол і автоматично підвищують репліку, якщо основний вузол не працює.

Ми використовуємо Sentinel з одним основним і двома репліками — Sentinel обробляє автоматичний відключення впродовж декількох секунд

Постійність: RDB і AOF

Redis пропонує два механізми збереження:

  • ** RDB (Redis Database) ** — створює періодичні знімок у певну точку часу. Швидке відновлення, але може призвести до втрати даних з часу останнього зніму.
  • ** AOF (файл, який можна лише додати) ** — записує у журнал кожну команду запису. Більш міцний, але більші файли і повільніше відновлення.

«Ми використовуємо AOF-персистентність — ми можемо дозволити собі додаткові дискові вхідно-вихідні операції, але ми не можемо дозволити собі втратити більше секунди даних»


Шаблони кешування

Лайош Лайош (угор

У шаблоні ** кеш- сторінка ** програма спочатку перевіряє кеш. Якщо не вдається, програма отримує результат з бази даних і записує його до кешу. У кеші містяться лише дані, які було дійсно запрошено.

«Ми використовуємо кеш-а-бід для даних продукції — ми кешуємо тільки те, що користувачі насправді дивляться»

Переписано

У write-through, кожен запис йде одночасно в кеш і базу даних. Кеш завжди збігається з базою даних.

«Запис-проти забезпечує, що кеш ніколи не застаріває, але додає затримку до кожного запису»

Запис (Write-Back)

У ** запис- позаду **, записи спочатку надходять до кешу і асинхронно виводяться до бази даних. Це зменшує затримку запису, але може призвести до втрати даних, якщо кеш не зможе зберегти дані.

«Запис позаду дає нам низьку затримку запису, але ми повинні переконатися, що черга є довговічною, щоб ми не втрачали записів»

Розподілене блокування

** Розподілене блокування ** (часто реалізоване з Redis SET NX EX ) запобігає декільком процесам від виконання критичної секції одночасно на різних серверах.

«Ми використовуємо розподілений замок Redis, щоб забезпечити, що тільки один екземпляр завдання виконується в один момент, навіть коли у нас є декілька працівників»


Як використовувати цю функцію в прикладі

** В архітектурному огляді: **

«Чи слід нам використовувати кеш-а-сайд або запис-про-прохід тут? Прохідний запис гарантує послідовність, але додає затримку до кожного запису»

В ответ на инцидент:

“База даних знищена. Перевірте швидкість влучання кешу Redis — якщо вона впаде, ми можемо отримати кеш-штамп з застарілої ключової фрази»

** В перегляді коду: **

“Цей ключ не має TTL — він ніколи не закінчиться і буде зростати безкінечно. Встановити відповідний TTL.”

** В планах: **

“Таблиця лідерів вимагає сортування результатів. Використовуйте впорядкований набір Redis — це саме те, для чого він розроблений, і він буде набагато швидшим, ніж SQL ORDER BY з мільйоном рядків»

Словник Redis є необхідним для будь- якого розробника сервера, який працює над продуктивністю, можливостями реального часу або розподіленими системами. Знання цих термінів допоможе вам розробити кращі стратегії кешування і безпечно брати участь у обговоренні проектування системи.

Поширені запитання

Про що ця стаття "Redis & Caching Vocabulary: 25 Terms Every Backend Developer Needs (англійською)"?

Вивчіть Redis і словниковий запас кешування — кешування hits/ miss, TTL, правила евакуації, структури даних Redis, pub/ sub, кластеризацію і шаблони кешування з поясненнями для розробників серверів.

Чи безкоштовна ця стаття?

Так. Усі статті на CoderSlingo, включно з цією, доступні безкоштовно без реєстрації.

Скільки часу займає читання "Redis & Caching Vocabulary: 25 Terms Every Backend Developer Needs (англійською)"?

Приблизно 9 min.