【Forord】
Når dataene når et visst beløp, vil databasen bli flaskehalsen i hele systemet, og optimaliseringsstrategien brukes vanligvis som lese- og skriveskille, og databasen realiserer lese- og skriveseparasjon ved å dele hoveddatabasen fra databasen (skriveforespørselsoperasjon fra hoveddatabasen, leseforespørselsoperasjon fra databasen);
【Ideer for å løse dataforsinkelser】
1. Prinsippet om master-slave-synkronisering (her tar vi det mest populære MySQL som eksempel)
Her er et skjematisk diagram over en klassisk MySQL master-slave datasynkronisering via binlog:
2. Hvordan oppstår problemer?
1. Fra skjemaet ovenfor er det ikke vanskelig å finne at master-slave-synkronisering har en viss forsinkelse, som påvirker forsinkelsesstørrelsen:
(1) Størrelsen på forsinkelsen avhenger av mengden data som genereres fra siste synkronisering til nåtiden
(2) Den nåværende nettverkssituasjonen mellom servere
(3) Presset fra selve master-slave-serveren (CPU, minne, IO, osv.)
2. Siden databasetjenesten vanligvis er i intranettet, og serveren vil være høyere i konfigurasjonen (mer enn det faktiske behovet) når den kjøpes, er synkroniseringen i praksis svært rask, vanligvis i millisekunder;
3. I generelle forretningsscenarier kan millisekundlatens ignoreres;
4. Det finnes generelle og spesielle tilfeller, og noen spesielle situasjoner krever sanntids millisekunds tidsforskjell. Her er vanlige løsninger for disse spesielle situasjonene.
3. Løsninger for dataforsinkelse:
1. Skjema 1: Skriv programdobbel (skriv hoveddatabasen og les databasen samtidig)
2. Skjema 2: Les programmet for å sjekke hoveddatabasen
3. Skjema 3: Skriv hoveddatabasen og skriv cachen (sett en viss utløpstid, vanligvis litt lengre enn maksimal forsinkelse for databasesynkronisering), les programmet, les cachen og les slave-databasen
4. Fordeler og ulemper ved de tre ordningene:
1. Skjema 1: Dobbel skriving vil kreve en viss mengde ytelse, noe som er relativt enkelt å implementere, og ikke egnet for scenarioer med høy samtidig skriving;
2. Skjema 2: Leseprogrammet vil påvirke ytelsen til hovedbiblioteket, som er relativt enkelt å implementere og ikke egnet for scenarioer med høy samtidig lesing.
3. Skjema 3: I de fleste tilfeller krever lesing og skriving mer skriveytelse, noe som er mer komplekst å implementere, og egner seg for både høye samtidige lesinger og skrivinger (cache-lesing og skriving er svært rask);
【Sammendrag】
1. Implementering er viktig, men viktigere er ideen;
2. Mange underliggende prinsipper og ideer er universelle
Original:https://blog.csdn.net/zhanghan18 ... le/details/91638443
|
Publisert 2020-4-2020 20:41:03
|
|
|
|
