8.1 ID Transaksi
Punika ditetepake minangka XID utawa TxID (yen ana prabédan, marang kula). Timestamps bisa digunakake minangka TxID, kang bisa muter menyang tangan yen kita pengin mulihake kabeh tumindak kanggo sawetara titik ing wektu. Masalah bisa muncul yen cap wektu ora cukup granular - banjur transaksi bisa entuk ID sing padha.
Mulane, pilihan sing paling dipercaya yaiku ngasilake ID prod UUID sing unik. Ing Python iki gampang banget:
>>> import uuid
>>> str(uuid.uuid4())
'f50ec0b7-f960-400d-91f0-c42a6d44e3d0'
>>> str(uuid.uuid4())
'd15bed89-c0a5-4a72-98d9-5507ea7bc0ba'
Ana uga pilihan kanggo nyiyapake sakumpulan data sing nemtokake transaksi lan nggunakake hash iki minangka TxID.
8.2 Nyoba maneh
Yen kita ngerti manawa fungsi utawa program tartamtu minangka idempoten, mula kita bisa lan kudu nyoba mbaleni telpon kasebut yen ana kesalahan. Lan kita mung kudu disiapake kanggo kasunyatan manawa sawetara operasi bakal menehi kesalahan - amarga aplikasi modern disebarake liwat jaringan lan hardware, kesalahan kasebut kudu dianggep ora minangka pangecualian, nanging minangka norma. Kesalahan bisa kedadeyan amarga kacilakan server, kesalahan jaringan, kemacetan aplikasi remot. Kepiye carane aplikasi kita kudu ditindakake? Bener, coba baleni operasi kasebut.
Wiwit siji Piece saka kode bisa ngomong luwih saka kaca kabèh tembung, ayo kang nggunakake siji conto kanggo ngerti carane mekanisme naif nyoba maneh saenipun kudu bisa. Aku bakal nduduhake iki nggunakake perpustakaan Tenacity (sampeyan uga-dirancang malah yen sampeyan ora rencana kanggo nggunakake, contone kudu nuduhake carane sampeyan bisa ngrancang mekanisme ambalan):
import logging
import random
import sys
from tenacity import retry, stop_after_attempt, stop_after_delay, wait_exponential, retry_if_exception_type, before_log
logging.basicConfig(stream=sys.stderr, level=logging.DEBUG)
logger = logging.getLogger(__name__)
@retry(
stop=(stop_after_delay(10) | stop_after_attempt(5)),
wait=wait_exponential(multiplier=1, min=4, max=10),
retry=retry_if_exception_type(IOError),
before=before_log(logger, logging.DEBUG)
)
def do_something_unreliable():
if random.randint(0, 10) > 1:
raise IOError("Broken sauce, everything is hosed!!!111one")
else:
return "Awesome sauce!"
print(do_something_unreliable.retry.statistics)
> Ing kasus, Aku bakal ngomong: \@retry(...) punika sintaks Python khusus disebut "dekorator". Iku mung fungsi nyoba maneh (...) sing mbungkus fungsi liyane lan nindakake soko sadurunge utawa sawise kaleksanan.
Kaya sing kita deleng, nyoba maneh bisa dirancang kanthi kreatif:
- Sampeyan bisa matesi usaha dening wektu (10 detik) utawa nomer usaha (5).
- Bisa eksponensial (yaiku, 2 ** sawetara nambah nomer n ). utawa piye wae liya (contone, tetep) kanggo nambah wektu antarane usaha kapisah. Varian eksponensial diarani "congestion collapse".
- Sampeyan bisa nyoba maneh mung kanggo jinis tartamtu saka kasalahan (IOError).
- Nyoba maneh bisa didhisiki utawa rampung dening sawetara entri khusus ing log.
Saiki kita wis ngrampungake kursus pejuang enom lan ngerti blok bangunan dhasar sing kudu ditindakake transaksi ing sisih aplikasi, ayo kenal karo rong cara sing ngidini kita ngetrapake transaksi ing sistem sing disebarake.
8.3 Piranti canggih kanggo penyayang transaksi
Aku mung bakal menehi definisi sing cukup umum, amarga topik iki pantes kanggo artikel gedhe sing kapisah.
Komitmen rong fase (2 pc) . 2pc duwe rong fase: fase persiapan lan fase komitmen. Sajrone fase nyiapake, kabeh layanan mikro bakal dijaluk nyiyapake sawetara owah-owahan data sing bisa ditindakake kanthi atom. Sawise kabeh wis siyap, fase komit bakal nggawe owah-owahan sing nyata. Kanggo koordinasi proses kasebut, koordinator global dibutuhake, sing ngunci obyek sing dibutuhake - yaiku, ora bisa diakses kanggo owah-owahan nganti koordinator mbukak kunci. Yen microservice tartamtu ora siap kanggo owah-owahan (contone, ora nanggapi), koordinator bakal mbatalake transaksi lan miwiti proses rollback.
Kenapa protokol iki apik? Iku menehi atomicity. Kajaba iku, njamin isolasi nalika nulis lan maca. Iki tegese owah-owahan ing siji transaksi ora katon kanggo wong liya nganti koordinator nindakake owah-owahan. Nanging sifat-sifat kasebut uga duwe kekurangan: amarga protokol iki sinkron (blocking), sistem kasebut alon-alon (senadyan RPC nelpon dhewe cukup alon). Lan maneh, ana bebaya saka pamblokiran bebarengan.
Saga . Ing pola iki, transaksi sing disebarake ditindakake kanthi transaksi lokal sing ora sinkron ing kabeh layanan mikro sing gegandhengan. Microservices komunikasi karo saben liyane liwat bis acara. Yen ana layanan mikro sing gagal ngrampungake transaksi lokal, layanan mikro liyane bakal nindakake transaksi ganti rugi kanggo mbalekake owah-owahan kasebut.
Kauntungan saka Saga yaiku ora ana obyek sing diblokir. Nanging ana, mesthi, downsides.
Saga angel debug, utamane yen ana akeh layanan mikro sing melu. Kerugian liyane saka pola Saga yaiku ora duwe isolasi maca. Yaiku, yen sifat sing dituduhake ing ACID penting kanggo kita, mula Saga ora cocog kanggo kita.
Apa sing kita deleng saka deskripsi rong teknik kasebut? Kasunyatan manawa ing sistem sing disebarake, tanggung jawab kanggo atomicity lan isolasi ana ing aplikasi kasebut. Bab sing padha kedadeyan nalika nggunakake database sing ora menehi jaminan ACID. Yaiku, kaya resolusi konflik, mundur, komitmen, lan mbebasake ruang ana ing pundhak pangembang.
8.4 Kepiye carane aku ngerti yen aku butuh jaminan ACID?
Nalika ana kemungkinan dhuwur sing pesawat tartamtu saka pangguna utawa pangolahan bakal bebarengan ing data sing padha .
Nyuwun pangapunten babagan banalitas, nanging conto khas yaiku transaksi finansial.
Nalika urutan transaksi dileksanakake penting.
Bayangake yen perusahaan sampeyan arep ngalih saka FunnyYellowChat messenger menyang FunnyRedChat messenger, amarga FunnyRedChat ngidini sampeyan ngirim gif, nanging FunnyYellowChat ora bisa. Nanging sampeyan ora mung ngganti utusan - sampeyan migrasi korespondensi perusahaan saka siji utusan menyang liyane. Sampeyan nindakake iki amarga programer sampeyan kesed kanggo nyathet program lan proses ing endi wae ing tengah, lan malah nerbitake kabeh ing saluran sing beda-beda ing utusan. Ya, lan salesman sampeyan nerbitake rincian negosiasi lan perjanjian ing papan sing padha. Ing cendhak, kabeh urip perusahaan sampeyan ana, lan amarga ora ana sing duwe wektu kanggo nransfer kabeh menyang layanan kanggo dokumentasi, lan telusuran utusan cepet bisa digunakake, sampeyan mutusake tinimbang ngresiki reruntuhan, mung nyalin kabeh pesen menyang lokasi anyar. Urutan pesen iku penting
Miturut cara, kanggo korespondensi ing utusan, urutan umume penting, nanging nalika wong loro nulis soko ing obrolan sing padha ing wektu sing padha, mula umume ora penting sing pesen bakal katon dhisik. Dadi, kanggo skenario tartamtu iki, ACID ora dibutuhake.
Conto liyane sing bisa ditindakake yaiku bioinformatika. Aku ora ngerti iki kabeh, nanging aku nganggep urutan penting nalika deciphering génom manungsa. Nanging, aku krungu manawa ahli bioinformatika umume nggunakake sawetara alat kanggo kabeh - bisa uga duwe database dhewe.
Nalika sampeyan ora bisa menehi pangguna utawa ngolah data basi.
Lan maneh - transaksi finansial. Kanggo jujur, aku ora bisa mikir conto liyane.
Nalika transaksi sing ditundha digandhengake karo biaya sing signifikan. Mbayangno masalah sing bisa muncul nalika dhokter lan perawat loro-lorone nganyari rekaman pasien lan mbusak owah-owahan saben liyane ing wektu sing padha, amarga database ora bisa ngisolasi transaksi. Sistem kesehatan minangka wilayah liyane, saliyane keuangan, ing ngendi jaminan ACID cenderung kritis.
8.5 Nalika aku ora butuh ASAM?
Nalika pangguna nganyari mung sawetara data pribadi.
Contone, pangguna ninggalake komentar utawa cathetan lengket ing kaca web. Utawa ngowahi data pribadhi ing akun pribadhi karo panyedhiya layanan apa wae.
Nalika pangguna ora nganyari data ing kabeh, nanging mung tambahan karo anyar (tambah).
Contone, aplikasi sing mlaku sing ngirit data nalika mlaku: pira sing sampeyan lakoni, wektu apa, rute, lsp. Saben roto anyar data anyar, lan sing lawas ora diowahi ing kabeh. Mbok, adhedhasar data, sampeyan entuk analytics - lan mung database NoSQL sing apik kanggo skenario iki.
Nalika logika bisnis ora nemtokake perlu kanggo urutan tartamtu kang transaksi dileksanakake.
Mbokmenawa, kanggo blogger Youtube sing ngumpulake sumbangan kanggo produksi materi anyar sajrone siaran langsung sabanjure, ora pati penting sapa, kapan lan ing urutan apa, mbuwang dhuwit.
Nalika pangguna bakal tetep ing kaca web utawa jendhela aplikasi sing padha kanggo sawetara detik utawa malah menit, lan mulane padha bakal weruh data stale.
Secara teoritis, iki minangka media warta online, utawa Youtube sing padha. Utawa "Habr". Nalika iku ora Matter kanggo sampeyan sing transaksi pepak bisa sementara disimpen ing sistem, sampeyan bisa nglirwakake tanpa karusakan.
Yen sampeyan nglumpukake data saka akeh sumber, lan data sing dianyari kanthi frekuensi dhuwur - contone, data babagan panggonan parkir ing kutha sing ganti paling sethithik saben 5 menit, mula ing teori ora bakal dadi masalah gedhe. kanggo sampeyan yen ing sawetara titik transaksi kanggo salah siji saka parking ora bakal liwat. Senajan, mesthi, iku gumantung apa persis sing arep kanggo apa karo data iki.
GO TO FULL VERSION