Redis kešatmiņas izmantošana ievērojami uzlabo lietojumprogrammu veiktspēju un efektivitāti, īpaši datu vaicāšanai. Bet tajā pašā laikā tas rada arī dažas problēmas. Starp tiem vissvarīgākā problēma ir datu konsekvence, kas ir stingri neatrisināma. Ja ir nepieciešama datu konsekvence, kešatmiņu nevar izmantot.
Citas tipiskas problēmas ir kešatmiņas iekļūšana, kešatmiņas lavīna un kešatmiņas sadalījums. Šobrīd nozarē ir arī populārāki risinājumi. Šis raksts nav paredzēts, lai perfektāk atrisinātu šīs trīs problēmas, kā arī tas negrauj populāros risinājumus nozarē. Tā vietā mēs demonstrēsim šīs trīs problēmas parādības no faktiskās koda darbības. Iemesls tam ir tas, ka ir grūti iegūt ļoti spilgtu jēdzienu galvā, tikai aplūkojot šo problēmu akadēmisko skaidrojumu, un ar faktiskām koda demonstrācijām jūs varat padziļināt savu izpratni un izpratni par šīm problēmām.
Kešatmiņas iekļūšana
Kešatmiņas iekļūšana attiecas uz datu vaicāšanu, kas nepastāv datu bāzē. Ja atslēgas nav vai atslēgas derīguma termiņš ir beidzies, datu bāzē tiek vaicāts un vaicātie objekti tiek ievietoti kešatmiņā. Ja datu bāzes vaicājuma objekts ir tukšs, tas netiek saglabāts kešatmiņā.
Koda plūsma
- nodot objekta primārās atslēgas ID
- Iegūstiet objektu no kešatmiņas, pamatojoties uz atslēgu
- Ja objekts nav tukšs, tas atgriežas tieši
- Ja objekts ir tukšs, veiciet datu bāzes vaicājumu
- Ja objekts, kas tiek vaicāts no datu bāzes, nav tukšs, ievietojiet to kešatmiņā (iestatiet derīguma termiņu) Iedomājieties šo situāciju, kas notiktu, ja nodotais parametrs būtu -1? Šis -1 ir objekts, kas nedrīkst pastāvēt. Datu bāze tiks vaicāta katru reizi, un katrs vaicājums būs tukšs, un tas netiks saglabāts kešatmiņā katru reizi. Ja ir ļaunprātīgs uzbrukums, šo ievainojamību var izmantot, lai izdarītu spiedienu uz datu bāzi vai pat to pārslogotu. Pat ja tiek izmantots UUID, ir viegli atrast neeksistējošu KEY un uzbrukt.
Savā darbā es izmantošu nulles vērtību kešatmiņas metodi, tas ir, 5. soli [koda procesā], ja objekts, kas vaicāts no datu bāzes, ir tukšs, tas tiek ievietots arī kešatmiņā, bet iestatītais kešatmiņas derīguma termiņš ir īss, piemēram, iestatot to uz 60 sekundēm.
Kešatmiņas lavīna
Kešatmiņas lavīna attiecas uz kešatmiņas iestatīšanas derīguma termiņu noteiktā laika periodā.
Viens no lavīnas iemesliem, piemēram, rakstot šo rakstu, divpadsmitajā dienā drīz būs pulksten nulle, un drīz būs steigas pirkšanas vilnis. Tad pulksten vienā no rīta beigsies šīs preču partijas kešatmiņa. Šīs preču partijas piekļuves vaicājums ietilpst datu bāzē, un datu bāzei būs periodiski spiediena maksimumi.
Kad Xiaobian veic e-komercijas projektus, viņš parasti pieņem dažādas preču kategorijas un kešatmiņā dažādus ciklus. Tās pašas kategorijas preces, kā arī nejaušs koeficients. Tādā veidā kešatmiņas derīguma termiņu var izkliedēt, cik vien iespējams, un populāru kategoriju produktu kešatmiņas laiks ir ilgāks, un nepopulāru kategoriju produktu kešatmiņas laiks ir īsāks, kas var arī ietaupīt kešatmiņas pakalpojuma resursus.
Faktiski centralizēts derīguma termiņš nav ļoti letāls, un letālāka kešatmiņas lavīna ir tā, ka kešatmiņas servera mezgls nokrīt vai atvienojas. Tā kā kešatmiņas lavīna, kas dabiski rodas, ir jāizveido noteiktā laika periodā, tad datu bāze var izturēt spiedienu, un šajā laikā datu bāze var izturēt arī spiedienu. Tas nav nekas cits kā periodisks spiediens uz datu bāzi. Kešatmiņas pakalpojuma mezgla dīkstāve rada neparedzamu spiedienu uz datu bāzes serveri, un, visticamāk, tas vienā mirklī pārslogos datu bāzi.
Kešatmiņas sadalījums
Kešatmiņas sadalījums attiecas uz atslēgu, kas ir ļoti karsta, pastāvīgi pārvadā lielu vienlaicīgumu, liela vienlaicīga koncentrējas uz piekļuvi šim punktam, kad šī atslēga neizdodas, nepārtraukta liela vienlaicīga izlaužas caur kešatmiņu un tieši pieprasa datu bāzi, tāpat kā urbjot caurumu barjerā.
Kad Xiaobian veica e-komercijas projektus, viņš padarīja šo produktu par "hit".
Patiesībā vairumā gadījumu šāda veida sprādzienu ir grūti izdarīt spiedienu uz datu bāzes serveri. Ir maz uzņēmumu, kas ir sasnieguši šo līmeni. Tāpēc pragmatiskais redaktors ir sagatavojies galvenajiem produktiem agri, lai kešatmiņa nekad nebeigtos. Pat ja daži produkti fermentējas trāpījumos, tos var iestatīt kā tādus, kas nekad nebeidzas.
Galvenais ceļš ir vienkāršs, un mutex atslēgas savstarpējā noraidīšanas slēdzene patiešām netiek izmantota.
|
Publicēts 19.11.2019 09:55:04
|
|
|
|
