Kuru mallar: Dağıtılmış işlem dengeleme modu + Mq / TCC
Tazminat modu
MQ (işlem mesajı):
Örneğin, Bob Smith'e para transfer ederse, önce mesajı göndermeli miyiz yoksa kesintiyi önce mi yapmalıyız?
Görünüşe göre sorunlar olabilir. Önce bir mesaj gönderirseniz ve kesinti işlemi başarısız olursa, Smith'in hesabında fazladan bir miktar para olacaktır. Tersine, eğer kesinti önce yapılırsa ve sonra mesaj gönderilirse, kesintinin başarılı olması ancak mesajın gönderilmemesi ve Smith parayı alamaması mümkündür. Yukarıda belirtilen istisna yakalama ve geri alma yöntemlerine ek olarak, başka fikirler var mı?
Alibaba'nın RocketMQ ara yazılımını, tasarım ve uygulama fikirlerini analiz etmek için örnek olarak alalım.
RocketMQ, ilk aşamada Hazırlanmış bir mesaj gönderdiğinde, mesajın adresini alır, ikinci aşama yerel işleri yürütür ve üçüncü aşama, mesaja erişmek ve durumu değiştirmek için ilk aşamada elde edilen adresi kullanır. Dikkatli okuyucular sorunu tekrar bulabilir .. Ya onay mesajı gönderilemezse? RocketMQ, mesaj kümesindeki işlem mesajlarını periyodik olarak tarayacaktır Hazırlanmış bir mesaj bulduğunda, mesaj gönderene Bob'un parasının azalmış olup olmadığını teyit edecektir. Azaltılırsa geri mi dönmeli yoksa onay mesajları göndermeye devam mı etmelidir? RocketMQ, gönderen tarafından belirlenen stratejiye göre geri alınmaya veya onay mesajlarını göndermeye devam etmeye karar verecektir. Bu, mesaj gönderiminin ve yerel işlemin aynı anda başarılı olmasını veya başarısız olmasını sağlar. Aşağıda gösterildiği gibi:
Özet: Yazarın anlayışına göre, hemen hemen tüm tanınmış e-ticaret platformları ve İnternet şirketleri "nihai tutarlılık" elde etmek için benzer tasarım fikirlerini benimser. Bu yöntem, çok çeşitli iş senaryoları için uygundur ve nispeten güvenilirdir. Ancak bu yöntemin teknik olarak gerçekleştirilmesi daha zordur. Şu anda, ana akım açık kaynaklı MQ (ActiveMQ, RabbitMQ, Kafka) işlem mesajlarını desteklemiyor, bu nedenle ikincil geliştirme veya yeni tekerlekler gerekiyor. Ne yazık ki, RocketMQ'nun işlem mesajı kısmının kodu açık kaynak değildir, bu yüzden onu kendiniz uygulamanız gerekir.
MQ (işlem dışı mesaj):
Normal koşullar altında, işlemsel olmayan mesaj destekli MQ ürünlerini kullanırken, iş operasyonlarını ve MQ işlemlerini yerel bir işlem etki alanında yönetmemiz zordur. Daha genel bir şekilde açıklamak gerekirse, yukarıda bahsedilen "bankalar arası transferi" örnek olarak alın.MQ teslimat mesajı işleminin kesinti tamamlandıktan sonra başarılı olacağını garanti etmemiz bizim için zor. Böyle bir tutarlılığı garanti etmek zor görünüyor.
Önce mesaj üreticisinin sonundan itibaren analiz edin, lütfen sözde koda bakın:
Yukarıdaki kod ve yorumlara göre olası durumları analiz edelim:
1. Veritabanı başarıyla işletiliyor ve MQ'ya mesaj teslimi de başarılı, herkes mutlu 2. Veritabanı çalıştırılamadı, MQ'ya hiçbir mesaj teslim edilmeyecek 3. Veritabanının çalışması başarılı, ancak MQ'ya mesaj teslimi başarısız oldu ve bir istisna atıldı. Henüz gerçekleştirilen veritabanını güncelleme işlemi geri alınacakYukarıda analiz edilen birkaç durumdan, sorunun büyük olmadığı anlaşılıyor. O halde tüketicilerin karşılaştığı sorunları analiz edelim:
1. Mesaj listelendikten sonra, tüketiciye karşılık gelen iş operasyonunun başarıyla yürütülmesi gerekir. Hizmetin yürütülmesi başarısız olursa, mesaj geçersiz kılınamaz veya kaybolamaz. Mesajların iş operasyonlarıyla tutarlı olmasını sağlamalı 2. Mesajların tekrar tekrar tüketilmesinden kaçınmaya çalışın. Tekrarlanan tüketim, iş sonuçlarını etkilememelidirMesajların iş operasyonlarıyla tutarlı olmasını ve kaybolmamasını nasıl sağlayabilirim?
Ana akım MQ ürünlerinin tümü mesajların kalıcı olması işlevine sahiptir. Tüketici çalışmazsa veya tüketim başarısız olursa, yeniden deneme mekanizması uygulanabilir (bazı MQ'lar yeniden deneme sayısını özelleştirebilir).
Mesajların tekrar tekrar kullanılmasının neden olduğu sorunlar nasıl önlenir?
1. Tüketicilerin işletmeyi aramaları için hizmet arayüzünün idempotensini sağlayın 2. Tüketim durumunu, yargılanması kolay olan tüketim günlüğü veya benzer durum tablosu aracılığıyla kaydedin (bu özelliği sağlamak için MQ ürünlerine güvenmek yerine bunu işletmede kendi başınıza uygulamanız önerilir)Özet: Bu yöntem daha yaygındır, performans ve verim, ilişkisel veritabanı mesaj tablolarının kullanımından daha iyidir. MQ'nun kendisi ve işletmesi yüksek kullanılabilirliğe sahipse, teorik olarak çoğu iş senaryosunu karşılayabilir. Ancak, yeterli test yapılmadan doğrudan ticaret sektöründe kullanılması tavsiye edilmez.
Diğer tazminat yöntemleri
Alipay işlem arayüzünü yapanlar, genellikle Alipay'in geri arama sayfasındaki ve arayüzündeki parametrelerin şifresini çözdüğümüzü ve ardından siparişi başarılı ödemeye güncellemek için sistemdeki işlem durumunu güncellemekle ilgili servisi aradığımızı bilirler. Aynı zamanda Alipay, geri arama isteğini yalnızca geri arama sayfamızda "başarılı" kelimesi çıktığında veya işletmenin başarılı bir şekilde işlendiğini gösteren ilgili durum kodu çıktığında durduracaktır. Aksi takdirde, Alipay, başarılı tanımlama çıktısı alınana kadar belirli bir süre sonra müşteriye bir geri arama isteği başlatır.
Aslında bu, bazı MQ yeniden deneme telafi mekanizmalarına benzer çok tipik bir tazminat örneğidir.
Genel olarak olgunlaşmış bir sistemde, üst düzey hizmetlerin ve arabirimlerin genel kullanılabilirliği genellikle çok yüksektir. Bazı hizmetler, geçici ağ arızalarından veya çağrı zaman aşımlarından kaynaklanıyorsa, bu yeniden deneme mekanizması aslında çok etkilidir.
Elbette, daha uç bir senaryo düşünüldüğünde, sistemin kendisinde bir hata varsa veya program mantığında bir sorun varsa, 1W kez yeniden denemek yardımcı olmayacaktır. "Açıkçası ödeme yapıldı ama ödemenin yapılmadığını ve gönderinin gönderilmeyeceğini gösteriyor" gibi bir trajedi olmaz mıydı?
Aslında, alım satım sistemini daha güvenilir hale getirmek için, genellikle işlemler gibi üst düzey hizmet kodlarına ayrıntılı günlük kayıtları ekleriz.Sistem içinde ölümcül bir istisna meydana geldiğinde, e-posta bildirimleri olacaktır. Aynı zamanda, bu tür günlükleri taramak ve analiz etmek, bu özel durumu kontrol etmek, program aracılığıyla telafi etmeye çalışmak ve ilgili personeli e-posta ile bilgilendirmek için arka planda düzenli görevler olacaktır.
Bazı özel durumlarda, son engel olan "suni tazminat" olacaktır.
Özetle, kendi dağıtılmış işlemimizi tasarlıyoruz:
//Durum 1. Mesaj sağlayıcı, gönderilen mesajda herhangi bir anormallik olmamasını sağlar, aksi takdirde veritabanının geri alma işlemi. 2. Tüketicinin kalıcı bir depolama ve yeniden deneme mekanizması olmasına rağmen, en iyisi mesajı java yerel kuyruğuna eklemek olacaktır. 3. Tüketici, temel işi gerçekleştirmek için yerel kuyruktaki mesajları sorgulayan ve izleyen tek bir hizmettir. 4. Günlüğü kaydedin ve kural dışı durumdan sonra yerel kuyruğa yeniden yerleştirin. Tazminat sayısını belirli bir işletmeye göre ayarlayın (hatalar nedeniyle sınırsız tazminattan kaçınmak için). 5. İş ihtiyaçlarına göre, tamamlanmamış iş mesajlarını manuel olarak telafi etmek için bir yönetim sayfası geliştirmenin gerekli olup olmadığı. Özet: Bu şekilde, sağlayıcı ve tüketicinin iki hizmeti "veri tutarlılığı" garanti edilebilir.özet
Yazar ayrıca itiraz edilen çeşitli planların tasarım fikirlerini, avantajlarını, dezavantajlarını vb. Özetledi Okuyucuların zaten belli bir anlayışa sahip olduğuna inanıyorum. Aslında, dağıtılmış sistemlerin işlem tutarlılığı başlı başına teknik bir sorundur ve tüm senaryoların üstesinden gelebilecek basit ve mükemmel bir çözüm yoktur. Özellikle, kullanıcılar farklı iş senaryolarına göre yine de seçimler yapmak zorundadır.
/ ************************************************** ************************************************** *********** /
TCC modu:
TCC işlem mekanizması
1. TCC mekanizması
Bir bakışta, TCC'nin üç İngilizce kelimenin kısaltması olması gerektiğini biliyorsun. Evet, TCC, Deneme, Onayla ve İptal işlemlerinin üç işlemine karşılık gelir.Bu üç işlemin ticari anlamları aşağıdaki gibidir: Dene: İş kaynaklarını ayır Onayla: İş işleminin yürütülmesini onaylayın İptal: İş işleminin yürütülmesini iptal edin İlişkisel veritabanı işlemini biraz karşılaştırın Üç işlem: DML, Commit ve Rollback, bunların TCC'ye benzer olduğunu göreceksiniz. Uygulamalar arası bir iş operasyonunda, Deneme işlemi, daha sonraki onay için temel oluşturmak üzere ilk olarak iş kaynaklarını birden çok uygulamada ayırmak ve kilitlemektir Benzer şekilde, DML işlemlerinin veritabanı kaydı satırlarını kilitlemesi ve veritabanı kaynaklarını tutması gerekir; Onaylama işlemi, Try işlemine dahil olan tüm uygulamaların başarılı olduktan sonra, Commit'e benzer şekilde ayrılmış iş kaynaklarını kullanarak onaylamak içindir; İptal, Try işleminde yer alan tüm uygulamaların tümü başarılı olmadığında ise, başarılı uygulamaları değiştirmeniz gerekir. İptal (ör. Geri alma geri alma). Onayla ve İptal işlemleri bir çift ters iş işlemidir.
Kısacası, uygulamayı bir kaynak yöneticisi olarak düşünürseniz, TCC, uygulama katmanının 2PC'sidir (2 Fazlı İşlem).
Ayrıntılı olarak, her bir işlem için TTK'nın yapması gerekenler şu şekildedir: Deneyin: İşi yürütmeye çalışın. Tüm iş kontrollerini tamamlayın (tutarlılık) ve gerekli iş kaynaklarını ayırın (yarı izolasyon) Onaylayın: İşin yürütülmesini onaylayın. İşi herhangi bir iş kontrolü yapmadan gerçekten yürütün ve yalnızca Deneme aşamasında ayrılan iş kaynaklarını kullanın. İptal: İşin yürütülmesini iptal edin ve Deneme aşamasında ayrılan iş kaynaklarını serbest bırakın. TCC mekanizmasını göstermek için bir şema kullanın:
Tam bir TTK işlemi katılımcısı üç bölümden oluşur: Ana iş hizmeti: Ana iş hizmeti, tüm iş faaliyetinin başlatıcısıdır Daha önce bahsedilen birleşik ödeme senaryosunda olduğu gibi, ödeme sistemi ana iş hizmetidir. İkincil iş hizmetleri: İkincil iş hizmetleri, TCC iş operasyonlarını sağlamaktan sorumludur ve tüm ticari faaliyetlerin işletmecisidir. Bağımlı işletme hizmeti, ana iş hizmetinin araması için Deneme, Onayla ve İptal arabirimlerini uygulamalıdır. Onayla ve İptal işlemleri tekrar tekrar çağrılabileceğinden, Onayla ve İptal arayüzlerinin idempotent olması gerekir. Önceki birleşik ödeme senaryosundaki denge sistemi ve kırmızı zarf sistemi, köle işletme hizmetleridir.
İş faaliyeti yöneticisi: İş faaliyeti yöneticisi, TCC global işleminin işlem durumunu ve iş hizmetinin her bir alt işleminin durumunu kaydetmek ve sürdürmek dahil olmak üzere tüm iş faaliyetini yönetir ve kontrol eder ve iş faaliyeti sunulduğunda tüm TCC tipi işlemlerin onaylandığını onaylar. , Ticari faaliyet iptal edildiğinde tüm TCC tipi işlemlerin iptal işlemini çağırın.
Tüm TTK işleminin, iş faaliyeti yöneticisi ve köle iş hizmetinin her birinin işin bir bölümünü yaptığı ana iş hizmetine karşı şeffaf olduğu görülebilir.
2. TTK'nın avantajları ve sınırlamaları
TCC işlemlerinin avantajları şu şekildedir: çapraz uygulama iş operasyonlarının atomik problemini çözer ve kombine ödeme ve hesap bölme gibi senaryolarda çok pratiktir. TCC aslında, veritabanı katmanında düşük 2PC performansı sorununu ortadan kaldıran veritabanı için tek aşamalı bir sunum olan veritabanı katmanının iki aşamalı sunumunu uygulamak için uygulama katmanına atıfta bulunur. TTK işlemlerinin temel dezavantajı şudur:
TCC'nin Dene, Onayla ve İptal işlem fonksiyonlarının işletme tarafından sağlanması gerekir ve geliştirme maliyetleri yüksektir.
Elbette, TTK işlerinin bu eksikliğinin bir eksiklik olup olmadığı bir görüş meselesidir.
3. TCC'yi anlamak için bir vaka
Dürüst olmak gerekirse, TCC'nin teorisi biraz kafa karıştırıcı. Bu nedenle, TCC'nin anlaşılmasına yardımcı olma umuduyla, TCC işlemlerinin sürecini açıklamak için örnek olarak hesap bölme alınacaktır.
Hesap bölme iş senaryosu aşağıdaki gibidir: A, B ve C hesapları üç farklı şubede bulunur. A ve B, C'ye toplam 80 yuan aktarır:
Deneyin: İşi yürütmeyi deneyin. Tüm iş kontrollerini tamamlayın (tutarlılık): A, B, C hesap durumunun normal olup olmadığını, A hesabının bakiyesinin 30 yuan'den az olup olmadığını ve B hesabının bakiyesinin 50 yuan'dan az olup olmadığını kontrol edin. Gerekli iş kaynaklarını ayırın (yarı izolasyon): Bu iki hesabın bakiyelerini düşüren ve başka bir eşzamanlı işlem yapılmamasını sağlamak için, dondurulmuş A hesabının miktarı 30 yuan ve B hesabının dondurulan miktarı 50 yuan artırılır. Sonraki gerçek transfer işlemi sırasında, A ve B hesaplarının kullanılabilir bakiyesi yetersizdir. Onaylayın: İşletmenin yürütülmesini onaylayın. İşletmenin gerçek icrası: Deneme aşamasında A, B ve C hesaplarının durumu normalse ve A ve B hesaplarının bakiyeleri yeterliyse, A hesabının C hesabına transfer işlemi 30 yuan ve B hesabının C hesabına 50 yuan olarak yürütülür. Herhangi bir iş teftişi yapmayın: Şu anda iş teftişi yapmaya gerek yoktur ve Deneme aşamasında iş teftişi tamamlanmıştır. Yalnızca Deneme aşamasında rezerve edilen iş kaynaklarını kullanın: yalnızca Deneme aşamasında A hesabı ve B hesabında dondurulan miktarı kullanın. İptal: İşin yürütülmesini iptal edin ve Deneme aşamasında rezerve edilen iş kaynaklarını serbest bırakın: Deneme aşaması kısmen başarılıysa, örneğin, A hesabının bakiyesi yeterliyse ve ilgili tutar başarıyla dondurulmuşsa ve B hesabının bakiyesi yeterli değilse ve donma başarısız olursa, A hesabını iptal etmeniz gerekir. A hesabının donmuş miktarını çözmek için çalıştırın. Özet: TCC işlemlerinin kullanılıp kullanılmayacağı aşağıdaki noktalara bağlıdır: Çapraz uygulama iş operasyonlarını sağlamak için gerçekten atomik bir gereksinim olup olmadığı. Karşılık gelen TCC arayüzünü geliştirmek için Ar-Ge'ye kaynak yatırımı yapabilir mi?
Elbette, istikrarlı, yüksek oranda erişilebilir ve ölçeklenebilir bir TCC işlem yöneticisi elde edip edemeyeceğiniz konusunda son bir nokta var.
Bir soru, TTK işlemindeki (iş hizmetinden gelen) tüm katılımcılar Deneme aşamasında başarılıysa, ancak bazı katılımcılar (iş hizmetinden) Onaylama aşamasında başarılı olursa, bununla nasıl başa çıkılır?
TCC referans malzemesi "Büyük Ölçekli SOA Sisteminde Dağıtılmış İşlem İşleme".
Idempotence:
İdempotence nedir
Matematiksel bir tanımı kopyalayın: f (f (x)) = f (x). X'in f fonksiyonu tarafından bir kez etki edilmesinin sonucu, sonsuz zamanlara etki etmekle aynıdır. Idempotence yazılım sistemlerine uygulanır. Bunu basitçe şöyle tanımlıyorum: Bir işlev veya arayüz aynı parametrelerle bir veya sonsuz kez çağrılırsa, sonuçlar aynıdır. Pratik uygulamalarda idempotent tasarım genellikle arayüzlere yöneliktir. Örneğin, sistemde, arayan A, ağ istikrarsızlığı nedeniyle kullanıcı kesinti işlemlerini gerçekleştirmek için B sisteminin arayüzünü aradığında, A isteği N kez yeniden dener, bu nedenle B'nin kaç istek aldığı önemli değil Kullanıcı için sadece bir ücret kesileceği garanti edilmektedir.
