Wilujeng sumping sadayana. Ieu Vladislav Rodin. Ayeuna abdi nuju ngajar kursus ngeunaan arsitéktur perangkat lunak sareng arsitéktur perangkat lunak beban tinggi di portal OTUS. Sateuacan diluncurkeunna aliran kursus anyar Kuring mutuskeun pikeun nulis karya asli pondok anu kuring hoyong bagikeun ka anjeun.
perkenalan
Kusabab HDD ngan ukur tiasa nanganan sakitar 400-700 operasi per detik (anu teu tiasa dibandingkeun sareng RPS has pikeun sistem anu dimuat pisan), database berbasis disk klasik mangrupikeun hambatan dina arsitéktur. Ku alatan éta, perhatian khusus kedah dibayar kana pola skala panyimpenan ieu.
Ayeuna, aya dua pola skala basis data: réplikasi sareng sharding. Sharding ngamungkinkeun anjeun pikeun skala operasi nulis, sahingga ngirangan RPS nulis per server dina klaster anjeun. Réplikasi ngamungkinkeun anjeun pikeun ngalakukeun hal anu sami, tapi nganggo operasi maca. Pola ieu mangrupikeun fokus tulisan ieu.
réplikasi
Dina tingkat anu luhur, réplikasi mangrupikeun masalah anu saderhana: anjeun gaduh hiji server anu ngandung data, teras server éta henteu tiasa nanganan beban baca. Anjeun nambihan sababaraha server deui, nyingkronkeun data di sakumna éta, sareng pangguna tiasa maca ti server mana waé dina klaster anjeun.
Sanaos katingalina basajan, aya sababaraha pilihan pikeun ngaklasifikasikeun rupa-rupa palaksanaan skéma ieu:
- Dumasar kana peran dina klaster (master-master atanapi master-slave)
- Ku objék anu ditransfer (dumasar kana baris, dumasar kana pernyataan atanapi campuran)
- Ku mékanisme sinkronisasi simpul
Dinten ieu urang bakal ngabahas sacara khusus poin 3.
Kumaha carana hiji transaksi commit lumangsung?
Topik ieu teu aya patalina langsung sareng réplikasi sareng tiasa dibahas dina tulisan anu misah. Nanging, kumargi maca salajengna teu aya gunana tanpa ngartos mékanisme komit transaksi, hayu atuh kuring ngarangkum poin anu paling dasar. Komit transaksi lumangsung dina tilu tahapan:
- Tulis transaksi kana log database.
- Ngalaksanakeun transaksi dina mesin database.
- Ngabalikeun konfirmasi ka klien yén transaksi parantos suksés diterapkeun.
Algoritma ieu tiasa gaduh nuansa dina database anu béda: contona, mesin InnoDB MySQL gaduh dua log: hiji pikeun réplikasi (log binér) sareng hiji pikeun pangropéa ACID (log undo/redo), sedengkeun PostgreSQL gaduh hiji log anu ngalaksanakeun duanana fungsi (log tulis sateuacanna = WAL). Nanging, konsép umum anu dipidangkeun di luhur ngamungkinkeun urang pikeun teu malire nuansa sapertos kitu.
Réplikasi sinkron (sinkron)
Hayu urang tambahkeun logika kana algoritma komit transaksi pikeun ngaréplikasi parobihan anu ditampi:
- Tulis transaksi kana log database.
- Ngalaksanakeun transaksi dina mesin database.
- Ngirim data ka sadaya réplika.
- Nampi konfirmasi ti sadaya réplika ngeunaan palaksanaan transaksi ka aranjeunna.
- Ngabalikeun konfirmasi ka klien yén transaksi parantos suksés diterapkeun.
Kalayan pendekatan ieu urang kéngingkeun sababaraha kalemahan:
- Klien ngantosan parobihan diterapkeun kana sadaya réplika.
- Sabot jumlah node dina hiji klaster ningkat, kamungkinan operasi nulis bakal suksés bakal turun.
Sanaos poin 1 kirang langkung jelas, alesan pikeun poin 2 kedah dijelaskeun. Upami urang henteu nampi réspon ti sahenteuna hiji simpul salami réplikasi sinkron, urang bakal ngabalikeun transaksi éta. Ku alatan éta, ku cara ningkatkeun jumlah simpul dina klaster, anjeun ningkatkeun kamungkinan yén operasi nyerat bakal gagal.
Naha urang tiasa ngantosan konfirmasi ngan ukur ti persentase anu tangtu tina simpul, contona, 51% (kuorum)? Leres, urang tiasa, tapi pendekatan klasik meryogikeun konfirmasi ti sadaya simpul, sabab ieu kumaha urang mastikeun konsistensi data anu lengkep dina klaster, anu mangrupikeun kaunggulan anu jelas tina jinis réplikasi ieu.
Réplikasi asinkron (asinkron)
Hayu urang modifikasi algoritma samemehna. Urang bakal ngirim data ka réplika "engké engké," sareng "engké engké" parobihan bakal diterapkeun kana réplika:
- Tulis transaksi kana log database.
- Ngalaksanakeun transaksi dina mesin database.
- Ngabalikeun konfirmasi ka klien yén transaksi parantos suksés diterapkeun.
- Ngirim data ka réplika sareng nerapkeun parobihan kana éta.
Pamarekan ieu ngahasilkeun klaster anu gancang jalan, sabab urang henteu ngajantenkeun klien ngantosan data dugi ka réplika sareng bahkan komitmen.
Nanging, kaayaan miceun data ka réplika "kadang engké" tiasa nyababkeun leungitna transaksi, khususna anu parantos dikonfirmasi ka pangguna. Upami data tacan diréplikasi, konfirmasi operasi anu suksés tacan dikirim ka klien, sareng node anu nampi parobihan ngalaman kagagalan hard drive, urang kaleungitan transaksi, anu tiasa nyababkeun akibat anu teu pikaresepeun.
Réplikasi semisinkron
Tungtungna, urang parantos ngahontal réplikasi semisinkron. Jinis réplikasi ieu teu pati dikenal atanapi dianggo sacara lega, tapi éta pikaresepeun pisan sabab tiasa ngagabungkeun kauntungan tina réplikasi sinkron sareng asinkron.
Hayu urang cobian ngagabungkeun dua pendekatan sateuacanna. Urang moal ngantep klien ditunda lila, tapi urang bakal meryogikeun data anu ditiru:
- Tulis transaksi kana log database.
- Ngalaksanakeun transaksi dina mesin database.
- Ngirim data ka réplika.
- Nampi konfirmasi ti replika yén parobihan parantos ditampi (parobihan éta bakal diterapkeun "engké engké").
- Ngabalikeun konfirmasi ka klien yén transaksi parantos suksés diterapkeun.
Punten perhatoskeun yén ku algoritma ieu, karugian transaksi ngan ukur kajantenan upami simpul anu nampi parobihan sareng simpul réplika gagal. Kamungkinan kagagalan sapertos kitu dianggap rendah, sareng résiko ieu ditampi.
Nanging, pendekatan ieu ngagaduhan résiko macaan hantu. Pertimbangkeun skénario ieu: dina léngkah 4, urang henteu nampi konfirmasi ti réplika naon waé. Urang kedah ngagulung deui transaksi ieu sareng henteu mulangkeun konfirmasi ka klien. Kusabab data diterapkeun dina léngkah 2, aya sela waktos antara akhir léngkah 2 sareng rollback transaksi, salami transaksi anu sami tiasa ningali parobihan anu henteu kedah aya dina database.
Réplikasi semisinkron anu kirang leungit
Upami anjeun mikirkeun sakedik, anjeun tiasa ngalereskeun masalah phantom read dina skénario ieu ku ngan saukur malikkeun léngkah-léngkah algoritma:
- Tulis transaksi kana log database.
- Ngirimkeun data réplika.
- Nampi konfirmasi ti replika yén parobihan parantos ditampi (parobihan éta bakal diterapkeun "engké engké").
- Ngalaksanakeun transaksi dina mesin database.
- Ngabalikeun konfirmasi ka klien yén transaksi parantos suksés diterapkeun.
Ayeuna urang ngalakukeun parobihan ngan upami parantos ditiru.
kacindekan
Sapertos biasana, teu aya solusi anu idéal; ngan aya sababaraha, masing-masing gaduh kaunggulan sareng kakurangan nyalira sareng cocog pikeun kelas masalah anu béda. Ieu ogé leres nalika milih mékanisme sinkronisasi data pikeun database anu diréplikasi. Kaunggulan réplikasi semisinkron cekap pikaresepeun sareng pikaresepeun pikeun dipertimbangkeun, sanaos panggunaanana terbatas.
Sakitu waé kanggo ayeuna. Tepang deui di !
sumber: www.habr.com
