Redis менен кэштөө
Кечигүүнү азайтуу жана базаны коргоо үчүн ысык маалыматтарды эстутумдан бериңиз
GET жана SET чакырууда эмес - эмнени кэштөө, канча убакытка жана качан аны ыргытуу керек экенин чечүүдө.
- Express'те cache-aside (жалкоо жүктөө) үлгүсүн туура ишке ашыруу;
- акылга сыярлык TTL тандоо жана мөөнөттүн бүтүшү эмнени кепилдейт, эмнени жок экенин түшүндүрүү;
- сессияларды Redis'те сактоо жана эмне үчүн бул процесстин эстутумунан жакшы экенин билүү;
- жазууда инвалидациялоо жана эскирген маалымат менен кэш штурму тузактарынан качуу;
- компромисстер жөнүндө ой жүгүртүү: ырааттуулук, эстутум жана кэштөөнүн эки кыйын маселеси.
1. Эмне үчүн кэштөө керек?
Сиздин базага же тышкы API'ге жеткен ар бир суроо баасын төлөйт: тармактык цикл, суроону пландоо, дисктин же тармактын кечигүүсү жана дал ошондой ишти жасаган башка бардык суроолор менен атаандаштык. Эгерде жүз колдонуучу бир эле товар барагын ачса, сиз бирдей байттарды алуу үчүн ошол эле кымбат суроону жүз жолу аткарасыз. Кэш жоопту бир жолу эсептеп, аны эстутумда сактап, ага ишенсе боло турганча көчүрмөсүн таратат.
Салыштыруу. Жүктөлгөн ашканаңы элестетиңиз. Маалымат базасы - терездеги чоң муздаткыч: чоң, аброюлуу, бирок ага жетүү жай. Кэш - плитанын жанындагы кичинекей даярдоо столу, азыр колдонуп жаткан ингредиенттериңиз менен. Сиз ар бир заказ үчүн муздаткычка барбайсыз - иштеп жаткан топтомду кол алдында кармап, түгөнгөндө гана толтурасыз. Redis - ошол даярдоо столу: тез, жакын жана атайын кичинекей.
Эки сан ынандырат. Негизги ачкыч боюнча SQL окуусу тармак жана байланыш пулу менен 5-40 мс алышы мүмкүн; ошол эле тармак аркылуу Redis'тен GET адатта 0,2-1 мс. Андан да маанилүүсү, кэш жүктү сиңирет: база агым ордуна ичке жаңылыш агымын гана көрөт, ошондуктан трафик секирүүсүндө да сак-салама калат.
Дароо эскертүү: кэш - чындыктын экинчи көчүрмөсү, ал эми экинчи көчүрмөлөр түп нускадан четтейт. Кэштөөдөгү бардык кыйынчылык ушул бир фактыдан чыгат. Айтылгандай, информатикада эки эле кыйын маселе бар: кэшти инвалидациялоо жана ат коюу.