【Forord】
Når dataene når et vist niveau, bliver databasen flaskehalsen i hele systemet, og optimeringsstrategien anvendes generelt som læse- og skriveadskillelse, og databasen realiserer læse- og skriveadskillelse ved at opdele hoveddatabasen fra databasen (skriveanmodningsoperation fra hoveddatabasen, læseanmodningsoperation fra databasen);
【Idéer til at løse dataforsinkelser】
1. Princippet om master-slave synkronisering (her tager vi det mest populære MySQL som eksempel)
Her er et skematisk diagram over en klassisk MySQL master-slave datasynkronisering via binlog:
2. Hvordan opstår problemer?
1. Ud fra ovenstående skema er det ikke svært at finde, at master-slave-synkronisering har en bestemt forsinkelse, som påvirker forsinkelsesstørrelsen:
(1) Forsinkelsens størrelse afhænger af mængden af data, der genereres fra den seneste synkronisering til nutiden
(2) Den nuværende netværkssituation mellem servere
(3) Presset fra selve master-slave-serveren (CPU, hukommelse, IO osv.)
2. Da databasetjenesten generelt er placeret i intranettet, og serveren vil være højere i konfigurationen (mere end det faktiske behov) ved køb, er synkroniseringen grundlæggende meget hurtig, typisk på millisekunder;
3. I generelle forretningsscenarier kan millisekundslatens ignoreres;
4. Der findes generelle og specielle tilfælde, og nogle særlige situationer kræver tidsforskel i millisekund i realtid. Her er almindelige løsninger til disse særlige situationer.
3. Datalatensløsninger:
1. Skema 1: Skriv program-dobbelt (skriv hoveddatabasen og læs databasen samtidig)
2. Skema 2: Læs programmet for at tjekke hoveddatabasen
3. Skema 3: Skriv hoveddatabasen og skriv cachen (sæt en bestemt udløbstid, som generelt er lidt længere end den maksimale forsinkelse for databasesynkronisering), læs programmet, læs cachen og læs slave-databasen
4. Fordele og ulemper ved de tre ordninger:
1. Skema 1: Dobbeltskrivning vil forbruge en vis mængde ydeevne, hvilket er relativt enkelt at implementere og ikke egnet til scenarier med høj samtidig skrivning;
2. Skema 2: Læseprogrammet vil påvirke ydeevnen af hovedbiblioteket, som er relativt enkelt at implementere og ikke egnet til scenarier med høj samtidig læsning.
3. Skema 3: I de fleste tilfælde kræver læsning og skrivning mere skriveydelse, hvilket er mere komplekst at implementere og egnet til både høje samtidige læsninger og skrivninger (cache-læsninger og skrivninger er meget hurtige);
【Resumé】
1. Implementering er vigtig, men vigtigere er idéen;
2. Mange underliggende principper og idéer er universelle
Oprindelig:https://blog.csdn.net/zhanghan18 ... le/details/91638443
|
Opslået den 2. april 2020 kl. 20:41:03
|
|
|
|
