Çok bölgeli yazmalar: değişiklik gerçekte nerede kesinleşir?
Yönlendirme bir isteği bir bölgeye ulaştırır; yazmayı atomik yapan tek şey işlem sınırıdır. Değişmezi adlandırın, sahibini seçin, sonra yeniden denemeyi onun etrafında tasarlayın.
İki bölgede iki uygulama sunucusu, VPN üzerinden yazan tek bir istemci ve kimsenin yazmadığı bir soru: yazmanın gerçekleştiğine hangi bileşen karar verir? Yönlendirme isteği bir sürece ulaştırır. İşlem sınırı, değişikliğin ne zaman kalıcı ve görünür olacağına karar verir. Bunlar farklı sistemlerin yaptığı farklı işlerdir ve aralarındaki boşluk, çok bölgeli yazma hatalarının çoğunun yaşadığı yerdir.
Haritadan değil, iş kuralından başlayın
Coğrafyadan değil iş kuralından söz eden bir cümleyle başlayın: hangi okumalar ve yazmalar birlikte başarılı olmalı ve bunlar olurken hangi eşzamanlı değişiklikler imkânsız olmalı. Bir envanter rezervasyonu için bu, stok kontrolü ve rezervasyonun ya ikisinin de yürürlüğe girmesi ya da hiçbirinin girmemesi demektir; arada ikinci bir sipariş aynı birimi tüketemez.
| 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 |
Ekiplerin atladığı tam olarak o orta satırdır. Yeterli yalıtım olmadan atomiklik, iki işlemin her birinin doğru biçimde commit etmesine izin verir ve yine de işin imkânsız saydığı bir durum üretir; sonradan hiçbir yeniden deneme mantığı bunu düzeltmez.
Tek bir yetkili sınır iki bölgesel sunucuyu yener
Bölgesel uygulama sunucuları yerlerinde kalabilir, yeter ki işlemi tek bir desteklenen işlem sınırı içinde gerçekleştiren bir hizmete devretsinler. Uygulama katmanı niyetin yönlendiricisi olur; veri katmanı gerçeğe sahiptir.
Bu sınırı kısa ve dokunduğu veriye yakın tutun. Bir insan bir isteme yanıt verirken ya da bir çağrı iki bölgeyi geçerken açık tutulan işlem, zamanını kilitleri tutarak geçirir ve arkasında başka bir şeyin zaman aşımına uğrama olasılığını artırır. Bu arıza veritabanı sorunu gibi görünür ve aslında öyle kılık değiştirmiş bir tasarım sorunudur. Kararı veri katmanına taşımak genellikle onu tamamen ortadan kaldı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 taslağı bir performans önerisi değil, bir sınır olarak okuyun. Mesele şu ki kontrol ve ekleme tek bir commit paylaşır, dolayısıyla eşzamanlı bir sipariş ya stoğun tüketildiğini görür ya da hiç görmez.
Çoğaltılmış bir veritabanının verdiği ve vermediği şeyler
Çoğaltılmış bir veritabanı, kendi işlem modeli desteklediğinde daha geniş bir sınır sağlayabilir. Spanner, tek bir veritabanı içinde tablolar genelinde atomik okuma-yazma işlemlerini, tanımlı yalıtım ve yeniden deneme davranışıyla belgeler. Bu, okuyup test ettiğiniz ve bilinçli olarak güvendiğiniz bir garantidir.
Aynı zamanda üründen gelen bir garantidir, yoldan değil. Bölgeler arasındaki VPN, paketlerin nasıl yol aldığını ve arızaların nasıl göründüğünü değiştirir. Tünel ne kadar sağlıklı görünürse görünsün işlem sınırını tek satır bile genişletmez. İkisini karıştırmak, her bileşenin kendi kontrolünden geçtiği ama verinin yine de uyuşmadığı mimariler üretir.
İki veritabanı tek bir sisteme dönüşmez
Bağımsız yönetilen iki veritabanı, istemciler ikisine de erişebildiği için ortak bir işlem yöneticisi edinmez. İş gerçekten bu çift genelinde atomik taahhüt gerektiriyorsa, koordinasyon mekanizması, katılımcılar ve kurtarma süreci varsayılmak yerine seçilmeli ve nitelendirilmelidir.
İş hazırlandıktan sonra bir katılımcının veya bağlantının kaybolduğu anı düşünün. Desteklenen dağıtık commit, kurtarma prosedürü ve insan kararı gerektiren belirsiz bir durum bırakabilir ve her bölgenin her bölünme boyunca yazılabilir kalacağına dair bir söz vermez.
Bunun yerine eşzamansız koordinasyon kabul edilebilirse, bunu açıkça söyleyin ve ara iş durumlarını ve uzlaştırma kurallarını yazın. Telafiyle yerel olarak commit edilmiş adımlardan oluşan bir zincir meşru bir tasarımdır; yalnızca başka bir ad altında tek bir atomik işlem değildir.
Yeniden denemeyi ilk kesintiden önce tasarlayın
İstemci, işlem commit edildikten sonra yanıtı kaybedebilir, bu yüzden çağıran zaman aşımını arıza sayamaz. Kalıcı bir istek kimliği koruyun ve bir değişikliği yeniden denemeden önce hizmetin sonucunu veya etkisizlik mekanizmasını kullanın, aksi hâlde yeniden deneme ikinci bir yazma olur.
Otomatik işlem geri çağırmaları da yeniden denetilebilir bir iptalden sonra birden fazla kez çalışabilir, bu da onları geri alınamaz dış etkiler için kötü bir yuva yapar. İş akışı onlar için açık ve güvenli bir protokol tanımlamadıkça bunları geri çağırmanın dışında tutun. Aynı özen para harcayan veya mesaj gönderen her şey için geçerlidir. Mükerrer bir tahsilat, mükerrer bir günlük satırından çok daha zor bir konuşmadır.
Kabul, dört senaryoyu yeniden oynatmalıdır: aynı satır için yarışan iki istemci, hizmetin yeniden denenebilir dediği bir iptal, yanıtı hiç gelmeyen bir commit ve bir bölgenin veya aralarındaki bağlantının kaybı. Commit edilmiş iş sonucunu ve çözülmemiş durumları yönlendirme tasarımının yanına kaydedin ki kimse ağı garantiyi sağlayan bileşen sanmasın.