Ko'p mintaqali yozuvlar: o'zgarish aslida qayerda tasdiqlanadi?
Marshrutlash so'rovni mintaqaga yetkazadi; yozuvni atomar qiladigan narsa faqat tranzaksiya chegarasi. Invariantni nomlang, egasini tanlang, so'ng qayta urinishni uning atrofida loyihalang.
Ikki mintaqada ikki ilova serveri, VPN orqali yozayotgan bitta mijoz va hech kim yozmagan savol: yozuv sodir bo'lganini qaysi komponent hal qiladi? Marshrutlash so'rovni jarayonga yetkazadi. Tranzaksiya chegarasi o'zgarish qachon barqaror va ko'rinadigan bo'lishini hal qiladi. Bular turli tizimlar bajaradigan turli ishlar, va ular orasidagi bo'shliq ko'p mintaqali yozuv xatolarining ko'pchiligi yashaydigan joy.
Xaritadan emas, biznes qoidasidan boshlang
Geografiya haqida emas, biznes qoidasi haqida gap bilan boshlang: qaysi o'qishlar va yozuvlar birga muvaffaqiyatli bo'lishi kerak va shu vaqtda qaysi bir vaqtli o'zgarishlar imkonsiz bo'lishi kerak. Zaxira band qilish uchun bu zaxira tekshiruvi va band qilish ikkalasi ham kuchga kirishini yoki hech biri kirmasligini, va oradagi ikkinchi buyurtma o'sha birlikni ishlata olmasligini bildiradi.
| Requirement | What satisfies it | What does not |
|---|---|---|
| All-or-nothing application | A transaction inside one owning system | A VPN path between regions |
| No double spend | Isolation strong enough to exclude the conflict | Atomicity alone |
| Survive a region loss | Replication the database itself documents | Two independent databases behind one client |
Aynan o'sha o'rta qatorni jamoalar o'tkazib yuboradi. Yetarli izolyatsiyasiz atomarlik ikki tranzaksiyaga har biri to'g'ri commit bo'lishiga imkon beradi va baribir biznes imkonsiz deb hisoblaydigan holatni keltirib chiqaradi, va keyin hech qanday qayta urinish mantiqi buni tuzatmaydi.
Bitta obro'li chegara ikki mintaqaviy serverdan ustun
Mintaqaviy ilova serverlari o'z joyida qolishi mumkin, agar operatsiyani bitta qo'llab-quvvatlanadigan tranzaksiya chegarasi ichida bajaradigan xizmatga topshirsa. Ilova qatlami niyat marshrutizatoriga aylanadi; ma'lumot qatlami haqiqatga egalik qiladi.
Bu chegarani qisqa va u tegadigan ma'lumotlarga yaqin saqlang. Inson so'rovga javob berayotganda yoki qo'ng'iroq ikki mintaqani kesib o'tayotganda ochiq tutilgan tranzaksiya vaqtini qulflarni ushlab turishga sarflaydi va uning orqasida boshqa narsa muddati o'tish ehtimolini oshiradi. Bu nosozlik ma'lumotlar bazasi muammosiga o'xshaydi va aslida shunday kiyin olgan loyihalash muammosidir. Qarorni ma'lumot qatlamiga ko'chirish odatda uni butunlay yo'q qiladi.
BEGIN;
UPDATE inventory SET reserved = reserved + 1
WHERE sku = 'A-100' AND available >= 1;
INSERT INTO reservation (sku, order_id) VALUES ('A-100', 'ord-9f');
COMMIT;Bu eskizni chegara sifatida o'qing, unumdorlik tavsiyasi sifatida emas. Gap shundaki, tekshiruv va kiritish bitta commitni bo'lishadi, shuning uchun bir vaqtli buyurtma zaxirani sarflangan ko'radi yoki umuman ko'rmaydi.
Replikatsiyalangan ma'lumotlar bazasi nima beradi va nima bermaydi
Replikatsiyalangan ma'lumotlar bazasi o'zining tranzaksiya modeli qo'llab-quvvatlaganda kengroq chegara bera oladi. Spanner bitta ma'lumotlar bazasi ichida jadvallar bo'ylab atomar o'qish-yozuv tranzaksiyalarini, belgilangan izolyatsiya va qayta urinish xatti-harakati bilan hujjatlashtiradi. Bu siz o'qiydigan, sinovdan o'tkazadigan va ataylab tayanadigan kafolat.
Bu ham mahsulotdan keladigan kafolat, marshrutdan emas. Mintaqalar orasidagi VPN paketlarning qanday sayohat qilishini va nosozliklarning qanday namoyon bo'lishini o'zgartiradi. Tunnel qanchalik sog'lom ko'rinmasin, u tranzaksiya chegarasini bir qatorga ham kengaytirmaydi. Ikkalasini aralashtirish har bir komponent o'z tekshiruvidan o'tadigan, ammo ma'lumot baribir mos kelmaydigan arxitekturalarni keltirib chiqaradi.
Ikki ma'lumotlar bazasi bitta tizimga aylanmaydi
Mustaqil boshqariladigan ikki ma'lumotlar bazasi mijozlar ikkalasiga ham yeta olishi sababli umumiy tranzaksiya menejeriga ega bo'lmaydi. Agar biznesga haqiqatan ham shu juftlik bo'ylab atomar majburiyat kerak bo'lsa, muvofiqlashtirish mexanizmi, ishtirokchilar va tiklash jarayoni taxmin qilinmasdan tanlanishi va malakalanishi kerak.
Ish tayyorlangandan keyin ishtirokchi yoki aloqa yo'qolgan lahzani o'ylab ko'ring. Qo'llab-quvvatlanadigan taqsimlangan commit tiklash tartibi va inson qarorini talab qiladigan noaniq holatni qoldirishi mumkin, va u har bir bo'linishda har bir mintaqa yozishga yaroqli bo'lib qolishini va'da qilmaydi.
Agar buning o'rniga asinxron muvofiqlashtirish maqbul bo'lsa, buni aniq ayting va oraliq biznes holatlari hamda kelishtirish qoidalarini yozib qo'ying. Kompensatsiya bilan mahalliy tasdiqlangan qadamlar zanjiri qonuniy loyihadir; u shunchaki boshqa nom ostidagi bitta atomar tranzaksiya emas.
Qayta urinishni birinchi uzilishdan oldin loyihalang
Operatsiya commit bo'lgandan keyin mijoz javobni yo'qotishi mumkin, shuning uchun chaqiruvchi taym-autni nosozlik deb hisoblay olmaydi. Barqaror so'rov identifikatorini saqlang va o'zgarishni qayta urinishdan oldin xizmat natijasi yoki idempotentlik mexanizmidan foydalaning, aks holda qayta urinish ikkinchi yozuvga aylanadi.
Avtomatik tranzaksiya callbacklari qayta urinish mumkin bo'lgan bekor qilishdan keyin bir necha marta ishlashi mumkin, bu ularni qaytarilmas tashqi ta'sirlar uchun yomon uyga aylantiradi. Ish oqimi ular uchun aniq xavfsiz protokol belgilamasa, ularni callbackdan tashqarida tuting. Xuddi shu ehtiyot pul sarflaydigan yoki xabar yuboradigan har qanday narsaga tegishli. Ikki marta hisoblash ikki marta log qatoridan ancha qiyin suhbat.
Qabul to'rt stsenariyni qayta o'ynashi kerak: bir xil qator uchun kurashayotgan ikki mijoz, xizmat qayta urinish mumkin deb aytgan bekor qilish, javobi hech qachon kelmaydigan commit va bitta mintaqa yoki ular orasidagi aloqaning yo'qolishi. Tasdiqlangan biznes natijasini va hal qilinmagan holatlarni marshrutlash loyihasi yonida yozib qo'ying, hech kim tarmoqni kafolat beruvchi komponent deb adashtirmasin.