【Predgovor】
Ko podatki dosežejo določeno količino, postane baza podatkov ozko grlo celotnega sistema, optimizacijska strategija pa se običajno uporablja kot ločitev branja in pisanja, pri čemer baza uresniči ločitev branja in pisanja z ločitvijo glavne baze podatkov od baze podatkov (operacija zahteve za pisanje iz glavne baze, operacija zahteve za branje iz baze);
【Ideje za reševanje podatkovnih zamud】
1. Načelo master-slave sinhronizacije (tukaj vzamemo najbolj priljubljen MySQL kot primer)
Tukaj je shematski diagram klasične MySQL sinhronizacije podatkov med glavnim in podrejenim preko binloga:
2. Kako nastanejo težave?
1. Iz zgornje sheme ni težko ugotoviti, da ima master-slave sinhronizacija določen zamik, ki vpliva na velikost zamika:
(1) Velikost zakasnitve je odvisna od količine podatkov, ustvarjenih od zadnje sinhronizacije do sedanjosti
(2) Trenutna omrežna situacija med strežniki
(3) Pritisk samega strežnika master-slave (CPU, pomnilnik, vhodno-vhodni sistem itd.)
2. Ker je storitev baze podatkov običajno v intranetu in je strežnik ob nakupu višje v konfiguraciji (več, kot je dejansko potrebno), je sinhronizacija v osnovi zelo hitra, običajno v milisekundah;
3. V splošnih poslovnih scenarijih lahko milisekundno zakasnitev zanemarimo;
4. Obstajajo splošni in posebni primeri, nekatere posebne situacije pa zahtevajo časovno razliko v milisekundah v realnem času. Tukaj so pogoste rešitve za te posebne situacije.
3. Rešitve za zakasnitev podatkov:
1. Shema 1: Program napišeš dvojno (zapišeš glavno bazo podatkov in bereš bazo hkrati)
2. Shema 2: Preberi program za preverjanje glavne baze podatkov
3. Shema 3: Zapišite glavno bazo podatkov in zapišite predpomnilnik (nastavite določen čas poteka, običajno nekoliko daljši od največje zakasnitve sinhronizacije podatkovne baze), preberite program, preberite predpomnilnik in preberete podrejeno bazo podatkov
4. Prednosti in slabosti treh shem:
1. Shema 1: Dvojno pisanje bo porabljalo določeno količino zmogljivosti, kar je razmeroma enostavno za izvedbo in ni primerno za scenarije z visokim sočasnim pisanjem;
2. Shema 2: Bralni program bo vplival na zmogljivost glavne knjižnice, ki je razmeroma enostavna za implementacijo in ni primerna za scenarije z visokim sočasnim branjem.
3. Shema 3: V večini primerov branje in pisanje porabita več zmogljivosti pisanja, kar je bolj zapleteno za implementacijo in je primerno tako za visoka sočasna branja kot zapise (branje in pisanje v predpomnilniku sta zelo hitra);
【Povzetek】
1. Izvedba je pomembna, a še pomembnejša je ideja;
2. Številna temeljna načela in ideje so univerzalna
Izvirno:https://blog.csdn.net/zhanghan18 ... le/details/91638443
|
Objavljeno 2020-4-2 20:41:03
|
|
|
|
