【Voorwoord】
Wanneer de data een bepaalde hoeveelheid bereikt, wordt de database de bottleneck van het hele systeem, en wordt de optimalisatiestrategie doorgaans toegepast als lees- en schrijfscheiding, en de database realiseert lees- en schrijfscheiding door de hoofddatabase te scheiden van de database (schrijfverzoekoperatie vanuit de hoofddatabase, leesverzoekoperatie uit de database);
【Ideeën om datavertragingen op te lossen】
1. Het principe van master-slave synchronisatie (hier nemen we het meest populaire MySQL als voorbeeld)
Hier is een schematisch diagram van een klassieke MySQL master-slave datasynchronisatie via binlog:
2. Hoe ontstaan problemen?
1. Uit het bovenstaande schema is het niet moeilijk te vinden dat master-slave synchronisatie een bepaalde vertraging heeft, wat de vertragingsgrootte beïnvloedt:
(1) De grootte van de vertraging hangt af van de hoeveelheid data die wordt gegenereerd van de laatste synchronisatie tot het heden
(2) De huidige netwerksituatie tussen servers
(3) De druk van de master-slave server zelf (CPU, geheugen, IO, enz.)
2. Omdat de databaseservice zich meestal in het intranet bevindt en de server hoger in de configuratie staat (meer dan de werkelijke behoefte) bij aankoop, is de synchronisatie in principe zeer snel, meestal in milliseconden;
3. In algemene zakelijke scenario's kan millisecondenlatentie worden genegeerd;
4. Er zijn algemene en speciale gevallen, en sommige bijzondere situaties vereisen een realtime milliseconde tijdsverschil. Hier zijn veelvoorkomende oplossingen voor deze bijzondere situaties.
3. Oplossingen voor datalatentie:
1. Schema 1: Schrijf de programma-double (schrijf de hoofddatabase en lees de database tegelijk)
2. Schema 2: Lees het programma om de hoofddatabase te controleren
3. Schema 3: Schrijf de hoofddatabase en schrijf de cache (stel een bepaalde vervaldatum in, meestal iets langer dan de maximale vertraging van databasesynchronisatie), lees het programma, lees de cache en lees de slave-database
4. Voordelen en nadelen van de drie schema's:
1. Schema 1: Dubbel schrijven verbruikt een bepaalde hoeveelheid prestaties, wat relatief eenvoudig te implementeren is en niet geschikt is voor scenario's met hoge gelijktijdige schrijftijd;
2. Schema 2: Het leesprogramma beïnvloedt de prestaties van de hoofdbibliotheek, die relatief eenvoudig te implementeren is en niet geschikt is voor scenario's met hoge gelijktijdige lees.
3. Schema 3: In de meeste gevallen verbruiken lezen en schrijven meer schrijfprestaties, wat complexer is om te implementeren en geschikt is voor zowel hoge gelijktijdige lees- als schrijfopdrachten (cache-lezen en schrijven zijn zeer snel);
【Samenvatting】
1. Implementatie is belangrijk, maar belangrijker is het idee;
2. Veel onderliggende principes en ideeën zijn universeel
Origineel:https://blog.csdn.net/zhanghan18 ... le/details/91638443
|
Geplaatst op 2-4-2020 20:41:03
|
|
|
|
