Eric Brewer'in CAP teoremini pratik bir zihinsel model olarak öğrenin: tutarlılık, kullanılabilirlik ve ağ bölünmelerinin dağıtık sistem kararlarını nasıl şekillendirdiğini.
Aynı veriyi birden fazla makinede sakladığınızda hız ve hata toleransı kazanırsınız—ama aynı zamanda yeni bir sorun da edinirsiniz: anlaşmazlık. İki sunucu farklı güncellemeler alabilir, mesajlar geç veya hiç gelmeyebilir, ve kullanıcılar hangi replika ile karşılaşırsa farklı cevaplar görebilir. CAP popüler oldu çünkü bu dağınık gerçeği abartmadan konuşmanın net bir yolunu sunuyor.
Eric Brewer, bilgisayar bilimci ve Inktomi'nin kurucularından biri, 2000 yılında başarısızlık altındaki çoğaltılmış sistemler hakkında pratik bir ifadeyle çekirdek fikri sundu. Hızla yayıldı çünkü üretimde takımların zaten yaşadığıyla örtüşüyordu: dağıtık sistemler sadece kapanarak başarısız olmaz; bölünerek başarısız olurlar.
CAP en faydalı olduğunda işler ters gittiğinde—özellikle ağ düzgün davranmadığında—ortaya çıkar. Sağlıklı bir günde birçok sistem hem yeterince tutarlı hem de yeterince kullanılabilir görünebilir. Gerçek sınama, makinelerin güvenilir şekilde iletişim kuramadığı ve sistem bölündüğünde okuma/yazma ile ne yapacağınıza karar vermeniz gerektiği zamandır.
Bu çerçeve CAP'in neden başvurulan bir zihinsel model olduğunu gösterir: en iyi uygulamalardan bahsetmez; somut bir soru sorar—bölünme sırasında neyi feda edeceğiz?
Bu makalenin sonunda şunları yapabilmelisiniz:
CAP, “dağıtık zor” lafını savunulabilir bir karara dönüştürdüğü için kalıcıdır.
Bir dağıtık sistem, basitçe söylemek gerekirse birbirine benzemeye çalışan çok sayıda bilgisayartır. Farklı raflarda, bölgelerde veya bulut zonlarında birkaç sunucunuz olabilir, ama kullanıcı için bu “uygulama” veya “veritabanı”dır.
Gerçek dünya ölçeğinde paylaşılan sistemi çalıştırmak için genellikle replikasyon yaparız: aynı verinin birden fazla kopyasını farklı makinelerde tutarız.
Replikasyon üç pratik sebepten popülerdir:
Şu ana kadar replikasyon mantıklı bir kazanım gibi görünüyor. Ama sorun şudur: replikasyon yeni bir iş çıkarır: tüm kopyaları uyumlu tutma.
Eğer her replikası her zaman diğerleriyle anında konuşabilseydi, güncellemeleri koordine edip aynı durumda kalabilirlerdi. Ama gerçek ağlar kusursuz değildir. Mesajlar gecikebilir, düşebilir veya hatalı yönlendirilebilir.
İletişim sağlıklı olduğunda replikalar genellikle güncellemeleri değiş-tokuş eder ve aynı durumda birleştirir. Ancak iletişim koptuğunda (geçici olsa bile) gerçeğin iki geçerli görünümlü versiyonuyla karşılaşabilirsiniz.
Örneğin bir kullanıcı gönderi adresini değiştirir. Replika A güncellemeyi alır, replik B almaz. Şimdi sistem basit bir soruyu cevaplamak zorunda: mevcut adres nedir?
Bu şu farktır:
CAP düşüncesi tam da burada başlar: replikasyon var olduğunda, iletişim kopması altındaki anlaşmazlık bir kenar durumu değil—temel tasarım sorunudur.
CAP, sistem birden fazla makineye yayıldığında kullanıcıların gerçekten ne hissettiğini modelleyen bir zihinsel çerçevedir. “İyi” veya “kötü” sistemleri tanımlamaz—sadece yönetmeniz gereken gerilimi gösterir.
Tutarlılık anlaşma hakkındadır. Bir şeyi güncellerseniz, sonraki okuma (herhangi bir yerden) o güncellemeyi yansıtacak mı?
Kullanıcı açısından bu, “Az önce değiştirdim ve herkes aynı yeni değeri görüyor” ile “bazıları eski değeri bir süre daha görüyor” arasındaki farktır.
Kullanılabilirlik, sistemin isteklere—okuma ve yazmalara—başarılı bir sonuçla yanıt vermesi demektir. “En hızlı” değil, “size hizmet vermeyi reddetmiyor” anlamındadır.
Sorun sırasında (bir sunucu kapandığında, ağda kesinti olduğunda) kullanılabilir bir sistem, cevap vermeye devam eder; hatta biraz eski olabilir ama yanıt verir.
Bir partition (bölünme), ağın bölünmesidir: makineler çalışıyor olabilir ama aralarındaki mesajlar ulaşamıyordur (veya işe yaramayacak kadar geç geliyordur). Dağıtık sistemlerde bunu imkansız sayamazsınız—bölünme olduğunda ne olacağını tanımlamanız gerekir.
Aynı ürünü satan ve “1 stok” paylaşan iki mağaza düşünün. Müşteri Shop A'da son ürünü alır, Shop A stok = 0 yazar. Aynı anda ağ bölünmesi Shop B'nin bunu duymasını engeller.
Eğer Shop B kullanılabilirliği korursa, bölünme sırasında artık olmayan bir ürünü satabilir (satışı kabul eder). Eğer Shop B tutarlılığı uygularsa, en güncel stoğu doğrulayana kadar satışı reddedebilir (bölünme sırasında hizmeti keser).
“Bölünme” sadece “internet kapandı” demek değildir. Sisteminizin bazı parçalarının hala çalışıyor olmasına rağmen güvenilir şekilde konuşamadığı her durumdur.
Replikalı bir sistemde düğümler sürekli mesaj değiş tokuşu yapar: yazmalar, onaylar, heartbeat'ler, lider seçimleri, okuma istekleri. Bir bölünme, bu mesajlar gelmeyi kestiğinde (veya çok geç geldiğinde) ortaya çıkar ve gerçeklik hakkında anlaşmazlık yaratır: "Yazı gerçekleşti mi?" "Kim lider?" "B düğümü canlı mı?"
İletişim şu karışık şekillerde başarısız olabilir:
Önemli nokta: bölünmeler genellikle bozulmadur, temiz bir açık-kapalı durum değil. Uygulama açısından “yeterince yavaş” olmak “kapalı” olmaktan ayırt edilemeyebilir.
Daha fazla makine, daha fazla ağ, daha fazla bölge ve daha fazla hareketli parça ekledikçe iletişimin bozulabileceği daha çok fırsat ortaya çıkar. Bireysel bileşenlerin güvenilir olması, genel sistemin daha fazla bağımlılık ve çapraz düğüm koordinasyonu olduğu için yine de arıza yaşamasını engellemez.
Sisteminiz yeterince uzun süre çalışır ve yeterince altyapıya yayılırsa, bölünmeler olacaktır—bunu kabul etmek yeterlidir.
Bölüm toleransı, sisteminizin bir bölünme sırasında çalışmaya devam edecek şekilde tasarlandığı anlamına gelir—replikalar anlaşamaz veya diğer tarafın ne gördüğünü onaylayamaz olsa bile. Bu bir tercihi zorlar: ya istekleri kabul etmeye devam edip tutarsızlık riskini almak ya da bazı istekleri reddedip/takip eden süre boyunca tutarlılığı korumak.
Replikasyon olduğunda bölünme sadece bir iletişim kopmasıdır: sisteminizin iki parçası bir süre güvenilir şekilde konuşamaz. Replikalar hâlâ çalışıyor, kullanıcılar hâlâ tıklıyor ve hizmet istek alıyor—ama replikalar en son gerçeğe uzlaşamaz.
CAP gerilimi bir cümlede: bölünme sırasında Tutarlılık (C) veya Kullanılabilirlik (A) önceliklendirilmelidir. Aynı anda her ikisini tam olarak elde edemezsiniz.
"Doğru olmaktansa yanıt vermeyeceğim" dersiniz. Sistem bir isteğin tüm replikaları senkronize tutacağını doğrulayamazsa işlemi başarısız kılmalı veya beklemelidir.
Pratik etkisi: bazı kullanıcılar özellikle veri değiştiren işlemler için hatalar, zaman aşımı veya "tekrar deneyin" mesajları görür. Çifte ücretlendirme riskini almak yerine ödemeyi reddetmeyi tercih etmek ya da fazla rezervasyonu engellemek gibi durumlarda bu yaygındır.
"Engellemek yerine yanıtlamayı tercih ederim" dersiniz. Bölünmenin her iki tarafı da koordine edemese bile istekleri kabul etmeye devam eder.
Pratik etkisi: kullanıcılar başarılı yanıtlar alır, fakat okudukları veriler bayat olabilir ve eşzamanlı güncellemeler çakışabilir. Sonrasında uzlaştırmaya güvenirsiniz (birleştirme kuralları, son yazı kazanır, manuel kontrol vs.).
Bu her zaman tek bir küresel ayar değildir. Birçok ürün strateji karıştırır:
Ana an, işlem başına neyin daha kötü olduğunu (kullanıcıyı şimdi engellemek mi yoksa daha sonra çakışmayı düzeltmek mi) seçmektir.
"İkisini seç" sloganı akılda kalıcıdır, ama insanları sık sık yanıltır; CAP'i üç özellikten ikisini sonsuza kadar saklayabileceğiniz bir menü gibi düşünmeye iter. CAP, ağ işbirliği yapmayı bıraktığında ne olduğuyla ilgilidir: bir bölünme (veya benzeri bir durum) meydana geldiğinde, dağıtık sistem her istek için tutarlı cevaplar verip veremeyeceği ile her isteğe yanıt verip veremeyeceği arasında seçim yapmak zorundadır.
Gerçek dağıtık sistemlerde bölünmeleri kapatabileceğiniz bir ayar yoktur. Sistem makineler, raflar, zonlar veya bölgeler arasında yayıldıysa mesajlar gecikebilir, düşebilir veya garip şekilde yönlendirilebilir. Bu yazılım açısından bir bölünmedir: düğümler olan biteni güvenilir şekilde koordine edemez.
Fiziksel ağ mükemmel olsa bile, GC duraklamaları, gürültülü komşular, DNS aksaklıkları ve hatalı yük dengeleyiciler aynı etkiyi yaratır.
Uygulamalar bölünmeyi net bir ikili olay olarak yaşamazlar. Bunun yerine gecikme sıçramaları ve zaman aşımı yaşarlar. Bir istek 200 ms sonra zaman aşımına uğruyorsa, paketin 201 ms'de ulaşmış olmasıyla hiç ulaşmamış olması arasında uygulama için fark yoktur: uygulama sonraki adımı seçmelidir.
Gerçek sistemler genellikle işletim koşullarına ve yapılandırmaya bağlı olarak çoğunlukla tutarlı veya çoğunlukla kullanılabilir görünür. Zaman aşımları, retry politikaları, quorum boyutları ve "kendi yazını okuma" seçenekleri davranışı kaydırabilir.
Normal koşullarda bir veritabanı güçlü tutarlı görünebilir; stres veya bölge arası aksaklıklarda ise istekleri reddetmeye (tutarlılığı tercih) veya daha eski verileri döndürmeye (kullanılabilirliği tercih) başlayabilir.
CAP, ürünleri etiketlemekten çok, anlaşmazlık olduğunda—özellikle bu anlaşmazlık basit yavaşlıktan kaynaklandığında—verdiğiniz takası anlamaktır.
CAP tartışmaları tutarlılığı iki uçluymuş gibi gösterir: ya “mükemmel” ya da “her şey serbest”. Gerçek sistemler, replikalar anlaşamazken veya ağ bağlantısı koptuğunda farklı kullanıcı deneyimleri sunan birkaç garanti seçeneği sunar.
Güçlü tutarlılık (genellikle “linearizable” olarak anılır) demek, bir yazı onaylandığında, daha sonraki her okumanın—hangi replikaya giderse gitsin—o yazıyı dönmesi demektir.
Bedeli: bir bölünme veya replikaların azınlığı ulaşılamaz olduğunda sistem okuma/yazmaları geciktirebilir veya reddedebilir. Kullanıcılar bunu zaman aşımı, "tekrar deneyin" veya geçici salt-okunur davranış olarak görür.
Nihai tutarlılık şunu vaat eder: eğer yeni güncellemeler durursa, tüm replikalar zamanla uzlaşır. İki kullanıcının tam şu anda aynı şeyi görmesini garanti etmez.
Kullanıcıların fark edebilecekleri: az önce güncellenen bir profil fotoğrafının "geri dönmesi", sayaçların geride kalması veya yeni gönderilen bir mesajın diğer cihazda kısa süre görünmemesi.
Tam güçlü tutarlılık talep etmeden daha iyi bir deneyim sağlayabilirsiniz:
Bu garantiler insanların düşündüğü şekilde haritalanır ("değişikliklerim kaybolmasın") ve kısmi arızalarda sürdürülmesi genellikle daha kolaydır.
Jargondan çok kullanıcıya verdiğiniz söze göre başlayın:
Tutarlılık bir ürün kararıdır: kullanıcı için "yanlış" ne demek olduğunu tanımlayın, sonra o yanlışı önlemek için en zayıf garantiyi seçin.
CAP'teki kullanılabilirlik övünme metriği değildir (“beş dokuz”). Bu, ağın emin olamadığı durumda kullanıcılara verdiğiniz sözdür.
Replikalar uzlaşamadığında genellikle iki seçenek vardır:
Kullanıcı bunu "uygulama çalışıyor" ile "uygulama doğru" arasında hisseder. Hiçbiri her zaman üstün değildir; nereyi kabul edilemez hata saydığınız ürüne bağlıdır. Biraz eski bir sosyal akış can sıkıcıdır; bayat bir hesap bakiyesi zararlı olabilir.
Belirsizlik anında iki yaygın davranış:
Bu teknik bir karardan çok politika kararıdır. Ürün, neyi göstermenin kabul edilebilir olduğunu ve neyin asla tahmin edilemeyeceğini tanımlamalıdır.
Kullanılabilirlik nadiren her şey veya hiçbir şeydir. Bir bölünme sırasında kısmi kullanılabilirlik görebilirsiniz: bazı bölgeler, ağlar veya kullanıcı grupları başarılı olurken diğerleri başarısız olur. Bu bilinçli bir tasarım (lokal replikadan hizmet vermeye devam etmek) veya kazara (yönlendirme dengesizlikleri, düzensiz quorum erişimi) olabilir.
Pratik bir orta yol degrade modudur: riskli işlemleri kısıtlayarak güvenli eylemleri sunmaya devam edin. Örneğin gözatma ve aramaya izin verin, ama geçici olarak “para transferi”, “parola değişikliği” gibi doğruluk gerektiren işlemleri devre dışı bırakın.
CAP soyut geliyor olabilir; onu ağ bölünmesi sırasında kullanıcıların ne deneyimleyeceğine göre haritalayın: sistemin cevap vermeye devam etmesini mi yoksa çakışmayı önlemek için durmasını mı tercih edersiniz?
İki veri merkezi aynı anda sipariş kabul ettiğinde...
Eğer checkout akışını kullanılabilir tutarsanız, her iki taraf da "son ürünü" satabilir ve fazla satış yaşanır. Düşük maliyetli ürünlerde kabul edilebilir olabilir, ama sınırlı ürünlerde can sıkıcıdır.
Tutarlılığı önceleyen davranışta, stok global olarak doğrulanamayınca yeni siparişleri engelleyebilirsiniz. Kullanıcı "sonra deneyin" görür, ama teslim edilemeyecek bir şeyi satmamış olursunuz.
Para klasik olarak "yanlış olmak pahalıdır" alanıdır. Bölünme sırasında iki replik ayrı ayrı çekim kabul ederse hesap negatif olabilir.
Sistemler genellikle kritik yazmalarda tutarlılığı tercih eder: en güncel bakiye doğrulanamıyorsa işlemi reddedin veya geciktirin. Bu, kullanılabilirlik kaybı pahasına doğruluk, denetlenebilirlik ve güven sağlar.
Sohbet ve sosyal akışlarda kullanıcılar genellikle küçük tutarsızlıklara tolerans gösterir: mesaj birkaç saniye gecikebilir, beğeni sayısı tutarsız olabilir veya görünüm metriği biraz sonra güncellenebilir.
Burada kullanılabilirliğe dayanmak iyi bir ürün tercihi olabilir—ancak hangi öğelerin "nihai olarak doğru" olduğunu açıkça belirtmeli ve güncellemeleri düzgün bir şekilde birleştirebilmelisiniz.
Doğru CAP seçimi, yanlış olmanın maliyetine bağlıdır: geri iadeler, yasal maruz kalma, kullanıcı güveni veya operasyonel kaos. Geçici bayatlığa nerede izin verebileceğinizi ve nerede kapatmanız gerektiğini belirleyin.
Bölünme sırasında ne yapacağınıza karar verdikten sonra bu kararı gerçeğe dönüştürecek mekanizmalara ihtiyacınız var. Bu desenler veritabanlarında, mesaj sistemlerinde ve API'lerde ortaya çıkar—ürün "CAP"i açıkça söylemese bile.
Quorum basitçe "replikaların çoğu anlaştığında" demektir. 5 kopyanız varsa çoğunluk 3'tür.
Okuma ve/veya yazma için çoğunluğu gerektirerek bayat veya çakışan veri döndürme olasılığını azaltırsınız. Örneğin yazı 3 replikadan onay almalıdır derseniz, iki izole grubun farklı "gerçek"ler kabul etmesi daha zorlaşır.
Takas: hız ve erişim. Çoğunluğa ulaşamazsanız (bölünme veya arızalar yüzünden) sistem işlemi reddedebilir—tutarlılığı kullanılabilirliğe tercih etmiş olursunuz.
Birçok kullanılabilirlik sorunu sert arızalar değil, yavaş yanıtlar yüzündendir. Kısa bir zaman aşımı sistemi çevik gösterir, ama yavaş başarıları başarısız sayma riskini artırır.
Yeniden denemeler geçici kusurlardan kurtarabilir; ama agresif yeniden denemeler zaten zorlanan bir hizmeti daha da bunaltabilir. Backoff (yeniden denemeler arasında biraz beklemek) ve jitter (rastgelelik) yeniden denemelerin trafik spike'ına dönüşmesini engeller.
Anahtar, bu ayarları verdiğiniz söze uyacak şekilde hizalamaktır: “her zaman yanıt ver” genellikle daha fazla yeniden deneme ve yedek yol anlamına gelir; “asla yalan söyleme” daha sıkı limitler ve net hatalar demektir.
Bölünme sırasında kullanılabilirliği seçerseniz replikalar farklı güncellemeleri kabul eder ve sonrasında uzlaştırma gerekir. Yaygın yaklaşımlar:
Yeniden denemeler çoğaltmalara yol açabilir: kartın iki kez çekilmesi veya aynı siparişin iki kez gönderilmesi. İdempotentlik bunu önler.
Yaygın desen, her istekle gönderilen bir idempotentlik anahtarıdır (istek ID'si). Sunucu ilk sonucu saklar ve tekrar eden isteklerde aynı sonucu döndürür—böylece yeniden denemeler kullanılabilirliği artırırken veriyi bozmaz.
Çoğu ekip CAP duruşunu beyaz tahtada “seçer”—sonra üretimde sistemin stres altındayken farklı davrandığını keşfeder. Doğrulama, CAP takaslarının görünür hale geldiği koşulları kasıtlı olarak yaratmak ve sisteminizin tasarladığınız şekilde tepki verdiğini kontrol etmektir.
Gerçek bir kablo kesimine gerek yok. Bölünmeleri taklit etmek için kontrollü hata enjeksiyonu kullanın:
Amaç somut sorulara cevap bulmaktır: Yazmalar reddediliyor mu yoksa kabul ediliyor mu? Okumalar bayat mı? Sistem otomatik olarak toparlanıyor mu ve uzlaşma ne kadar sürüyor?
Eğer bu davranışları erken doğrulamak istiyorsanız (hizmetleri birbirine bağlamak için haftalar harcamadan önce), gerçekçi bir prototip hızla kurmak yardımcı olur. Örneğin, Koder.ai kullanan takımlar genellikle küçük bir servis (çoğunlukla Go backend, PostgreSQL ve bir React UI) üreterek retry, idempotentlik anahtarları ve “degrade mode” akışlarını sandbox ortamında test ederler.
Geleneksel uptime kontrolleri “yanlış ama erişilebilir” davranışı yakalamaz. Şunları izleyin:
Operatörlerin bir bölünme olduğunda önceden belirlenmiş eylemlere ihtiyacı vardır: ne zaman yazıları donduracaksınız, ne zaman fail over yapacaksınız, ne zaman özellikleri azaltacaksınız ve yeniden birleştirmenin güvenliğini nasıl doğrulayacaksınız.
Ayrıca kullanıcıya yönelik mesajı planlayın. Tutarlılığı seçtiyseniz mesaj "Güncellemenizi şu an doğrulayamıyoruz—lütfen tekrar deneyin" olabilir. Kullanılabilirliği seçtiyseniz açık olun: "Güncellemeniz birkaç dakika içinde herkese yansıyabilir." Net ifadeler destek yükünü azaltır ve güveni korur.
Sistem kararı alırken CAP, teorik bir tartışmadan ziyade “bölünme olursa ne bozulur?” denetimi olarak en yararlıdır. Bir veritabanı özelliği, önbellekleme stratejisi veya replikasyon modu seçmeden önce bu hızlı kontrol listesini kullanın.
Sırayla şu soruları sorun:
Bir ağ bölünmesi olursa önce bunlardan hangisini koruyacağınızı seçiyorsunuz.
"Biz AP sistemiyiz" gibi tek bir küresel ayardan kaçının. Bunun yerine şunları uç nokta başına belirleyin:
Örnek: bir bölünme sırasında payments için yazmaları engelleyip (tutarlılığı tercih) product_catalog okumalarını önbellekten sunabilirsiniz.
Neyi tolere edebileceğinizi örneklerle yazın:
Eğer tutarsızlığı açık örneklerle anlatamazsanız, test etmekte ve olayları açıklamakta zorlanırsınız.
İzlemesi faydalı bir sonraki konular: konsensüs, tutarlılık modelleri ve SLO'lar/hata bütçeleri.
CAP, iletişim hatası altındaki çoğaltılmış sistemler için bir zihinsel modeldir. Ağ yavaşladığında, paketler kaybolduğunda veya sistem parçalandığında en faydalıdır; çünkü bu durumlarda replikalar güvenilir şekilde uzlaşamaz ve şu ikiden birini seçmeniz gerekir:
Bu model, “dağıtık zor” lafını somut bir ürün ve mühendislik kararına dönüştürür.
Gerçek bir CAP senaryosu için her ikisi de gereklidir:
Eğer sistem tek bir düğümse veya durum çoğaltılmıyorsa, CAP takasları merkezi bir mesele değildir.
Bir partition (bölünme), sistem parçalarının güvenilir şekilde ya da gerekli süre içinde iletişim kuramadığı herhangi bir durumdur—her makine hâlâ çalışıyor olsa bile.
Pratikte “bölünme” şu şekilde görünür:
Uygulama açısından “çok yavaş” olmak çoğu zaman “çökmüş” olmakla aynıdır.
Tutarlılık (C), herhangi bir yerden yapılan okumanın en son onaylanmış yazıyı geri döndürmesi demektir. Kullanıcı bunu “değiştirdim ve herkes aynı şeyi görüyor” şeklinde hisseder.
Kullanılabilirlik (A), her isteğin başarılı bir yanıt alması anlamına gelir (mutlaka en güncel olmayabilir). Kullanıcı bunu “uygulama çalışmaya devam ediyor” şeklinde deneyimler—ancak sonuçlar bayat olabilir.
Bir bölünme sırasında genelde her iki garantiyi aynı anda tüm işlemler için sağlayamazsınız.
Çünkü dağıtık sistemlerde bölünmeler opsiyonel değildir. Eğer durum çoğaltılıyorsa, düğümler koordine olamadığında nasıl davranılacağını tanımlamanız gerekir.
Dolayısıyla “bölünmeleri yok sayayım” diye bir yol yoktur: çoğaltma yaptığınız sürece, iletişim bozulduğunda sistem ya bazı işlemleri reddetmeli/saklamalı (tutarlılığı tercih ederek) ya da en iyi çabayı gösterip sonuçları daha sonra uzlaştırmalıdır (kullanılabilirliği tercih ederek).
Tutarlılığı tercih ederseniz genellikle şunları yaparsınız:
Bu yaklaşım para transferi, envanter rezervasyonu ve izin değişiklikleri gibi yanlış olmak istemediğiniz alanlarda yaygındır.
Kullanılabilirliği tercih ederseniz genellikle şunları yaparsınız:
Kullanıcı sert hatalar daha az görür, ama veriler bayat olabilir veya idempotentlik yoksa tekrar eden etkiler ortaya çıkabilir.
Evet. Genelde farklı uç noktalar ve veri tipleri için farklı stratejiler benimsenir. Yaygın karışık yaklaşımlar:
Bu, tek bir “biz AP/CP’yiz” etiketinden kaçınmaya yardımcı olur.
Altında yatan seçenekler şunlardır:
Gerçek koşullarda farklı davranışları görmek için kasıtlı olarak parçalanma koşulları yaratın:
Ayrıca bir bölünme olduğunda ne zaman yazıları donduracağınızı, ne zaman failover yapacağınızı ve kullanıcıya ne söyleyeceğinizi içeren çalışma kitapçıkları hazırlayın.
Kabul edilebilir yanlışlığı önleyecek en zayıf garantiyi seçin.
