|
|
Yayınlandı 17.03.2021 10:15:10
|
|
|
XA spesifikasyonu
XA, işlem ara yazılımı ile X/Open DTP tarafından tanımlanan veritabanı arasındaki arayüz spesifikasyonu (yani arayüz fonksiyonu) olup, işlem ara yazılımı tarafından veritabanına işlemlerin başlangıcı, sonu, bağlanma, geri alınması vb. hakkında veritabanını bildirmek için kullanılır. XA arayüz fonksiyonları veritabanı üreticileri tarafından sağlanır.
İkinci derece teslimiyet anlaşması ve üçüncü derece teslimiyet anlaşması bu fikirden türetilmiştir. İki aşamalı commitlerin aslında XA dağıtık işlemlerin uygulanmasının anahtarı olduğu söylenebilir (kesin olarak: iki aşamalı commitler esas olarak dağıtık işlemlerin atomikliğini sağlar: yani tüm düğümler ya hepsini yapar ya da hiçbir şey yapmaz)
2PC
İki aşamalı Taahhüt, bilgisayar ağları ve veritabanları alanında dağıtık sistem mimarisine dayalı tüm düğümler için işlem taahhütlerinde tutarlılığı korumak için tasarlanmış bir algoritmayı ifade eder. Çoğu zaman, iki aşamalı bir taahhüt protokolü de olarak adlandırılır. Dağıtık bir sistemde, her düğüm kendi operasyonunun başarısını veya başarısızlığını bilebilir, ancak diğer düğümlerin işlemlerinin başarısını veya başarısızlığını bilemez. Bir işlem birden fazla düğümü kapsadığında, işlemin ACID özelliklerini korumak için, tüm düğümlerin (katılımcı olarak adlandırılan) sonuçlarını kontrol etmek ve nihayetinde bu düğümlere sonuçları gerçekten göndermelerini (örneğin güncellenmiş verileri diske yazmak gibi) yönlendirmek için koordinatör olarak görev yapan bir bileşen tanıtılmalıdır. Bu nedenle, iki aşamalı gönderimin algoritma fikri şu şekilde özetlenebilir: katılımcılar operasyonun başarısını veya başarısızlığını koordinatörü bilgilendirir ve ardından koordinatör tüm katılımcıların geri bildirim bilgilerine dayanarak işlemi gönderip göndermeyeceğine veya iptal edileceğine karar verir.
Sözde iki aşama şunlardır: birinci aşama: hazırlık aşaması (oy verme aşaması) ve ikinci aşama: teslim etme aşaması (uygulama aşaması).
Hazırlık aşaması
İşlem koordinatörü (işlem yöneticisi) her katılımcıya (kaynak yöneticisi) bir Prepare mesajı gönderir ve her katılımcı ya doğrudan bir hata döndürür (örneğin başarısız bir izin doğrulaması gibi), ya da işlemi yerel olarak çalıştırır, yerel yeniden ve geri alma logları yazar, ancak commit yapmaz ve "her şey hazır, sadece doğu rüzgarı borçludur" durumuna gelir.
Hazırlık aşaması ise aşağıdaki üç adıma bölünebilir:
1) Koordinatör düğüm, tüm katılımcı düğümlere oy verip veremeyeceklerini sorar ve her katılımcı düğümden yanıt beklemeye başlar.
2) Katılımcı düğüm, sorgu başlatılana kadar tüm işlem işlemlerini yapar ve Geri Geri Alma ve Yeniden Etme bilgilerini günlüğe yazar. (Not: Başarılı olursa, her katılımcı işlem işlemini zaten gerçekleştirmiştir)
3) Her katılımcı düğüm, koordinatör düğüm tarafından başlatılan sorguya yanıt verir. Katılımcı düğümün işlem işlemi gerçekten başarıyla yürütülürse, "Kabul et" mesajı döner; Katılımcı düğümün işlem işlemi gerçekten başarısız olursa, "iptal edildi" mesajı döner.
Teslim aşaması
Koordinatör bir katılımcıdan bir arıza mesajı veya zaman aşımı alırsa, doğrudan her katılımcıya geri dönüş mesajı gönderir. Aksi takdirde, bir Commit mesajı gönderin; Katılımcılar, işlem sürecinde kullanılan tüm kilit kaynaklarını serbest bırakmak için koordinatörün talimatlarına göre commit veya geri alma işlemlerini gerçekleştirir. (Not: Kilit kaynakları son aşamada serbest bırakılmalıdır)
Sonra, başvuru aşaması süreci iki davada ayrı ayrı ele alınır.
Koordinatör düğümün tüm katılımcı düğümlerden aldığı ilgili mesaj Kabul edildiğinde:
Teslim aşaması
Koordinatör bir katılımcıdan bir arıza mesajı veya zaman aşımı alırsa, doğrudan her katılımcıya geri dönüş mesajı gönderir. Aksi takdirde, bir Commit mesajı gönderin; Katılımcılar, işlem sürecinde kullanılan tüm kilit kaynaklarını serbest bırakmak için koordinatörün talimatlarına göre commit veya geri alma işlemlerini gerçekleştirir. (Not: Kilit kaynakları son aşamada serbest bırakılmalıdır)
Sonra, başvuru aşaması süreci iki davada ayrı ayrı ele alınır.
Koordinatör düğümün tüm katılımcı düğümlerden aldığı ilgili mesaj Kabul edildiğinde:
1) Koordinatör düğüm, tüm katılımcı düğümlere "commit " talebi gönderir.
2) Katılımcı düğüm işlemi resmen tamamlar ve işlem süresi boyunca kullanılan kaynakları serbest bırakır.
3) Katılımcı düğüm, koordinatör düğüme "Bitti" mesajı gönderir.
4) Koordinatör düğüm, tüm katılımcı düğümlerden "Bitti" mesajı geri bildirimini aldıktan sonra işlemi tamamlar.
1) Koordinatör düğüm, tüm katılımcı düğümlere "geri dönüş" talebi gönderir.
2) Katılımcı düğüm, işlem süresi boyunca kullanılan kaynakları serbest bırakmak ve geri almak için önceden yazılmış Geri Alma bilgilerini kullanır.
3) Katılımcı düğüm, koordinatör düğüme "geri dönüş tamamlandı" mesajı gönderir.
4) Koordinatör düğüm, tüm katılımcı düğümlerden gelen "Geri Dönüş Tamamlandı" mesajı geri bildirimini aldıktan sonra işlemi iptal eder.
Faz 2 tazminatları atomik işlemler sağlıyor gibi görünüyor, ancak ne yazık ki aşama 2 teminatlarının hâlâ bazı dezavantajları vardır:
1. Eşzamanlı engelleme sorunu. Yürütme sırasında, tüm katılımcı düğümler işlem engellenir. Bir katılımcı kamu kaynağında yer aldığında, diğer üçüncü taraf düğümlerin kamu kaynağına erişimi engellenmelidir.
2. Tek bir başarısızlık noktası. Koordinatörün önemi nedeniyle, bir kez koordinatör başarısız olur. Katılımcılar tıkanıklığı engellemeye devam edecekler. Özellikle ikinci aşamada, koordinatör başarısız olursa, tüm katılımcılar işlem kaynaklarını kilitleme durumunda kalır ve işlem işlemlerini tamamlamaya devam edemezler. (Koordinatör telefonu kapatırsa, bir koordinatörü yeniden seçebilirsiniz ama katılımcının koordinatörün eksikliği nedeniyle engellendiği sorununu çözemez)
3. Veri tutarsızlığı. Commit işleminin ikinci aşamasında, koordinatör katılımcıya commit talebi gönderdiğinde, yerel ağ istisnası oluşur veya koordinatör commit isteği sürecinde başarısız olur; bu da sadece bazı katılımcıların commit talebini kabul etmesine neden olur. Commit talebi alındıktan sonra, bu katılımcılar commit işlemini gerçekleştirir. Ancak, commit talebi almayan diğer makineler işlem taahhüdünü gerçekleştiremez. Sonuç olarak, veri departmanının tutarlılığı tüm dağıtık sistemde gerçekleşir.
4. İkinci aşamada çözülemeyen sorunlar: Koordinatör commit mesajı gönderdikten sonra devre dışı kalır ve bu mesajı alan tek katılımcı da aşağıda kalır. Yani kolaylaştırıcı seçim anlaşması yoluyla yeni bir kolaylaştırıcı seçse bile, işlemin durumu belirsizdir ve kimse işlemin sunulup sunulmadığını bilmez.
3PC
Üç aşamalı taahhüt, üç fazlı taahhüt protokolü olarak da bilinir, iki fazlı taahhüt protokolünün (2PC) geliştirilmiş bir versiyonudur.
İki aşamalı commitlerin aksine, üç aşamalı commitlerde iki değişiklik vardır.
1. Bir zaman aşım mekanizması getirin. Aynı zamanda, hem kolaylaştırıcıda hem de katılımcılarda bir zaman aşımına sahip mekanizma uygulanır.
2. Birinci ve ikinci aşamaya hazırlık aşaması ekleyin. Bu, katılımcı tüm düğümlerin durumunun nihai commit aşamasına kadar tutarlı olmasını sağlar.
Başka bir deyişle, bir zaman aşımına sahip mekanizmanın yanı sıra, 3PC 2PC'nin hazırlık aşamasını yine ikiye böler; böylece Commit'in üç aşamasında CanCommit, PreCommit ve DoCommit'in üç aşaması vardır.
CanCommit aşaması
3PC'nin CanCommit aşaması aslında 2PC'nin hazırlık aşamasına çok benzer. Koordinatör katılımcıya bir commit talebi gönderir; katılımcı ise commit yapabilirse Evet yanıtı veya Hayır cevabı döner.
1. İşlem Sorgusu Kolaylaştırıcı, katılımcıya bir CanCommit talebi gönderir. İşlem taahhüt işlemi yapıp yapamayacağınızı sorun. Sonra katılımcılardan yanıt beklemeye başlayın.
2. Yanıt Geri Bildirimi CanCommit talebini aldıktan sonra, katılımcı işlemin sorunsuz yürütülebileceğini düşünürse evet yanıtını döndürür ve hazır duruma girer. Aksi takdirde geri bildirim Hayır
PreCommit aşaması
Kolaylaştırıcı, katılımcının yanıtına göre işlemin PreCommit işlemini ezberleyip ezberlememeye karar verir. Yanıta bağlı olarak iki olasılık var.
Kolaylaştırıcının tüm katılımcılardan aldığı geri bildirim Evet cevabı ise, işlemin ön yürütülmesi yapılır.
1. PreCommit Talep Gönder Kolaylaştırıcı, katılımcıya bir ÖnCommit isteği gönderir ve Prepare aşamasına geçer.
2. İşlem Öncesi Taahhüt Katılımcı PreCommit talebini aldıktan sonra, işlem işlemini gerçekleştirir ve geri alma ve tekrar etme bilgilerini işlem günlüğüne kaydeder.
3. Yanıt Geri Bildirimi Katılımcı işlem işlemini başarıyla yürütürse, son talimatı beklemeye başlarken ACK yanıtı döner.
1. Kesinti talebi gönderin Kolaylaştırıcı, tüm katılımcılara iptal talebi gönderir.
2. İşlemi kesin Katılımcı koordinatöründen ABORT talebini aldıktan sonra (veya zaman aşımından sonra, koordinatörün talebi alınmamış olsa da), işlemin kesintisi gerçekleştirilir.
Bu gerçek işlem taahhüdü aşaması ayrıca aşağıdaki iki duruma ayrılabilir.
Bir commit gerçekleştir
1. Bir commit talebi gönderin. Koordinasyon, katılımcı tarafından gönderilen ACK yanıtını alır, ardından ön commit durumundan commit durumuna geçer. ve tüm katılımcılara bir doCommit talebi gönderin.
2. İşlem Gönderimi DoCommit talebini aldıktan sonra katılımcı resmi işlem taahhüdü gerçekleştirir. ve işlem taahhüdü tamamlandıktan sonra tüm işlem kaynaklarını serbest bırakın.
3. Geri bildirime yanıt verin İşlem gönderildikten sonra koordinatara Ack yanıtı gönderin.
4. İşlemi tamamla Koordinatör tüm katılımcılardan ACK yanıtını aldıktan sonra işlem tamamlanır.
Koordinatör katılımcıdan ACK yanıtı almazsa (alıcıdan gelen ACK yanıtı olmayabilir veya yanıt zaman aşımına dayanmış olabilir), kesinti işlemi yürütülür.
1. Bir kesme talebi gönder Kolaylaştırıcı, tüm katılımcılara bir iptal talebi gönderir
2. İşlem Geri Dönüşü ABORT talebini aldıktan sonra, katılımcı İşlem geri alma işlemini gerçekleştirmek için Phase 2'de kaydedilen geri alma bilgilerini kullanır ve geri alma işlemi tamamlandıktan sonra tüm işlem kaynaklarını serbest bırakır.
3. Geri bildirim sonuçları Katılımcı işlem geri dönüşünü tamamladıktan sonra, koordinatörüne bir ACK mesajı gönderin
4. İşlemi kesin Koordinatör katılımcıdan ACK mesajını aldıktan sonra işlem kesilir.
2PC ile 3PC arasındaki fark
2PC ile karşılaştırıldığında, 3PC esas olarak tek noktalı başarısızlık sorununu çözer ve engellemeyi azaltır; çünkü katılımcı koordinatörden zamanında mesaj alamayınca, varsayılan olarak commit işlemi gerçekleştirir. İşlem kaynaklarını sürekli tutmak ve engelleme halinde olmak yerine. Ancak bu mekanizma aynı zamanda veri tutarlılığı sorunlarına da yol açar; çünkü koordinatör tarafından gönderilen iptal yanıtı ağ nedenleriyle katılımcı tarafından zamanında alınmaz, ardından katılımcı zaman aşımını bekledikten sonra commit işlemini gerçekleştirir. Bu, iptal komutunu alan ve geri alma işlemi gerçekleştiren diğer katılımcılarla veri tutarsızlıkları yaratır.
|
Önceki:.NET Core, Baidu PaddleOCR'i çağırarak görüntüleri ve metinleri tanırÖnümüzdeki:Markdown sözdiziminin CSV çevrimiçi dönüşümü
|
