Използването на кеш Redis значително подобрява производителността и ефективността на приложенията, особено при заявки към данни. Но в същото време носи и някои проблеми. Сред тях най-важният проблем е последователността на данните, която е строго неразрешима. Ако е необходима консистентност на данните, кеширането не може да се използва.
Други типични проблеми са проникване в кеша, лавина на кеша и пробив на кеша. В момента има и по-популярни решения в индустрията. Тази статия не цели да реши тези три проблема по-перфектно, нито да подкопае популярните решения в индустрията. Вместо това ще демонстрираме тези три проблемни явления от действителната операция на кода. Причината за това е, че е трудно да имаш много ярка концепция в главата си само като погледнеш академичното обяснение на тези проблеми, а с реални демонстрации на код можеш да задълбочиш разбирането и разбирането си за тях.
Проникване в кеша
Проникването в кеша се отнася до запитване на данни, които не съществуват в база данни. Ако ключът не съществува или ключът е изтекъл, базата данни се заявява и заявените обекти се поставят в кеша. Ако обектът за заявка в базата данни е празен, той не се кешира.
Поток на код
- параметърът предава първичния ключ ID на обекта
- Вземи обекта от кеша според ключа
- Ако обектът не е празен, той се връща директно
- Ако обектът е празен, изпълнете заявка към база данни
- Ако обектът, търсен от базата данни, не е празен, поставете го в кеша (задайте времето за изтичане). Представете си тази ситуация – какво би станало, ако параметърът, който е предаден, е -1? Това -1 е обект, който не трябва да съществува. Базата данни ще бъде заявявана всеки път, всяка заявка ще бъде празна и няма да бъде кеширана всеки път. Ако има злонамерена атака, тази уязвимост може да бъде използвана, за да се окаже натиск върху базата данни или дори да се претовари. Дори и да се използва UUID, лесно е да се намери несъществуващ КЛЮЧ и да се атакува.
В моята работа използвам метода за кеширане на null стойности, тоест стъпка 5 в [кодовия процес], ако обектът, търсен от базата данни, е празен, той също се поставя в кеша, но зададеното време за изтичане на кеша е кратко, например да се зададе на 60 секунди.
Кеш лавина
Кеш лавина се отнася до изтичането на кеш набора за определен период от време.
Една от причините за лавината е, например, когато пишех тази статия, че скоро ще е нула часа на дванадесетия ден и скоро ще настъпи вълна от бързи покупки. Тогава в един часа през нощта запасът на тази партида стоки ще изтече. Заявката за достъп до тази партида стоки пада върху базата данни, а за базата данни ще има периодични пикове на налягането.
Когато Сяобиан прави проекти за електронна търговия, той обикновено възприема различни категории стоки и съхранява различни цикли. Стоки в същата категория, плюс случаен фактор. По този начин времето за изтичане на кеша може да се разпръсне колкото е възможно повече, а времето за кеширане на продуктите в популярни категории е по-дълго, а времето за кеширане на продукти в непопулярни категории е по-кратко, което също може да спести ресурсите на кеширащата услуга.
Всъщност, централизираното изтичане не е много фатално, а по-фаталната лавина на кеша е, че възел от кеш сървъра се прекъсва или изключва. Тъй като естествената кеш лавина трябва да бъде създадена в определен период от време, базата данни може да издържи натиска, а в този момент и базата данни също може да го понесе. Това е нищо повече от периодичен натиск върху базата данни. Прекъсването на кеш сервисния възел причинява непредсказуемо напрежение върху сървъра на базата данни и вероятно ще претовари базата данни мигновено.
Разбивка на кеша
Разбивката на кеша се отнася до ключ, който е много горещ, постоянно носи голяма паралелност, голямата паралелност се концентрира върху достъпа до тази точка; когато този ключ се повреди, непрекъснатата голяма паралелност пробива кеша и директно иска базата данни, подобно на пробиване на дупка в бариера.
Когато Сяобиан правеше проекти за електронна търговия, той направи този продукт "хит".
Всъщност, в повечето случаи този вид експлозия е трудно да се окаже огромен натиск върху сървъра на базата данни. Малко компании са достигнали това ниво. Затова прагматичният редактор е подготвил за основните продукти рано, така че кешът никога да не изтече. Дори ако някои продукти се ферментират до удари, те могат да бъдат настроени като никога да не изтичат.
Основният път е прост, а mutex ключът за взаимно отхвърляне на ключ почти не се използва.
|
Публикувано в 19.11.2019 г. 9:55:04 ч.
|
|
|
|
