Halo kabeh. Vladislav Rodin sesambungan. Saiki aku mulang kursus babagan Arsitektur Perangkat Lunak lan Arsitektur Perangkat Lunak Tekanan Tinggi ing OTUS. Ing nunggu wiwitan aliran kursus anyar Aku mutusakΓ© kanggo nulis Piece cendhak saka materi asli sing aku arep kanggo nuduhake karo sampeyan.
Pambuka
Amarga kasunyatan manawa HDD mung bisa nindakake babagan 400-700 operasi per detik (sing ora bisa dibandhingake karo rps khas ing sistem beban dhuwur), database disk klasik minangka bottleneck arsitektur. Mulane, perlu diwenehi perhatian khusus kanggo pola skala panyimpenan iki.
Saiki, ana 2 pola skala basis data: replikasi lan sharding. Sharding ngidini sampeyan ngukur operasi nulis, lan, minangka asil, nyuda rps saben nulis saben server ing kluster sampeyan. Replikasi ngidini sampeyan nindakake perkara sing padha, nanging kanthi operasi maca. Iku pola iki sing artikel iki pengabdian kanggo.
replikasi
Yen sampeyan ndeleng replikasi ing tingkat sing dhuwur banget, iku prasaja: sampeyan duwe siji server, ana data, banjur server iki ora bisa ngatasi beban maca data iki. Sampeyan nambah sawetara server liyane, nyinkronake data ing kabeh server, lan pangguna bisa maca saka server apa wae ing kluster sampeyan.
Senadyan kesederhanaan sing katon, ana sawetara opsi kanggo klasifikasi macem-macem implementasi skema iki:
- Miturut peran ing kluster (master-master utawa master-slave)
- Miturut obyek sing dikirim (basis baris, basis statement utawa campuran)
- Miturut mekanisme sinkronisasi simpul
Dina iki kita bakal menehi hasil karo poin 3.
Kepiye carane nggawe transaksi?
Topik iki ora ana hubungane langsung karo replikasi; artikel sing kapisah bisa ditulis, nanging amarga maca luwih lanjut ora ana gunane tanpa ngerti mekanisme komitmen transaksi, mula aku ngelingake sampeyan babagan perkara sing paling dhasar. Komitmen transaksi dumadi ing 3 tahap:
- Log transaksi menyang log database.
- Nggunakake transaksi ing mesin database.
- Mbalekake konfirmasi menyang klien yen transaksi kasebut kasil ditrapake.
Ing basis data sing beda-beda, algoritma iki bisa uga duwe nuansa: contone, ing mesin InnoDB database MySQL ana 2 log: siji kanggo replikasi (log biner), lan liyane kanggo njaga ACID (batal / redo log), nalika ing PostgreSQL ana siji log sing nindakake loro fungsi (nulis ahead log = WAL). Nanging apa sing dituduhake ing ndhuwur yaiku konsep umum, sing ngidini nuansa kasebut ora dianggep.
Replikasi sinkron (sinkronisasi).
Ayo nambah logika kanggo niru owah-owahan sing ditampa ing algoritma komit transaksi:
- Log transaksi menyang log database.
- Nggunakake transaksi ing mesin database.
- Ngirim data menyang kabeh replika.
- Nampa konfirmasi saka kabeh replika yen transaksi wis rampung.
- Mbalekake konfirmasi menyang klien yen transaksi kasebut kasil ditrapake.
Kanthi pendekatan iki, kita entuk sawetara kekurangan:
- klien ngenteni owah-owahan ditrapake kanggo kabeh replika.
- minangka nomer kelenjar ing kluster mundhak, kita nyuda kamungkinan sing operasi nulis bakal sukses.
Yen kabeh luwih utawa kurang jelas karo titik 1, mula alasan kanggo titik 2 kudu diterangake. Yen sajrone replikasi sinkron kita ora nampa respon saka paling ora siji simpul, kita muter maneh transaksi. Mangkono, kanthi nambah jumlah simpul ing kluster, sampeyan nambah kemungkinan operasi nulis bakal gagal.
Apa kita bisa ngenteni konfirmasi saka mung persentase tartamtu saka kelenjar, contone, saka 51% (quorum)? Ya, kita bisa, nanging ing versi klasik, konfirmasi saka kabeh kelenjar dibutuhake, amarga iki carane kita bisa njamin konsistensi data lengkap ing kluster, kang kauntungan undoubted saka jinis replikasi.
Replikasi asinkron (asinkron).
Ayo ngowahi algoritma sadurunge. Kita bakal ngirim data menyang replika "sawetara mengko", lan "sawetara mengko" owah-owahan bakal ditrapake kanggo replika:
- Log transaksi menyang log database.
- Nggunakake transaksi ing mesin database.
- Mbalekake konfirmasi menyang klien yen transaksi kasebut kasil ditrapake.
- Ngirim data menyang replika lan nglamar owah-owahan.
Pendekatan iki ndadΓ©kakΓ© kasunyatan sing kluster dianggo cepet, amarga kita ora tetep klien nunggu data kanggo tekan replika lan malah setya.
Nanging kahanan mbuwang data menyang replika "sok-sok mengko" bisa nyebabake mundhut transaksi, lan mundhut transaksi sing dikonfirmasi dening pangguna, amarga yen data kasebut ora duwe wektu kanggo ditiru, konfirmasi menyang klien. babagan sukses operasi dikirim, lan simpul sing owah-owahan teka tabrakan HDD, kita kelangan transaksi, kang bisa mimpin kanggo jalaran banget karu.
Replikasi semisync
Pungkasan, kita entuk replikasi semi-sinkron. Jinis replikasi iki ora pati ngerti utawa umum banget, nanging menarik banget amarga bisa nggabungake kaluwihan saka replikasi sinkron lan asinkron.
Coba gabungke 2 pendekatan sadurunge. Kita ora bakal njaga klien nganti suwe, nanging mbutuhake data kasebut ditiru:
- Log transaksi menyang log database.
- Nggunakake transaksi ing mesin database.
- Ngirim data menyang replika.
- Nampa konfirmasi saka replika yen owah-owahan wis ditampa (bakal ditrapake "sawetara mengko").
- Mbalekake konfirmasi menyang klien yen transaksi kasebut kasil ditrapake.
Wigati dimangerteni manawa kanthi algoritma iki, mundhut transaksi mung kedadeyan yen simpul nampa owah-owahan lan simpul replika gagal. Kemungkinan gagal kasebut dianggep kurang, lan risiko kasebut ditampa.
Nanging kanthi pendekatan iki ana risiko maca phantom. Coba bayangake skenario ing ngisor iki: ing langkah 4, kita ora nampa konfirmasi saka replika apa wae. Kita kudu muter maneh transaksi iki lan ora bali konfirmasi kanggo klien. Wiwit data wis Applied ing langkah 2, ana longkangan wektu antarane mburi langkah 2 lan rollback transaksi, sajrone transaksi podo bisa ndeleng owah-owahan sing ngirim ora ing database.
Replikasi semisync sing ora ilang
Yen sampeyan mikir sethithik, sampeyan mung bisa mbalikke langkah-langkah algoritma lan ndandani masalah maca phantom ing skenario iki:
- Log transaksi menyang log database.
- Ngirim data replika.
- Nampa konfirmasi saka replika yen owah-owahan wis ditampa (bakal ditrapake "sawetara mengko").
- Nggunakake transaksi ing mesin database.
- Mbalekake konfirmasi menyang klien yen transaksi kasebut kasil ditrapake.
Saiki kita nindakake owah-owahan mung yen wis ditiru.
kesimpulan
Kaya biasane, ora ana solusi sing cocog, ana sawetara solusi, sing saben duwe kaluwihan lan kekurangan dhewe lan cocog kanggo ngrampungake macem-macem kelas masalah. Iki pancen bener kanggo milih mekanisme kanggo nyinkronake data ing database replika. Setel kaluwihan sing diduweni replikasi semi-sinkron cukup padhet lan menarik sing bisa dianggep pantes digatekake, sanajan prevalensi kurang.
Mekaten. Ndeleng sampeyan ing !
Source: www.habr.com