Bu makale, mikro hizmetler altında işlem tutarlılığının nasıl sağlanacağından bahsediyor
İşin hızla gelişmesi ve işin artan karmaşıklığıyla birlikte, geleneksel tekli uygulamalar, düşük geliştirme verimliliği, zayıf sürdürülebilirlik, zayıf mimari ölçeklenebilirliği, esnek olmayan dağıtım ve zayıf sağlamlık gibi bazı sorunları kademeli olarak ortaya çıkardı. Mikro hizmet mimarisi, tek bir hizmeti bir dizi küçük hizmete böler ve bu küçük hizmetlerin bağımsız süreçleri vardır ve birbirinden bağımsızdır, bu da geleneksel monolitik uygulamaların yukarıdaki sorunlarını çözer, ancak mikro hizmet mimarisi altında işlemlerin nasıl sağlanacağı Tutarlılık ne olacak? Bu makalenin yazarı size ayrıntılı bir cevap verecektir.
1 Yerel işlemlerden dağıtılmış işlemlere geçiş
İşlem nedir? Bu soruyu cevaplamadan önce klasik bir senaryoya bir göz atalım: Alipay gibi ticaret platformlarının transferi. Xiao Ming'in 100,000 yuan'ı Xiaohong'a transfer etmek için Alipay'i kullanması gerektiğini varsayalım. Şu anda Xiaoming'in hesabı 100,000 yuan daha az ve Xiaohong'un hesabı 100,000 yuan daha fazla olacak. Transfer işlemi sırasında sistem çökerse, Xiaoming'in hesabı 100000 yuan'ın altındaysa ve Xiaohong'un hesabının miktarı değişmeden kalırsa büyük bir sorun olacak, bu yüzden şu anda işlemleri kullanmamız gerekiyor.
Burada işlemlerin çok önemli bir özelliği yansıtılır: atomiklik. Aslında işlemlerin dört temel özelliği vardır: atomiklik, tutarlılık, izolasyon ve dayanıklılık. Bunların arasında atomiklik, yani işlem içindeki tüm işlemler başarılı veya başarısız olur ve ortada belirli bir bağlantıyla bitmez. Tutarlılık, veritabanı bir işlemden önce ve sonra çalıştırılsa bile, veritabanı tutarlı bir durumda olmalıdır. İşlem başarısız olursa, otomatik olarak orijinal durumuna geri döndürülmesi gerekir. Başka bir deyişle, işlem tamamlandıktan sonra, diğer işlemler tarafından görüntülenen sonuçlar tutarlıdır. İşlem geri alındığında, diğer işlemler yalnızca geri alma işleminden önceki durumu görebilir. İzolasyon, yani eşzamanlı bir ortamda, farklı işlemler aynı verileri aynı anda değiştirdiğinde, bekleyen bir işlem başka bir bekleyen işlemi etkilemeyecektir. Kalıcılık, yani işlem tamamlandıktan sonra, değiştirilen veriler veritabanında kalıcı olarak depolanacak ve değişiklikler kalıcı olacaktır.
Yerel işlemler, ACID aracılığıyla güçlü veri tutarlılığı sağlar. ACID, Atomik, Tutarlılık, İzolasyon ve Dayanıklılığın kısaltmasıdır. Gerçek geliştirme sürecinde, az çok yerel işleri kullandık. Örneğin, MySQL işlem işleme kullanımları bir işlemi başlatmaya başlar, geri alma işlemi geri alınır ve işlem onaylarını taahhüt eder. Burada, işlem tamamlandıktan sonra, değişiklikler yineleme günlüğü aracılığıyla kaydedilir ve geri alma günlüğü, işlemin atomikliğini sağlamakta başarısız olduğunda geri almak için kullanılır. Yazar, Java dilini kullanan tüm geliştiricilerin Spring ile iletişime geçtiğini ekliyor. Spring, işlem işlevini işlemek için @Transactional ek açıklamasını kullanır. Aslında Spring bu detayları özetliyor.İlgili çekirdekler üretilirken ilgili çekirdeklere @Transactional annotations enjekte etmeniz gerektiğinde proxy enjeksiyonu kullanılır ve proxy'de commit / rollback işlemi bizim için açılır.
İşin hızla gelişmesiyle birlikte, muazzam miktarda veri karşısında, örneğin on milyonlarca hatta yüz milyonlarca veri karşısında, bir kez sorgulama süresi uzar ve hatta veritabanı üzerinde tek bir baskı noktasına bile neden olabilir. Bu nedenle, alt veri tabanı ve sayaç altı şemasını dikkate almalıyız. Alt veritabanı ve alt tablonun amacı, tek veritabanı ve veritabanının tek tablosunun yükünü azaltmak, sorgu performansını iyileştirmek ve sorgu süresini kısaltmaktır. Burada önce sipariş kitaplığının bölündüğü senaryoya bakalım. Aslında, bölünmüş tablo stratejisi dikey bölme ve yatay bölme olarak özetlenebilir. Dikey bölme, tablonun alanlarını bölün, yani daha fazla alana sahip bir tablo, satır verilerini daha küçük hale getiren birden çok tabloya bölünür. Bir yandan, üretim ortamı aynı ağ bant genişliğini paylaştığı için istemci programı ile veritabanı arasında ağda aktarılan bayt sayısını azaltabilir.Eşzamanlı sorguların artmasıyla bant genişliği darboğazına neden olabilir ve tıkanıklığa neden olabilir. Öte yandan, bir veri bloğu daha fazla veri depolayabilir, bu da sorgulama sırasında I / O'ların sayısını azaltacaktır. Yatay bölme, tablonun satırlarını bölün. Bir tablodaki satır sayısı birkaç milyon satırı aştığı için yavaşlayacaktır. Şu anda, bir tablonun verileri depolama için birden çok tabloya bölünebilir. Yatay bölme için birçok strateji vardır, örneğin, modüler alt tablo, zaman boyutu alt tablosu vb. Bu senaryoda, tabloyu belirli kurallara göre bölmemize rağmen, yine de yerel işlemleri kullanabiliriz. Ancak kitaplıktaki tabloların bölümlere ayrılması, sadece tek bir tablodaki aşırı büyük veri sorununu çözer, tek bir tablonun verilerini farklı fiziksel makinelerde dağıtmaz, bu nedenle MySQL sunucusu üzerindeki baskıyı azaltmaz.Aynı fiziksel makinede hala veri mevcuttur. CPU, bellek, disk GÇ, ağ bant genişliği vb. Dahil olmak üzere kaynak rekabeti ve darboğazlar. Veritabanı bölme senaryosu için, bir tablonun verilerini farklı veritabanlarına böler ve birden çok veritabanının tablo yapısı aynıdır. Bu noktada işlem kullanmamız için ihtiyaç duyduğumuz verileri belirli kurallara göre aynı kütüphaneye yönlendirirsek, lokal işlemler ile güçlü bir tutarlılık sağlayabiliriz. Bununla birlikte, iş ve işleve göre bölünmüş dikey bölünmeler için, iş verilerini farklı veritabanlarına koyacaktır. Burada, bölünmüş sistem veri tutarlılığı sorunlarıyla karşılaşacaktır, çünkü işlemlerle garanti edilen verileri farklı veritabanlarında dağıtmamız gerekir ve her veritabanı, güçlü tutarlılık sağlamak için yalnızca kendi verilerinin ACID'yi karşılamasını sağlayabilir. Ancak dağıtılmış bir sistemde, farklı sunuculara yerleştirilebilirler ve yalnızca ağ üzerinden iletişim kurabilirler, bu nedenle diğer veritabanlarında işlemlerin yürütülmesini doğru bir şekilde bilmek imkansızdır.
Buna ek olarak, yalnızca veritabanı çapraz çağrılarda yerel işlemlerle çözülemeyen sorunlar değil, mikro hizmetlerin uygulanmasıyla her hizmetin kendi veritabanı vardır ve veritabanları bağımsız ve şeffaftır. Ardından, A servisinin B servisinin verilerini alması gerekiyorsa, bir servisler arası arama olacaktır.Hizmet çalışmıyorsa veya ağ bağlantısı anormalse, senkronizasyon çağrısı zaman aşımı ve diğer senaryolar veri tutarsızlığına neden olacaktır, bu da dağıtılmış bir senaryoda bir ihtiyaçtır. Veri tutarlılığı sorunlarını düşünün.
Özetle, iş ölçeği genişletildiğinde, mikro hizmetler uygulandıktan sonra alt veritabanı ve iş hizmeti, tutarsız dağıtılmış veriler sorununa neden olacaktır. Yerel işlemler talebi karşılayamadığı için dağıtık işlemler devreye girmelidir. Dağıtılmış işlem nedir? Farklı veritabanlarında veri tutarlılığını sağlamak için bir işlem çözümü olduğunu kolayca anlayabiliriz. Burada önce CAP prensibini ve BASE teorisini anlamamız gerekiyor. CAP ilkesi, Tutarlılık, Kullanılabilirlik ve Bölme toleransının kısaltmasıdır ve dağıtılmış sistemlerde denge teorisidir. Dağıtılmış bir sistemde tutarlılık, tüm düğümlerin her okunduklarında en son verilerin elde edilmesini sağlamasını gerektirir; kullanılabilirlik, hizmetlerin herhangi bir hatadan bağımsız olarak hala kullanılabilir olmasını gerektirir; bölüm hatası toleransı, bölümlenmiş düğümlerin normal şekilde hizmet sunabilmesini gerektirir . Aslında, herhangi bir sistem aynı anda yalnızca ikisini tatmin edebilir ve üçüne de bakamaz. Dağıtılmış sistemler için, bölüm hata toleransı en temel gereksinimdir. Ardından, tutarlılık ve bölüm hata toleransını seçerseniz ve kullanılabilirlikten vazgeçerseniz, ağ sorunları sistemin kullanılamamasına neden olur. Kullanılabilirliği ve bölüm hatası toleransını seçerseniz ve tutarlılıktan vazgeçerseniz, farklı düğümler arasındaki veriler zaman içinde senkronize edilemez ve bu da veri tutarsızlığına neden olur.
Şu anda, BASE teorisi tutarlılık ve kullanılabilirlik için bir çözüm ortaya koymaktadır. BASE, Temelde Kullanılabilir, Yumuşak Durum ve Sonunda Tutarlı'nın kısaltmasıdır. Nihai tutarlılık için teorik destek. . Basitçe, dağıtılmış bir sistemde kısmi kullanılabilirliğin kaybolmasına izin verildiğini ve farklı düğümler arasında veri senkronizasyonu sürecinde bir gecikme olduğunu, ancak bir onarım süresinden sonra verilerin nihai tutarlılığının elde edilebileceğini anlayın. BASE, verilerin nihai tutarlılığını vurgular. ACID ile karşılaştırıldığında, BASE kısmi tutarlılığın kaybolmasına izin vererek kullanılabilirlik kazanır.
Şimdi, endüstride daha yaygın olarak kullanılan dağıtılmış işlem çözümleri, güçlü tutarlılık iki aşamalı tamamlama protokolü, üç aşamalı tamamlama protokolü ve nihayetinde tutarlı güvenilir olay modu ve telafi modu ve Ali'nin TCC modunu içerir.
2 güçlü tutarlılık çözümü
İki aşamalı taahhüt sözleşmesi
Dağıtılmış bir sistemde, her veritabanı güçlü bir tutarlılık sağlamak için yalnızca kendi verilerinin ACID'yi karşılamasını sağlayabilir, ancak farklı sunucularda konuşlandırılabilir ve yalnızca ağ üzerinden iletişim kurabilir, bu nedenle diğer veritabanlarındaki işlemleri doğru bir şekilde bilmek imkansızdır. Uygulama. Bu nedenle, birden fazla düğüm arasındaki koordinasyon sorununu çözmek için, tüm düğümlerin işlem sonuçlarını kontrol etmekten sorumlu bir koordinatörün tanıtılması gerekir, hepsi başarılı olsun veya olmasın. Bunlar arasında, XA protokolü, iki rolü olan dağıtılmış bir işlem protokolüdür: işlem yöneticisi ve kaynak yöneticisi. Burada işlem yöneticisini koordinatör ve kaynak yöneticisini katılımcı olarak anlayabiliriz.
XA protokolü, iki aşamalı bir gönderim protokolü aracılığıyla güçlü tutarlılığı garanti eder.
Adından da anlaşılacağı gibi, iki aşamalı tamamlama protokolünün iki aşaması vardır: ilk hazırlık aşaması ve sunmanın ikinci aşaması. Burada, işlem yöneticisi (koordinatör) esas olarak hazırlık süreci ve gönderim süreci dahil olmak üzere tüm düğümlerin işlem sonuçlarını kontrol etmekten sorumludur. İlk aşamada, işlem yöneticisi (koordinatör) kaynak yöneticisine (katılımcı) bir hazırlık talimatı başlatır ve kaynak yöneticisine (katılımcı) ön taahhüdün başarılı olup olmadığını sorar. Kaynak yöneticisi (katılımcı) tamamlayabilirse, işlemi göndermeden gerçekleştirecek ve son olarak, ön gönderim başarılı veya ön gönderim başarısız olsun, kendi yanıt sonucunu verecektir. İkinci aşamada, tüm kaynak yöneticileri (katılımcılar) ön gönderimin başarılı olduğunu söylerse, kaynak yöneticileri (katılımcılar) siparişi resmi olarak gönderir. Kaynak yöneticilerinden (katılımcılar) biri ön taahhüt hatasına yanıt verirse, işlem yöneticisi (koordinatör) tüm kaynak yöneticilerine (katılımcılar) bir geri alma komutu başlatır. Örneğin, şimdi bir işlem yöneticimiz (koordinatörümüz) ve üç kaynak yöneticimiz (katılımcı) var, bu durumda bu işlemde işlem sürecindeki üç katılımcının verilerinin güçlü tutarlılığını sağlamamız gerekiyor. Her şeyden önce, işlem yöneticisi (koordinatör), başarılı bir şekilde önceden gönderilip gönderilmediğini belirlemek için hazırlık talimatlarını başlatır.Tüm cevap ön sunumları başarılı olursa, işlem yöneticisi (koordinatör) veri değişikliklerini yürütmek için resmi olarak bir commit komutu başlatır.
İki aşamalı kesinleştirme protokolü, güçlü tutarlılık sağlamak için bir dizi çözüm önermesine rağmen, hala bazı sorunlar olduğunu unutmayın. Birincisi, işlem yöneticisi (koordinatör) esas olarak hazırlık süreci ve gönderim süreci dahil olmak üzere tüm düğümlerin işlem sonuçlarını kontrol etmekten sorumludur, ancak tüm süreç senkronize edilir, bu nedenle işlem yöneticisi (koordinatör) her kaynak yöneticisini (katılım) beklemelidir. ) Sonraki işlem ancak işlem sonucu döndürüldükten sonra gerçekleştirilebilir. Bu, senkronizasyon engelleme sorunlarına neden olmak çok kolaydır. İkincisi, tek bir başarısızlık noktası da ciddi düşünmeyi gerektiren bir konudur. Hem işlem yöneticisi (koordinatör) hem de kaynak yöneticisi (katılımcı) çalışmıyor olabilir. Kaynak yöneticisi (katılımcı) başarısız olursa yanıt veremez ve sonsuza kadar bekler. İşlem yöneticisi (koordinatör) başarısız olursa, işlem akışı Denetleyici kaybolur.Başka bir deyişle, tüm süreç her zaman engellenir. Aşırı durumlarda bile, bazı kaynak yöneticileri (katılımcılar) veri gönderimi yapar ve bazıları gönderimi yapmaz, ayrıca veri tutarsızlığı da ortaya çıkar. Bu noktada okuyucu sorular soracaktır: Bu sorunlar küçük olasılık durumları olmalı ve genellikle oluşmayacak mı? Evet, ancak dağıtılmış işlem senaryoları için, yalnızca normal mantık akışını dikkate almamız gerekmiyor, aynı zamanda anormal sahnelerin küçük olasılığına da dikkat etmemiz gerekiyor. Anormal sahneler için bir işleme planımız yoksa, veri tutarsızlıkları ve ardından el emeği Müdahale işleme çok maliyetli bir iş olacaktır.Ayrıca, işlemin temel bağlantısı bir veri sorunu değil, daha ciddi bir varlık kaybı sorunu olabilir.
Üç aşamalı taahhüt sözleşmesi
İki aşamalı sunum anlaşmasının birçok sorunu var, bu nedenle üç aşamalı sunum anlaşması devreye girmek üzere. Üç aşamalı kesinleştirme protokolü, iki aşamalı kesinleştirme protokolünün geliştirilmiş bir sürümüdür. İki aşamalı kesinleştirme protokolünden farklıdır, çünkü senkronizasyon engelleme sorununu çözmek için bir zaman aşımı mekanizması sunar.Ayrıca, hazırlık aşamasında olabildiğince erken yürütemediği tespit edilen kaynak yöneticilerini de ekler (katılmak Tüm kaynak yöneticileri (katılımcılar) işlemi tamamlayabilirse, hazırlığın ikinci aşaması ve taahhüdün üçüncü aşaması başlatılır. Aksi takdirde, kaynak yöneticilerinden (katılımcılardan) herhangi biri uygulamaya yanıt verir veya bir zaman aşımı için bekler ve ardından işlemi sonlandırır. Özetlemek gerekirse, üç aşamalı sunum anlaşması şunları içerir: ilk aşama hazırlık, ikinci aşama hazırlık ve ikinci aşama teslim.
Üç aşamalı gönderim protokolü, iki aşamalı gönderim protokolünün neden olduğu sorunları çözer ve çok anlamlı bir çözümdür. Ancak çok düşük olasılıklı senaryolarda veri tutarsızlıkları meydana gelebilir. Üç aşamalı gönderim protokolü bir zaman aşımı mekanizması getirdiği için, bir kaynak yöneticisi (katılımcı) zaman aşımı senaryosu varsa, gönderim varsayılan olarak başarılı olur, ancak başarılı bir şekilde yürütülmezse veya diğer kaynak yöneticileri (katılımcılar) geri alınırsa, o zaman olacaktır Veri tutarsızlığı.
3 Son olarak tutarlı çözüm
TCC modu
İki aşamalı tamamlama protokolü ve üç aşamalı tamamlama protokolü, dağıtılmış işlemlerin sorununu çözer, ancak aşırı durumlarda hala veri tutarsızlıkları vardır.Ayrıca, sistem üzerinde nispeten büyük bir ek yüke sahip olacak ve bir işlem yöneticisi (koordinatör) sunacaktır. Daha sonra, tek noktalı darboğazların ortaya çıkması daha olasıdır ve iş ölçeği büyümeye devam ettikçe, sistem ölçeklenebilirliği de sorunlu olacaktır. Eşzamanlı bir işlem olduğunu unutmayın, bu nedenle bir işlemin başlatılmasından sonra kaynaklar küresel işlemin sonuna kadar serbest bırakılamaz, performans büyük bir sorun olabilir. Bu nedenle, yüksek eşzamanlılık senaryolarında nadiren kullanılır. Bu nedenle Ali başka bir çözüm önerdi: TCC modu. Pek çok okuyucunun iki aşamalı gönderimi iki aşamalı teslim sözleşmesi ile eşitlediğini unutmayın.Bu bir yanlış anlaşılmadır.Aslında, TCC modu da iki aşamalı bir sunumdur.
TCC modu, bir görevi üç işleme ayırır: Dene, Onayla, İptal. Bir func () yöntemimiz varsa, TCC modunda, tryFunc (), confirmFunc (), cancelFunc () üç yöntem haline gelir.
tryFunc (); confirmFunc (); cancelFunc ();TCC modunda, ana iş hizmeti sürecin başlatılmasından sorumludur, ikincil iş hizmeti ise TCC modunda Deneme, Onayla ve İptal işlemlerini sağlar. Bunların arasında, işlemlerin tutarlılığını kontrol etmekten sorumlu bir işlem yöneticisi rolü de vardır. Örneğin, şu anda üç ticari hizmetimiz var: işlem hizmetleri, envanter hizmetleri ve ödeme hizmetleri. Kullanıcı ürünü seçer, sipariş verir ve daha sonra ödeme için ödeme yöntemini seçer.Daha sonra bu talep için işlem servisi önce stok servisini arayarak stoku düşürecek, ardından işlem servisi ilgili ödeme işlemleri için ödeme servisini arayacak, ardından ödeme servisi üçüncü bir şahıs talep edecektir. Ödeme platformu işlemleri yaratır ve parayı düşürür.Burada işlem hizmeti ana iş hizmetidir ve envanter hizmeti ve ödeme hizmeti ikincil iş hizmetleridir.
TCC modelinin sürecini sıralayalım. İlk aşamada, ana iş hizmeti yardımcı iş hizmetlerinin tüm Try işlemlerini çağırır ve işlem yöneticisi işlem günlüğünü kaydeder. İkinci aşamada, tüm ikincil iş hizmetleri başarılı olduğunda, Onaylama işlemi yürütülecek, aksi takdirde geri almak için İptal işleminin tersi gerçekleştirilecektir.
Şimdi, TCC modeli için genel iş gerçekleştirme fikirlerinden bahsedelim. İlk olarak, işlem hizmeti (ana iş hizmeti) işlem yöneticisine kaydolacak ve işlemi başlatacaktır. Aslında işlem yöneticisi, ana iş hizmetine gömülü bir iş mantığı veya izole bir TCC çerçevesi olabilen kavramsal bir küresel işlem yönetimi mekanizmasıdır. Aslında, tüm işlem bağlantısını kaydetmek için küresel bir işlem kimliği oluşturur ve iç içe geçmiş işlemler için bir dizi işleme mantığı uygular. Ana işletme hizmeti, ikincil işletme hizmetlerinin tüm deneme işlemlerini çağırdığında, işlem yöneticisi, ilgili işlem günlüklerini kaydetmek için yerel işlemleri kullanır.Bu durumda, envanter hizmetini çağırmanın eylem kaydını ve ödeme hizmetini çağırmanın eylem kaydını ve durumunu kaydeder. "Ön gönder" durumuna ayarlayın. Burada, bağımlı işletme hizmetini çağıran Deneme işlemi, temel iş kodudur. Öyleyse, Try işlemi, karşılık gelen Onayla ve İptal işlemlerine nasıl bağlanır? Aslında, bağlayıcı bir ilişki kurmak için bir yapılandırma dosyası yazabilir veya Spring'in açıklamaları aracılığıyla onaylama ve iptal etme parametreleri ekleyebiliriz ki bu da iyi bir seçimdir. Tüm ikincil iş hizmetleri başarılı olduğunda, işlem yöneticisi TCC işlem bağlamı yönü aracılığıyla Onaylama işlemini yürütür ve durumunu "başarılı" durumuna ayarlar, aksi takdirde durumunu "ön taahhüt" durumuna ayarlamak için İptal işlemini yürütür ve ardından yeniden başlatır. Ölçek. Bu nedenle, TCC modu tazminat yoluyla nihai tutarlılığını garanti eder.
TCC'nin uygulama çerçevesi, tcc-transaction çerçevesi gibi birçok olgun açık kaynak projesine sahiptir. (Tcc-transaction çerçevesi hakkında ayrıntılar için şu adresi okuyabilirsiniz: https://github.com/changmingxie/tcc-transaction).
Tcc-işlem çerçevesi esas olarak üç modülü içerir: tcc-transaction-core, tcc-transaction-api ve tcc-transaction-spring. Bunlar arasında, tcc-transaction-core, tcc-transaction'ın temelindeki uygulamasıdır, tcc-transaction-api, tcc-transaction tarafından kullanılan API ve tcc-transaction-spring, tcc-transaction'ın Spring desteğidir. tcc-transaction her bir iş işlemini bir işlem katılımcısı olarak özetler ve her işlem birden fazla katılımcı içerebilir. Katılımcıların üç tür yöntem beyan etmeleri gerekir: dene / onayla / iptal et. Burada try yöntemini @Compensable annotation ile işaretliyoruz ve ilgili onayla / iptal yöntemini tanımlıyoruz.
// @Compensable yöntemini deneyin (confirmMethod = "confirmRecord", cancelMethod = "cancelRecord", transactionContextEditor = MethodTransactionContextEditor.class) @Transactionalpublic Dize kaydı (TransactionContext transactionContext, CapitalTradeOrderDto, tradeOrderDto) {} // onaylama yöntemi @Transcordonactional CapitalTradeOrderDto tradeOrderDto) {} // yöntemi iptal et @Transactionalpublic void cancelRecord (TransactionContext transactionContext, CapitalTradeOrderDto tradeOrderDto) {}Tcc-transaction çerçevesinin gerçekleştirilmesi için, bazı temel fikirleri anlayalım. Tcc-transaction çerçevesi, katılımcının onaylama / iptal etme yöntemini şeffaf bir şekilde çağırabilen @Compensable yönü aracılığıyla kesişir ve böylece TCC modunu gerçekleştirir. Burada tcc-transaction iki engelleyiciye sahiptir.
- org.mengyun.tcctransaction.interceptor.CompensableTransactionInterceptor, telafi edilebilir bir işlem önleyicisi.
- org.mengyun.tcctransaction.interceptor.ResourceCoordinatorInterceptor, kaynak koordinatörü engelleyici.
Burada, TransactionContext işlem bağlamına özel dikkat göstermemiz gerekir, çünkü hizmet katılımcısını uzaktan ararken işlemi parametreler şeklinde uzak katılımcıya iletmemiz gerekir. Tcc-transaction'da, org.mengyun.tcctransaction.Transaction işleminde birden çok katılımcı org.mengyun.tcctransaction.Participant'ın ticari faaliyetlere katılması olabilir. Bunlar arasında, TransactionXid işlem numarası, bir işlemi benzersiz bir şekilde tanımlamak için kullanılır ve benzersizliği sağlamak için UUID algoritması kullanılarak oluşturulur. Bir katılımcı uzaktan arama yaptığında, uzak şube işleminin işlem numarası, katılımcının işlem numarasına eşittir. İşlem numarası ilişkilendirmesinin TTK onaylama / iptal etme yöntemi ile, katılımcının işlem numarası, işlemin tamamlanması ve geri alınmasının gerçekleştirilmesi için uzak şube işlemi ile ilişkilendirmek için kullanılır. İşlem Durumu İşlem Durumu şunları içerir: Deneme durumu DENiyor (1), Durum onaylanıyor (2), İptal durumu İPTAL EDİLİYOR (3). Ayrıca TransactionType işlem türü şunları içerir: kök işlem ROOT (1), şube işlemi BRANCH (2). Kök işlemi başlatmak için TransactionManager # begin () çağrıldığında, tür MethodType.ROOT şeklindedir ve işlem deneme yöntemi çağrılır. Şube hareketini yaymak için TransactionManager # propagationNewBegin () yöntemini çağırın. Bu yöntem MethodType.PROVIDER'ı çağırıyor ve işlem deneme yöntemi çağrılıyor. İşlemi gerçekleştirmek için TransactionManager # commit () yöntemini çağırın. Bu yöntem, işlem onaylama / iptal etme yöntemindeyken çağrılır. Benzer şekilde, işlemi iptal etmek için TransactionManager # rollback () yöntemini çağırın.
Ek olarak, işlem kurtarma mekanizması için, tcc-işlem çerçevesi, planlamayı uygulamak ve işlem tamamlanıncaya veya maksimum yeniden deneme sayısı aşılana kadar işlemi belirli bir sıklıkta yeniden denemek için Quartz'ı temel alır. Tek bir işlem maksimum yeniden deneme sayısını aşarsa, tcc-işlem çerçevesi artık yeniden denemez ve bu sırada manuel müdahale gerekir.
Burada, operasyonların ideopotansına özellikle dikkat etmeliyiz. İdempotent mekanizmasının özü, kaynakların benzersizliğini sağlamaktır.Örneğin, sunucu tarafında tekrarlanan gönderimler veya çoklu yeniden denemeler yalnızca bir sonuç üretecektir. Ödeme senaryoları, iade senaryoları ve para içeren işlemlerde birden fazla kesinti olamaz. Aslında, sorgu arabirimi kaynakların değişimini etkilemeden yalnızca verileri sorguladığı için kaynakları elde etmek için kullanılır.Bu nedenle arabirim kaç kez çağrılırsa çağrılsın kaynaklar değişmez, dolayısıyla idempotenttir. Yeni arayüz idempotent değildir, çünkü arayüzü birden çok kez çağırırsanız, kaynak değişikliklerine neden olur. Bu nedenle, tekrarlanan gönderimler gerçekleştiğinde idempotent işlemeyi gerçekleştirmemiz gerekir. Peki idempotent mekanizma nasıl sağlanır? Aslında birçok uygulama seçeneğimiz var. Bunların arasında bir çözüm, ortak benzersiz bir dizin oluşturmaktır. Yinelenen verilerin eklenmesini önlemek için kısıtlamamız gereken kaynak alanları için veritabanında benzersiz bir dizin oluşturun. Ancak, alt veritabanı ve alt tablo söz konusu olduğunda, benzersiz dizinin kullanımı o kadar kolay değildir.Şu anda, önce veritabanını sorgulayabilir ve ardından kısıtlı kaynak alanının yinelenip yinelenmediğini belirleyebilir ve ardından yineleme olmadığında işlemi ekleyebiliriz. . Eşzamanlı senaryolardan kaçınmak için, kötümser kilitleme ve iyimser kilitleme gibi kilitleme mekanizmaları aracılığıyla verilerin benzersizliğini garanti edebileceğimizi unutmayın. Burada dağıtılmış kilit sık kullanılan bir çözümdür, genellikle karamsar bir kilit uygulamasıdır. Bununla birlikte, çoğu insan genellikle kötümser kilitleri, iyimser kilitleri ve dağıtılmış kilitleri idempotent mekanizmalara çözüm olarak görür, bu yanlıştır. Ek olarak, aynı işletmenin prosedürel olarak yürütülmesini sağlamak için durum kısıtlamaları ve durum atlamaları gerçekleştirmek için bir durum makinesi de ekleyebiliriz, böylece veri idempotansı elde edebiliriz.
Tazminat modu
Önceki bölümde, yeniden deneme mekanizmasından bahsetmiştik. Aslında, nihai tutarlılık için de bir çözümdür: Veritabanının çalışmasının sonunda veri tutarlılığını sağlamak için elimizden gelen en iyi çabayı göstermeye devam etmeliyiz. Son yeniden deneme birden çok kez başarısız olursa, ilgili günlüklere dayanarak geliştirmeyi aktif olarak bilgilendirebiliriz. Personel tarafından manuel müdahale. Aranan ucun idempotansını sağlaması gerektiğini unutmayın. Yeniden deneme mekanizması bir senkronizasyon mekanizması olabilir, örneğin, ana iş hizmeti çağrısı zaman aşımı veya anormal olmayan bir çağrı arızasının iş çağrısını zamanında yeniden başlatması gerekir. Yeniden deneme mekanizması, kabaca sabit sayıda yeniden deneme stratejisine ve sabit zamanlı yeniden deneme stratejisine bölünebilir. Ayrıca mesaj kuyruğu ve zamanlama görev mekanizmasını da kullanabiliriz. Mesaj kuyruğunun yeniden deneme mekanizması, yani, tüketilmeden mesajın atılmasını önlemek için, tüketilemediğinde mesaj yeniden teslim edilecektir.Örneğin, RocketMQ her mesajın varsayılan olarak 16 defaya kadar yeniden denenmesine izin verebilir ve her yeniden deneme arasındaki aralık Ayarları yapın. Zamanlanmış görevlerin yeniden deneme mekanizması için, bir görev yürütme tablosu oluşturabilir ve bir "yeniden deneme süreleri" alanı ekleyebiliriz. Bu tasarım şemasında, görevin başarısız bir yürütme durumunda olup olmadığını ve görev düzenli olarak çağrıldığında yeniden deneme sayısının aşılmadığını öğrenebilir ve öyleyse başarısız bir yeniden deneme gerçekleştirebiliriz. Ancak, yürütme başarısız olduğunda ve yeniden deneme sayısı yeniden deneme sayısını aştığında, bu, görevin kalıcı olarak başarısız olduğu ve geliştiriciler tarafından manuel müdahale ve sorun giderme gerektirdiği anlamına gelir.
Yeniden deneme mekanizmasına ek olarak, her güncellendiğinde de onarılabilir. Örneğin, beğenme, sık kullanılanlar ve yorumların sayısı gibi sosyal etkileşim sayma senaryoları için, belki de ağ titreşimi veya ilgili hizmetlerin kullanılamaması nedeniyle veriler belirli bir süre boyunca tutarsız olabilir.Her güncellendiğinde düzeltebiliriz. Sistemin kısa sürede kendini kurtarmasını ve revize etmesini ve verilerin nihayet aynı seviyeye ulaşmasını sağlayın. Bu çözümün kullanılması durumunda, bir veri parçası tutarsızsa, ancak tekrar güncellenip onarılmazsa, her zaman anormal veri olacağı unutulmamalıdır.
Zamanlama düzeltmesi de çok önemli bir çözümdür ve bunu sağlamak için periyodik düzeltme işlemlerini benimser. Zamanlama görev çerçevesinin seçimiyle ilgili olarak, endüstride en yaygın olarak kullanılanlar, bağımsız bir senaryoda Quartz ve dağıtılmış bir senaryoda Elastic-Job, XXL-JOB ve SchedulerX gibi dağıtılmış zamanlama görev ara yazılımlarıdır. Zamanlama düzeltmesi ile ilgili olarak, iki senaryoya ayrılabilir: Biri tamamlanmamış zamanlama yeniden denemesidir.Örneğin, zamanlama görevlerini, veri tutarlılığını sağlamak için bitmemiş arama görevlerini taramak ve bir tazminat mekanizması aracılığıyla onarmak için kullanırız. Diğeri, ana iş hizmetinin, ikincil iş hizmetinin kontrol etmesi ve sorgulaması için ilgili bir sorgu arabirimi sağlamasını gerektiren ve kayıp iş verilerini kurtarmak için kullanılan zamanlama kontrolüdür. Şimdi, e-ticaret senaryosundaki iade işini hayal edelim. Bu geri ödeme işinde temel bir geri ödeme hizmeti ve otomatik bir geri ödeme hizmeti olacak. Şu anda, otomatik geri ödeme hizmeti, geri ödeme temel hizmetine dayalı olarak geri ödeme yeteneklerinin geliştirilmesini gerçekleştirir, otomatik geri ödemeyi birden çok kurala göre gerçekleştirir ve geri ödeme temel hizmeti tarafından iletilen geri ödeme anlık görüntü bilgilerini mesaj kuyruğu üzerinden alır. Ancak, temel geri ödeme hizmeti tarafından gönderilen mesajın kaybolması veya birden çok başarısız yeniden denemeden sonra mesaj kuyruğunun aktif olarak atılması nedeniyle, veri tutarsızlıklarına neden olma olasılığı yüksektir. Bu nedenle, temel geri ödeme hizmetini düzenli olarak kontrol ederek ve kontrol ederek kaybolan iş verilerini geri yüklemek özellikle önemlidir.
Güvenilir olay modu
Dağıtılmış bir sistemde, sunucu mimarisindeki ileti kuyruklarının konumu, esas olarak eşzamansız işleme, sistem ayrıştırması ve trafik zirvesi gibi senaryoları çözmek için çok önemlidir. Birden fazla sistem arasındaki senkronize iletişim kolaylıkla tıkanmaya neden olabilir ve bu sistemler birbirine bağlanacaktır. Bu nedenle, mesaj kuyruklarının girişi bir yandan senkronize iletişim mekanizmasının neden olduğu tıkanıklığı çözerken, diğer yandan hizmetleri mesaj kuyruğu üzerinden ayırır.
Güvenilir olay modu, geçerli güvenilir olay teslimi garanti edildiği ve mesaj kuyruğu, olayın en az bir kez teslim edilmesini sağladığı sürece, güvenilir bir mesaj kuyruğu sunarak, bu etkinliğe abone olan tüketiciler olayın kendi işlerinde tüketilebilmesini sağlayabilir. Burada, lütfen sorunun bir mesaj kuyruğu oluşturarak çözülüp çözülemeyeceğini düşünün. Aslında, bir mesaj kuyruğunun sadece tanıtılması nihai tutarlılığını garanti edemez, çünkü dağıtılmış bir dağıtım ortamında, iletişim ağa dayanır ve ağ iletişimi sürecinde, yukarı ve aşağı akış, çeşitli nedenlerle mesaj kaybına neden olabilir.
Birincisi, ileti kuyruğu kullanılamadığından ileti gönderirken ana iş hizmeti başarısız olabilir. Bu durumda, ana iş hizmetinin (üreticinin) bir mesaj göndermesine izin verebilir ve ardından emin olmak için bir iş görüşmesi yapabiliriz. Genel yaklaşım, ana iş hizmetinin yerel veritabanına gönderilecek mesajı devam ettirmesi, bayrak durumunu "gönderilecek" durumuna ayarlaması ve ardından mesajı mesaj kuyruğuna göndermesidir.Mesaj kuyruğu mesajı aldıktan sonra, aynı zamanda mesajı kendi Depolama hizmetinde, mesaj ikincil iş hizmetine (tüketici) hemen teslim edilmez, ancak mesaj kuyruğunun yanıt sonucu önce ana iş hizmetine (üretici) geri gönderilir ve ardından ana iş hizmeti yanıt sonucunu değerlendirir ve yürütmeden sonra iş sürecini yürütür. Yanıt başarısız olursa, sonraki iş süreci terk edilir ve yerel kalıcı mesaj bayrağı durumu "son" durumuna ayarlanır. Aksi takdirde, sonraki iş sürecini gerçekleştirin ve yerel kalıcı mesaj bayrağı durumunu "gönderildi" durumuna ayarlayın.
public void doServer () { // Mesaj gönder send (); // İşletmeyi yürüt exec (); // Mesaj durumunu güncelleyin updateMsg (); }Ek olarak, mesaj kuyruğunda bir mesaj oluştuktan sonra, iş hizmeti (tüketici) çalışmayabilir ve tüketilemez. Bu durum için, RabbitMQ, RocketMQ vb. Gibi çoğu mesajlaşma ara yazılımı bir ACK mekanizması sunar. Varsayılan olarak otomatik yanıtın kullanıldığını unutmayın.Bu şekilde, mesaj kuyruğu mesajı gönderdikten sonra mesajı mesaj kuyruğundan hemen silecektir. Bu nedenle, mesajın güvenilir bir şekilde teslim edilmesini sağlamak için manuel ACK yöntemini kullanıyoruz.İşletme hizmeti (tüketici) kesinti veya başka nedenlerle bir ACK göndermezse, mesajın güvenilirliğini sağlamak için mesaj kuyruğu mesajı yeniden gönderecektir. İş hizmeti ilgili işi işledikten sonra, mesaj kuyruğu manuel ACK ile bildirilir ve mesaj kuyruğu kalıcı mesajı mesaj kuyruğundan siler. Öyleyse, mesaj kuyruğu yeniden denenmeye devam ederse ve teslim edilemiyorsa, mesaj aktif olarak atılacaktır, nasıl çözeriz? Akıllı okuyucular, son adımda ana iş hizmetinin mesajı yerel veri tabanına gönderilmek üzere ısrarla sürdürdüğünü keşfetmiş olabilirler. Bu nedenle, işletme hizmetinden başarılı bir şekilde tüketildikten sonra, mesaj kuyruğuna bir bildirim mesajı da gönderecek ve bu sırada bir mesaj üreticisi olacaktır. Ana iş hizmeti (tüketici) mesajı aldıktan sonra, en sonunda yerel kalıcı mesajın durumunu "tamamlandı" olarak işaretler. Bunu söyledikten sonra, okuyucular, mesaj kuyruğunda güvenilir olay teslimi sağlamak için "ileri ve geri mesaj mekanizmasını" kullandığımızı anlayabilmelidir. Elbette tazminat mekanizması da önemlidir. Zamanlanmış görevler, veritabanını belirli bir süre içinde bitmemiş mesajlar için tarar ve yeniden teslim eder.
Mesaj kuyruğunun mesaj işleme sonucunu alamayabileceğini unutmayın çünkü mesaj işleme zaman aşımı veya hizmet kesinti süresi ağdan olduğu kadar iş hizmetinden de alınabilir Bu nedenle güvenilir olay teslimi ve mesaj kuyruğu olayın en az bir kez teslim edilmesini sağlar. Burada, iş hizmetleri (tüketiciler) idempotence sağlamalıdır. İşletme hizmeti (tüketici) arayüzün idempotansını garanti etmezse, tekrarlanan gönderimler gibi anormal senaryolara yol açacaktır. Ek olarak, bağımsız mesaj servisi de yapabilir, mesaj servisini bağımsız olarak devreye alabilir, mesaj servisini farklı iş senaryolarına göre paylaşabilir ve tekrarlanan servis geliştirme maliyetini azaltabiliriz.
"Güvenilir olay modelinin" metodolojisini anladıktan sonra, anlayışımızı derinleştirmek için şimdi gerçek bir duruma bakıyoruz. İlk olarak, kullanıcı bir geri ödeme başlattığında, otomatik geri ödeme hizmeti bir geri ödeme olay mesajı alır. Bu durumda, geri ödeme otomatik geri ödeme politikasını karşılıyorsa, otomatik geri ödeme hizmeti kalıcı olması için önce yerel veritabanına yazar. Bu geri ödeme anlık görüntüsü, mesaj kuyruğuna bir geri ödeme yürütme mesajı gönderdikten hemen sonra, mesaj kuyruğu mesajı aldıktan sonra başarılı bir yanıt verir, ardından otomatik geri ödeme hizmeti sonraki iş mantığını çalıştırabilir. Aynı zamanda, mesaj kuyruğu eşzamansız olarak mesajı geri ödeme temel hizmetine iletir ve ardından geri ödeme temel hizmeti kendi işle ilgili mantığını yürütür. Yürütme hatası, geri ödeme temel hizmeti tarafından garanti edilir. Yürütme başarılı olursa, bir geri ödeme yürütmesi gönderir. Başarılı mesaj, mesaj kuyruğuna teslim edilir. Son olarak, zamanlanan görev, veritabanını belirli bir süre içinde bitmemiş mesajlar için tarayacak ve bunları yeniden teslim edecektir. Burada, otomatik geri ödeme hizmetinin kalıcı geri ödeme anlık görüntüsünün, başarılı bir teslimatı sağlaması gereken bir mesaj olarak anlaşılabileceği ve "ileri ve geri mesaj mekanizması" ve "zamanlanmış görev", bunun başarılı bir şekilde teslim edilmesini sağladığına dikkat edilmelidir. Ek olarak, gerçek geri ödeme ödeme mantığı temel geri ödeme hizmeti tarafından garanti edilir, bu nedenle ödeme mantığının idempotence ve yakınsamasını sağlamalıdır. Yürütme hatası durumu ortaya çıktığında ve yeniden deneme sayısı aşıldığında, bu, görevin kalıcı olarak başarısız olduğu ve geliştirici tarafından manuel müdahale ve sorun giderme gerektirdiği anlamına gelir.
Özetlemek gerekirse, bir mesaj kuyruğunun devreye girmesi güvenilir olay teslimatını garanti etmez. Diğer bir deyişle, ağ gibi çeşitli nedenlerden dolayı mesajların kaybolması nihai tutarlılığını garanti edemez. Bu nedenle, "ileri ve geri mesaj mekanizması" ile sağlamamız gerekir. Mesaj kuyruğu güvenilir olaylar sunar ve bitmemiş mesajları belirli bir süre içinde yeniden teslim etmek için bir telafi mekanizması kullanır.
4 Açık kaynaklı projelerin dağıtılmış işlem gerçekleştirmesinin yorumlanması
Açık kaynaklı projelerde dağıtılmış işlemlerin uygulanmasından öğrenebileceğimiz ve öğrenebileceğimiz birçok şey var. Bu bölümde, uygulamasını yorumlayacağız.
RocketMQ
Apache RocketMQ, Ali tarafından sağlanan açık kaynaklı, yüksek performanslı, yüksek verimli bir dağıtılmış mesajlaşma ara yazılımıdır. Yıllar boyunca Double 11 sırasında RocketMQ, Alibaba'nın üretim sisteminin tüm mesaj akışını üstlendi, temel işlem bağlantısında istikrarlı ve olağanüstü bir performansa sahip ve en yüksek işlemi gerçekleştiren temel temel ürünlerden biri. RocketMQ ayrıca, Alibaba Cloud üzerinden satın alınabilen ticari bir MQ sürümüne de sahiptir. Alibaba'nın açık kaynak sürüm ile ticari sürüm arasındaki temel farkı, dağıtılmış mesajlaşmanın tüm temel özelliklerini açık kaynak olarak sunmasıdır. Ticari düzeyde, özellikle bulut platformlarının inşasında, İşletme ve bakım kontrolü, güvenlik yetkilendirmesi ve derinlemesine eğitim, işletmenin en önemli öncelikleri arasındadır.
Apache RocketMQ sürüm 4.3 resmi olarak dağıtılmış işlem mesajlarını destekler. RocketMQ işlem mesajı tasarımı, esas olarak üretici tarafında mesaj gönderme ve yerel işlem yürütme atomiklik problemini çözer, başka bir deyişle, yerel işlem başarılı bir şekilde gerçekleştirilmezse, MQ mesaj itme işlemi gerçekleştirilmez. Yani, akıllıca sorularınız olabilir: önce yerel işlemleri gerçekleştirebiliriz ve ardından yürütme başarılı olduktan sonra MQ mesajları gönderebiliriz, böylece işlem özellikleri garanti edilemez? Ancak, lütfen dikkatlice düşünün, MQ mesajı başarıyla gönderilmezse ne yapmalısınız? Aslında RocketMQ bunun için iyi bir fikir ve çözüm sağlar. RocketMQ, önce MQ'ya bir yürütme öncesi mesajı gönderecek ve yürütme öncesi mesajını başarıyla gönderdikten sonra yerel işlemi gerçekleştirecektir. Daha sonra, yerel işlemin yürütme sonucuna bağlı olarak sonraki yürütme mantığını gerçekleştirir.Yerel işlemin yürütme sonucu kesin ise, MQ mesajı resmi olarak teslim edilir.Yerel işlemin yürütme sonucu geri alınırsa, MQ daha önce teslim edilmiş olan önceden yürütülen mesajı siler ve bir sonraki mesajı teslim etmez. saç. RocketMQ'nun, yerel işlemlerin yürütülmesi sırasında sunucu kesintisi veya zaman aşımı gibi anormal durumlar için sürekli olarak aynı gruptaki diğer üreticilerden durum almalarını isteyeceğini unutmayın.
ServiceComb
ServiceComb, Huawei'nin dahili CSE (Bulut Hizmeti Motoru) çerçevesine dayanan açık kaynak kodludur.Kod çerçevesi oluşturma, hizmet kaydı bulma, yük dengeleme, hizmet güvenilirliği (hataya dayanıklı birleştirme, mevcut sınır bozulması, çağrı zinciri izleme) gibi bir dizi işlev sağlar. Mikro hizmet çerçevesi. Bunların arasında ServiceComb Saga, mikro hizmet uygulamaları için nihai bir veri tutarlılığı çözümüdür.
Saga, dağıtılmış işlemleri birden fazla yerel işleme ayırır ve ardından koordinasyondan Saga motoru sorumludur. Tüm süreç normal şekilde sona ererse, iş başarıyla tamamlanır; bu işlem sırasında uygulamanın bir kısmı başarısız olursa, Saga motoru tazminat işlemini başlatır. Saga'nın iki kurtarma stratejisi vardır: ileri kurtarma ve geriye dönük kurtarma. Bunlar arasında, ileri kurtarma, veritabanının çalışmasının sonunda veri tutarlılığını garantilemek için başarısız düğümü sürekli olarak yeniden denemek için en iyi çabayı gösterir.Son yeniden deneme birden çok kez başarısız olursa, geliştirici, ilgili günlüğe dayalı olarak manuel müdahale için geliştiriciyi aktif olarak bilgilendirebilir. Verilerin tutarlı sonuçlar elde etmesini sağlamak için daha önce başarılı olan tüm düğümlerde geri alma işlemi işlemini gerçekleştirmek için geriye doğru devam edin.
Saga ve TCC arasındaki fark, Saga'nın TCC'den bir tane daha az Try işlemine sahip olmasıdır. Bu nedenle, Saga doğrudan veri tabanına gönderecek ve başarısız olduğunda tazminat işlemleri gerçekleştirecektir. Saga'nın tasarımı, aşırı senaryolarda daha zahmetli tazminat eylemlerine yol açabilir, ancak basit iş mantığı için daha az müdahaleci, daha hafiftir ve iletişim sayısını azaltır.
ServiceComb Saga, teorik temeline göre genişletilmiştir ve iki bileşen içerir: alfa ve omega. Alpha, esas olarak işlem olaylarının kalıcı olarak saklanmasından ve alt işlemlerin durumunu koordine etmekten sorumlu olan bir koordinatör olarak hareket eder, böylece nihayetinde küresel işlemin durumu ile tutarlı olabilir. Omega, mikro hizmetlere gömülü bir aracıdır, ağ taleplerini yakalamaktan ve işlem olaylarını alfa'ya bildirmekten ve anormal durumlarda alfa tarafından verilen talimatlara göre karşılık gelen tazminat işlemlerini gerçekleştirmekten sorumludur. Ön işleme aşamasında alfa, işlemin başladığı andaki olayı kaydedecektir; işlem sonrası aşamasında alfa, işlem bittiğinde olayı kaydedecektir. Bu nedenle, her başarılı alt işlem, bire bir karşılık gelen başlangıç ve bitiş olayına sahiptir. Hizmet üreticisinde, omega, işlemin içeriğini çıkarma talebinde işlemle ilgili kimliği yakalar. Hizmet tüketicisi tarafında, omega, işlemin içeriğini iletmek için talebe işlemle ilgili kimliği enjekte edecektir. Hizmet sağlayıcılar ve hizmet tüketicileri arasındaki bu işbirliğine dayalı işlem yoluyla, alt işlemler birbirine bağlanarak tam bir küresel işlem oluşturabilir. Saga'nın işlem işleme yöntemleri sağlamak ve tazminat işlevleri sağlamak için ilgili alt işlemleri gerektirdiğini unutmayın. Burada, omega yapılandırmasını başlatmak ve alfa ile bağlantı kurmak için @EnableOmega açıklamasını ekleyin. @SagaStart açıklamasını genel işlemin başlangıcına ekleyin ve ilgili ücret yöntemini belirtmek için alt işleme @Compensable ek açıklamasını ekleyin. Kullanım örneği: https://github.com/apache/servicecomb-saga/tree/master/saga-demo
@EnableOmega public class Uygulaması { public static void main (String args) { SpringApplication.run (Application.class, args); }} @Kafadergisi genel void xxx () {} @Compensable genel geçersiz transfer () {}Şimdi iş akış şemasına bir göz atalım, Şekil 6-17'ye bakın.
