Використання кешу Redis значно підвищує продуктивність і ефективність додатків, особливо для запитів до даних. Але водночас це приносить і певні проблеми. Серед них найважливішою проблемою є узгодженість даних, яка є строго нерозв'язною. Якщо потрібна узгодженість даних, кешування не можна використовувати.
Інші типові проблеми — проникнення кешу, лавина кешу та розпад кешу. Наразі в індустрії також є більш популярні рішення. Ця стаття не має на меті краще розв'язати ці три проблеми і не підриває популярні рішення в галузі. Натомість ми продемонструємо ці три проблемні явища з фактичної операції коду. Причина цього полягає в тому, що важко мати дуже яскраве уявлення в голові, просто дивлячись на академічне пояснення цих задач, а за допомогою реальних демонстрацій коду ви можете поглибити своє розуміння і розуміння цих задач.
Проникнення кешу
Проникнення кешу означає запит даних, які не існують у базі даних. Якщо ключ не існує або він закінчився, база даних запитується, і запитувані об'єкти поміщаються в кеш. Якщо об'єкт запиту до бази даних є порожнім, він не кешується.
Потік коду
- параметр передає первинний ідентифікатор ключа об'єкта
- Отримайте об'єкт із кешу на основі ключа
- Якщо об'єкт не порожній, він повертається безпосередньо
- Якщо об'єкт порожній, виконайте запит до бази даних
- Якщо об'єкт, запитаний із бази даних, не є порожнім, помістіть його в кеш (встановіть час закінчення). Уявіть собі таку ситуацію, що станеться, якщо переданий параметр буде -1? Це -1 — об'єкт, який не повинен існувати. База даних буде запитуватися щоразу, і кожен запит буде порожнім, і не буде кешуватися щоразу. Якщо відбувається шкідлива атака, цю вразливість можна використати, щоб створити тиск на базу даних або навіть перевантажити її. Навіть якщо використовується UUID, легко знайти неіснуючий КЛЮЧ і атакувати.
У своїй роботі я використовую метод кешування нульових значень, тобто крок 5 у процесі [коду], якщо об'єкт, запитаний із бази даних, є порожнім, його також кладуть у кеш, але час закінчення встановленого кешу короткий, наприклад, встановлений на 60 секунд.
Лавина кешу
Cache avalanche означає закінчення терміну дії кеш-набору протягом певного періоду часу.
Однією з причин лавини, наприклад, коли ви писали цю статтю, було те, що незабаром буде нульова година дванадцятого дня, і незабаром почнеться хвиля поспіху покупок. Потім о першій годині ночі схованка цієї партії товарів закінчиться. Запит до доступу до цієї партії товарів припадає на базу даних, і для бази даних періодично спостерігаються піки тиску.
Коли Сяобян займається проєктами електронної комерції, він зазвичай використовує різні категорії товарів і зберігає різні цикли. Товари з тієї ж категорії, плюс випадковий фактор. Таким чином, термін придатності кешу можна максимально розподілити, а час кешування продуктів у популярних категоріях довший і коротший — у непопулярних категоріях, що також може заощадити ресурси кешу.
Насправді, централізоване закінчення не є фатальним, і більш фатальна лавина кешу полягає в тому, що вузол кеш-сервера виходить з ладу або відключається. Оскільки природно виникаюча кеш-лавина має бути створена за певний проміжок часу, тоді база даних витримує тиск, і в цей момент база даних також може витримати тиск. Це не більше ніж періодичний тиск на базу даних. Простій вузла кеш-сервісу створює непередбачуваний тиск на сервер бази даних і, ймовірно, миттєво перевантажить базу даних.
Розподіл кешу
Розбій кешу означає ключ, який дуже гарячий, постійно несе велику паралельність; великі конкурентності зосереджені на доступі до цієї точки; коли цей ключ не спрацьовує, безперервна велика конкурентність проривається крізь кеш і безпосередньо запитує базу даних, подібно до свердління отвору в бар'єрі.
Коли Сяобян займався проєктами в сфері електронної комерції, він зробив цей продукт «хітом».
Насправді, у більшості випадків такий вибух важко покласти потужний тиск на сервер бази даних. Мало компаній досягли такого рівня. Тому прагматичний редактор заздалегідь підготувався до основних продуктів, щоб кеш ніколи не закінчився. Навіть якщо деякі продукти ферментуються до хітів, їх можна визнати такими, що ніколи не закінчуються терміном придатності.
Основний шлях простий, і mutex-ключ для взаємного відхилення майже не використовується.
|
Опубліковано 19.11.2019 09:55:04
|
|
|
|
