Çoxregionlu yazmalar: commit əslində hansı regionda baş verir?
Marşrutlaşdırma sorğunu regiona çatdırır; yazmanı atomar edən yalnız tranzaksiya sərhədidir. İnvariantı adlandırın, sahibi seçin, sonra təkrar cəhdi onun ətrafında qurun.
İki regionda iki tətbiq serveri, VPN vasitəsilə yazma edən bir müştəri və heç kimin yazmadığı bir sual: yazmanın baş verdiyini hansı komponent qərar verir? Marşrutlaşdırma sorğunu prosesə çatdırır. Tranzaksiya sərhədi dəyişikliyin nə vaxt davamlı və görünən olacağını müəyyən edir. Bunlar müxtəlif sistemlərin yerinə yetirdiyi müxtəlif işlərdir və aralarındakı boşluq çoxregionlu yazma xətalarının çoxunun yaşadığı yerdir.
Xəritədən deyil, biznes qaydasından başlayın
Coğrafiyadan deyil, biznes qaydasından bəhs edən bir cümlə ilə başlayın: hansı oxumalar və yazmalar birlikdə uğurlu olmalıdır və hansı eyni vaxtlı dəyişikliklər bu zaman qeyri-mümkün olmalıdır. Ehtiyat rezervasiyası üçün bu o deməkdir ki, ehtiyat yoxlaması və rezervasiya ya hər ikisi qüvvəyə minir, ya da heç biri, və heç bir ikinci sifariş bu arada həmin vahidi istehlak edə bilməz.
| 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 |
Komandaların atladığı sıra elə ortadakı sıradır. Kifayət qədər izolyasiya olmadan atomarlıq iki tranzaksiyaya ayrı-ayrılıqda düzgün commit etməyə imkan verir və yenə də biznesin qeyri-mümkün saydığı bir vəziyyət yaradır, və heç bir təkrar cəhd məntiqi bunu sonradan düzəltmir.
Bir səlahiyyətli sərhəd iki regional serverdən üstündür
Regional tətbiq serverləri yerində qala bilər, bir şərtlə ki, əməliyyatı onu vahid dəstəklənən tranzaksiya sərhədi daxilində yerinə yetirən xidmətə təqdim etsinlər. Tətbiq qatı niyyətin marşrutlaşdırıcısına çevrilir; məlumat qatı həqiqətə sahib olur.
Bu sərhədi qısa və toxunduğu məlumata yaxın saxlayın. İnsan bir suala cavab verərkən və ya çağırış iki regionu keçərkən açıq saxlanılan tranzaksiya vaxtını kilidləri tutmağa və arxasında başqa bir şeyin vaxtının bitmə ehtimalını artırmağa sərf edir. Bu nasazlıq verilənlər bazası problemi kimi görünür və əslində belə geyinmiş dizayn problemidir. Qərarı məlumat qatına köçürmək onu adətən tamamilə aradan qaldırır.
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 eskizi performans tövsiyəsi kimi deyil, sərhəd kimi oxuyun. Məsələ ondadır ki, yoxlama və əlavəetmə bir commit-i paylaşır, buna görə eyni vaxtlı sifariş ya ehtiyatın istehlak edildiyini görür, ya da heç görmür.
Replikasiya olunmuş verilənlər bazası nə verir və nə vermir
Replikasiya olunmuş verilənlər bazası öz tranzaksiya modeli dəstəklədikdə daha geniş sərhəd təmin edə bilər. Spanner cədvəllər üzrə vahid verilənlər bazası daxilində atomar oxuma-yazma tranzaksiyalarını, müəyyən edilmiş izolyasiya və təkrar cəhd davranışı ilə sənədləşdirir. Bu, oxuduğunuz, sınaqdan keçirdiyiniz və qəsdən güvəndiyiniz bir zəmanətdir.
Bu həm də məhsuldan gələn, marşrutdan gəlməyən bir zəmanətdir. Regionlar arasındakı VPN paketlərin necə getdiyini və nasazlıqların necə üzə çıxdığını dəyişir. Tünel nə qədər sağlam görünsə də, o, tranzaksiya sərhədini bir sətir də uzatmır. İkisini qarışdırmaq hər komponentin öz yoxlamasını keçdiyi, məlumatın isə yenə də uyğunsuz qaldığı arxitekturalar yaradır.
İki verilənlər bazası bir sistemə çevrilmir
Ayrı-ayrılıqda idarə olunan iki verilənlər bazası, müştərilər hər ikisinə çata bildiyi üçün ortaq tranzaksiya meneceri əldə etmir. Əgər biznes həqiqətən cütlük üzrə atomar öhdəlik tələb edirsə, koordinasiya mexanizmi, iştirakçılar və bərpa prosesi hamısı fərz edilmək əvəzinə seçilməli və kvalifikasiya edilməlidir.
İş hazırlandıqdan sonra bir iştirakçının və ya əlaqənin yox olduğu anı düşünün. Dəstəklənən paylanmış commit bərpa proseduru və insan qərarı tələb edən şübhəli vəziyyət buraxa bilər, və hər bölmə boyunca hər regionun yazıla bilən qalacağına dair heç bir vəd vermir.
Əvəzində asinxron koordinasiya qəbul edilirsə, bunu açıq deyin və aralıq biznes vəziyyətlərini və uzlaşdırma qaydalarını yazın. Kompensasiya ilə yerli olaraq təsdiqlənmiş addımlar zənciri qanuni bir dizayndır; sadəcə fərqli ad geyinmiş bir atomar tranzaksiya deyil.
Təkrar cəhdi ilk kəsintidən əvvəl dizayn edin
Müştəri əməliyyat commit edildikdən sonra cavabı itirə bilər, buna görə çağıran fasiləni nasazlıq kimi qəbul edə bilməz. Davamlı sorğu kimliyini qoruyun və dəyişikliyi təkrar cəhd etməzdən əvvəl xidmətin nəticəsindən və ya idempotentlik mexanizmindən istifadə edin, əks halda təkrar cəhd ikinci yazmağa çevrilir.
Avtomatik tranzaksiya çağırışları təkrar cəhd edilə bilən ləğvdən sonra birdən çox dəfə də icra oluna bilər, bu da onları geri dönməz xarici təsirlər üçün pis məkan edir. İş axını onlar üçün açıq təhlükəsiz protokol təyin etmirsə, bunları çağırışdan kənarda saxlayın. Eyni ehtiyat pul xərcləyən və ya mesaj göndərən hər şeyə aiddir. İkiqat ödəniş, ikiqat log sətrindən qat-qat çətin söhbətdir.
Qəbul dörd ssenarini təkrar oynamalıdır: eyni sətir üçün yarışan iki müştəri, xidmətin təkrar cəhd edilə bilər dediyi ləğv, cavabı heç vaxt gəlməyən commit, və bir regionun və ya aralarındaki əlaqənin itməsi. Təsdiqlənmiş biznes nəticəsini və həll olunmamış vəziyyətləri marşrutlaşdırma dizaynının yanında qeyd edin ki, heç kim şəbəkəni zəmanəti verən komponent zənn etməsin.