Karınca Finansal Dağıtık İşlem Açık Kaynak SOFA ve Uygulama
Geçtiğimiz hafta dağıtılmış işlem Fescar, Seata'ya marka yükseltmesini duyurdu.Ant Financial, Seata 0.4.0'a TCC modunu ekledi ve gelecekte de girmeye devam edecek. SOFAMeetup Beijing Station'ın yerinde paylaşımına dayanan bu makale, Ant Financial'da dağıtılmış işlemlerin geliştirilmesini ve açık kaynak sürümünün planlanmasını açıklamaktadır.Umarım anlamanıza yardımcı olabilir.
Geçtiğimiz hafta, dağıtılmış işlem Fescar bir marka yükseltmesini duyurdu:
Teşekkürler Fescar ,
Merhaba Seata.
Seata şu anlama gelir: Tek noktadan dağıtılmış bir işlem çözümü olan Basit Genişletilebilir Otonom İşlem Mimarisi.
Proje adresi: https://github.com/seata/seata
Ant Financial, Seata 0.4.0'a TCC modunu ekledi ve gelecekte de giriş yapmaya devam edecek.
Herkesin anlamasına yardımcı olmak için, dağıtılmış işlemin açık kaynağından sorumlu kişi olan Shao Hui, herkesin dağıtılmış işlemi anlamasına yardımcı olmayı umarak, Ant Financial'da dağıtılmış işlemin gelişimini ayrıntılı olarak açıklayan çevrimdışı bir paylaşım gerçekleştirdi, aşağıdaki paylaşım sürümünün metni.
Önsöz
Bugünün paylaşımı şu üç bölümden başlayacak: dağıtılmış işlem sorununun arka planı, Ant Financial'ın dağıtılmış işlemi ve dağıtılmış Seata işleminin Yol Haritası.
Paylaşım konuğu: Shao Hui, Ant Financial, Dağıtık İşler ve Açık Kaynak Başkanı
1. Dağıtılmış işlem sorununun arka planı
1.1, veritabanının yatay bölünmesi
Ant Financial'ın ilk günlerinde, iş hacmi nispeten küçüktü ve tek veritabanı ve tek tablo iş ihtiyaçlarını karşılayabiliyordu; ancak, işin gelişmesiyle birlikte, tek veritabanı ve tek tablo veritabanı yavaş yavaş bir darboğaz haline geldi. Veritabanının darboğaz problemini çözmek için veritabanını yatay olarak böleriz. Bölünmenin neden olduğu sorunlardan biri, geçmişte bir veritabanında yapılabilen yazma işlemlerinin artık birden çok veritabanını kapsaması ve bu da veritabanları arası işlemler sorununu beraberinde getirmesidir.
1.2. Hizmet odaklı iş dağılımı
İlk günlerde, Ant Financial tek sistemli bir mimariye sahipti ve neredeyse tüm iş hizmetleri birkaç uygulamadaydı. İşin gelişmesiyle birlikte, iş gittikçe daha karmaşık hale geliyor ve hizmetler arasındaki bağlantı gittikçe artıyor, bu nedenle sistemi yeniden yapılandırdık ve hizmetler, işlevlerine göre ayrıştırılıp dikey olarak bölünüyor. Bölünmeden sonraki sorun, bir ticari faaliyetin yalnızca bir hizmeti arayarak tamamlanabilmesidir, ancak şimdi birden çok hizmeti arayarak tamamlanması gerektiğidir, bu da hizmetler arası işlem sorunu yaratır.
1.3. Transfer vakası, veri tutarlılığı sorunlarını gösterir
Veri tabanlarının su bölünmesi ve hizmetlerin dikey olarak bölünmesi sorunu, bir iş faaliyetinin tamamlanması için genellikle birden çok hizmeti çağırması ve birden çok veri tabanına erişmesi gerektiğidir.
Finansal işletme senaryosundaki transfer senaryosunu örnek olarak alırsak, transfer hizmetinin aşağıdaki işlemleri tamamlaması gerekir:
Yukarıdaki 4 işlemin 3 sistemi kapsaması ve 4 veritabanına erişmesi gerekir. Bununla birlikte, ağlar, veritabanları, makineler vb. Güvenilir değildir ve yukarıdaki dört işlemin% 100 başarısını garanti etmemiz bizim için zor.
Mali nitelikler işinde, A hesabındaki paranın düşülmesine izin verilmez ve B hesabındaki para eklenmez, bu nedenle 1'den 4'e kadar dört işlemin tamamının başarılı olmasını veya tümünün başarısız olmasını sağlamanın bir yolunu bulmalıyız; bu nedenle Ant Financial, hizmetler ve veritabanları arasında veri tutarlılığı sorununu çözmek için bağımsız olarak dağıtılmış işlem ara yazılımı geliştirdi.
2. Finansal Dağıtık İşlem
2.1, dağıtılmış işlemlerin teorik temeli
Ant Financial'ın dağıtılmış işlem ara yazılımını tanıtmadan önce, ilk olarak dağıtılmış işlemin bazı teorik altyapısını tanıtın.
- 2PC
İki Aşamalı Taahhüt Protokolü, dağıtılmış işlemler için en temel protokoldür. İki aşamalı kesinleştirme protokolünde, bir işlem yöneticisi ve birden çok kaynak yöneticisi vardır İşlem yöneticisi, kaynak yöneticilerini iki aşamada koordine eder. İlk aşamada, işlem yöneticisi tüm kaynak yöneticilerine hazırlığın başarılı olup olmadığını sorar. Tüm kaynaklar başarılı bir şekilde hazırlanırsa, ikinci aşamada işlem yöneticisi tüm kaynak yöneticilerinin taahhüt etme işlemini gerçekleştirmesini isteyecektir; herhangi bir kaynak yöneticisi ilk aşamada hazırlıkta başarısız olursa, işlem yöneticisi tüm kaynak yöneticilerinin İkinci aşama, bir geri alma işlemi gerçekleştirir. İşlem yöneticisinin iki aşamalı koordinasyonu sayesinde, tüm kaynak yöneticileri ya taahhüt edilir ya da sonunda geri alınır ve son durum tutarlıdır.
- TCC
TCC (Dene-Onayla-İptal) arasında kaynak yöneticilerinin hizmet odaklı bir uygulaması olduğu kaynak yöneticilerini uygulamanın birçok yolu vardır. TCC, veri tabanları arası ve hizmetler arası iş operasyonlarının veri tutarlılığı sorununu çözmek için kullanılabilecek nispeten olgun bir dağıtılmış işlem çözümüdür. TCC'nin üç Deneme, Onayla ve İptal yönteminin tümü iş kodlamasıyla uygulanır, bu nedenle TCC'ye hizmet odaklı bir kaynak yöneticisi denilebilir.
TCCnin Deneme işlemi, kaynak inceleme ve rezervasyondan sorumlu olan ilk aşamadır; Onay işlemi, gerçek işi gerçekleştirmek için ikinci aşama gönderim işlemidir; İptal, ayrılmış kaynakların iptalini gerçekleştiren ve kaynakları başlangıç durumuna döndüren ikinci aşama geri alma işlemidir. .
Aşağıdaki şekilde gösterildiği gibi, kullanıcı TTK hizmetini uyguladıktan sonra, dağıtılmış işlemin tamamına katılmak için dağıtılmış işlemin kaynaklarından biri olarak TTK hizmeti kullanılacaktır. İşlem yöneticisi TTK hizmetlerini iki aşamada koordine eder.İlk aşamada tüm TTK hizmetlerinin Try yöntemi çağrılır, ikinci aşamada ise tüm TTK hizmetlerinin Onayla veya İptal yöntemi uygulanır.Sonuçta tüm TTK hizmetlerinin tamamı veya tümü sunulur. Hepsi geri alınır.
2.2. Ant Financial'ın Dağıtılmış Ürünlerine Giriş
Ant Financial 2007 yılında dağıtık işlemler yapmaya başladı ve 12 yıllık bir geçmişe sahip. Ant Financialın dağıtılmış işlemleri başlangıçta TCC kullanılarak uygulandı. TCC modeli, Antun işletmesinin çeşitli temel finansal senaryolarda veri tutarlılığı sorunlarını çözmesine yardımcı oldu.
2007 yılında Double Eleven'i desteklemeye başladık, Double Eleven'in yüksek performans gereksinimlerini karşılamak için dağıtılmış işlemler için bir dizi performans optimizasyonu yaptık.
2013 yılında, Ant Financial birimleştirilmiş dönüşüm gerçekleştirmeye başladı ve dağıtılmış işlemler aynı zamanda LDC, uzaktan çoklu etkinlik ve yüksek kullanılabilirlikli felaket kurtarmayı desteklemeye başladı, bu da bir bilgisayar odası arızası durumunda hızlı servis kurtarma sorununu çözdü.
2014 yılında Ant Financial'ın dağıtılmış işlem ara yazılımı, Ant Financial Cloud üzerinden ihracat yapmaya başladı ve çok sayıda harici kullanıcı geliştirdik; harici müşteriler geliştirme sürecinde, harici müşteriler performansın bir kısmını (karıncasız iş ölçeği) feda etme isteklerini ifade ettiler. Erişim kolaylığı ve müdahaleci olmama karşılığında.
2015 yılında, müdahaleci olmayan işlem çözümleri yapmaya başladık: FMT modu ve XA modu.
Uzun vadeli evrimin ardından, Ant Financial'ın dağıtılmış işlem ara yazılımı üç mod biriktirdi: Zengin uygulama senaryolarına sahip TCC, FMT ve XA. Üç mod aşağıda açıklanmıştır.
2.3, TCC modu
Ant Financial'ın TCC modeli, TCC teorisinin önceki girişinde bahsedilen TTK ilkesi ile tutarlıdır. Aradaki fark, dağıtılmış işlemin yürütülmesi sırasında işlem günlüğünü kaydedecek olmamızdır Dağıtılmış bir işlem, bir ana işlem kaydı (başlatıcıya karşılık gelen) ve birkaç şube işlem kaydı (TCC katılımcılarına karşılık gelen) oluşturacaktır. İşlem günlüğünün kaydedilmesinin amacı, dağıtılmış bir işlemin yürütülmesi sırasında anormal bir kesinti meydana geldiğinde, işlem kurtarma hizmetinin, anormal şekilde kesintiye uğramış işlemi bulmak ve anormal işlemin kalan tamamlanmamış eylemlerini telafi etmek için işlem günlüğünü taramasıdır. İşlemin son durumu ya tamamlandı ya da tamamı geri alındı.
TCC tasarım özellikleri ve önlemleri:
Kullanıcılar TCC'ye eriştiklerinde, çalışmalarının çoğu TCC hizmetlerinin nasıl uygulanacağına odaklanır. Ant Financial tarafından yıllarca süren TCC uygulama uygulamasından sonra, TTK tasarım ve uygulama sürecinde aşağıdaki hususları özetliyoruz:
1. İşletme operasyonu iki aşamada tamamlanır:
TTK'ya erişmeden önce, ticari işlemler tek adımda tamamlanabilir. Ancak, TCC'ye eriştikten sonra, onu iki aşamaya nasıl ayıracağınızı düşünmeniz gerekir: ilk aşama Deneme işleminde kaynakları kontrol edin ve ayırın ve gerçek iş işlemlerini ikinci aşama Doğrulama işlemine yerleştirin. bin.
Aşağıdaki örnek, iş modelinin iki aşamada nasıl tasarlandığını göstermektedir: Örnek bir senaryo: "A hesabının bakiyesinde 100 yuan vardır ve bunun 30 yuanının düşülmesi gerekir".
TCC'ye erişmeden önce kullanıcı, kesinti işlemini tek adımda tamamlamak için SQL: "hesap tablosunu güncelle bakiye ayarla = bakiye -20 burada hesap = A" yazar.
TCC'ye eriştikten sonra, kesinti işlemini iki adıma nasıl böleceğinizi düşünmeniz gerekir:
- İşlemi deneyin: kaynakları kontrol edin ve ayırın.
Kesinti senaryosunda, Try işleminde yapılacak şey, önce A hesabının bakiyesinin yeterli olup olmadığını kontrol etmek ve ardından mahsup edilecek 30 yuan'ı dondurmaktır (ayrılmış kaynaklar); bu aşamada gerçek bir kesinti olmayacaktır.
- İşlemi onaylayın: gerçek işletmenin sunumunu gerçekleştirin.
Kesinti senaryosunda, Doğrulama aşamasında yapılan, fiili kesintiyi düşürmek ve A hesabında dondurulmuş olan 30 yuan'ı mahsup etmektir.
- İşlemi iptal et: ayrılmış kaynakların serbest bırakılması.
Kesinti senaryosunda kesinti iptal edilir ve İptal işleminin görevi Deneme işleminde donmuş 30 yuan'ı serbest bırakmak ve A hesabını ilk durumuna döndürmektir.
2. Eşzamanlılık kontrolü
Kullanıcılar TCC'yi uygularken, eşzamanlılık sorunlarını dikkate almalı ve dağıtılmış işlemlerin eşzamanlılığını en üst düzeye çıkarmak için kilitlerin ayrıntı düzeyini en aza indirmelidir.
Aşağıda örnek olarak A hesabından yapılan kesinti hala örnek olarak alınmaktadır: "Hesap A'nın 100 yuan'ı var, T1 işleminin 30 yuan'i kesmesi gerekiyor, T2 işleminin de 30 yuan kesintisi yapması gerekiyor ve eşzamanlılık var."
Birinci aşama Try işleminde, sırasıyla dağıtılmış T1 işlemi ve dağıtılmış T2 işlemi fonların bir kısmını dondurur ve aralarında herhangi bir müdahale olmaz. Bu şekilde, dağıtılmış işlemin ikinci aşamasında, T1'in taahhüt edilmiş veya geri alınmış olmasına bakılmaksızın, T2'yi etkilemeyecektir, böylece T1 ve T2 aynı iş verileri üzerinde paralel olarak yürütülebilir.
3. Boş geri dönüşe izin ver
Aşağıdaki şekilde gösterildiği gibi, işlem koordinatörü TCC hizmetinin birinci aşama Deneme işlemini çağırdığında, paket kaybı nedeniyle bir ağ zaman aşımı meydana gelebilir. Bu zamanda, işlem yöneticisi, TCC hizmetinin İptal işlemini çağırarak iki aşamalı bir geri dönüşü tetikleyecektir ve işlem iptal çağrısı zaman aşımına uğramaz.
TCC hizmeti bir Deneme isteği almadan bir İptal isteği alır Bu senaryoya boş geri dönüş denir. Null geri alma genellikle üretim ortamında meydana gelir TCC hizmetini uygularken, kullanıcı boş geri dönüşün yürütülmesine izin vermelidir, yani boş geri dönüş alındığında geri dönüş başarılı olmalıdır.
4. Anti-asma kontrolü
Aşağıdaki şekilde gösterildiği gibi, işlem koordinatörü TCC hizmetinin birinci aşama Deneme işlemini çağırdığında, ağ tıkanıklığı nedeniyle bir zaman aşımı meydana gelebilir. Bu zamanda, işlem yöneticisi iki aşamalı bir geri dönüşü tetikleyecek, TCC hizmetinin İptal işlemini çağıracak ve İptal çağrısı zaman aşımına uğramayacaktır. Bundan sonra, ağda tıkanan birinci aşama Deneme paketi TCC hizmeti tarafından alınır ve ikinci aşama İptal isteği, birinci aşama Deneme isteğinden önce yürütülür Bu TCC hizmeti hiçbir zaman geç Dene isteğini yerine getirmez. Onayla veya İptal etmenin ikinci aşaması alınır ve TCC hizmetinin askıya alınmasına neden olur.
TCC hizmetini uygularken, kullanıcılar boş geri dönüşlere izin vermeli, ancak boş geri dönüşlerden sonra Dene isteğini gerçekleştirmeyi reddetmeli ve asmaktan kaçınmalıdır;
5. Idempotent kontrolü
Ağ veri paketinin yeniden iletimi veya anormal işlemlerin tazminat yürütülmesi olsun, TCC hizmetinin Deneme, Onayla veya İptal işlemlerinin tekrar tekrar yürütülmesine neden olacaktır; kullanıcıların, TCC hizmetini uygularken idempotent kontrolü, yani Deneme, Onayla, Yürütmeyi iptal etmeleri gerekir. İş sonucu bir kez aynıdır ve birden çok kez yürütülür.
2.4, FMT modu
FMT (Çerçeve tarafından yönetilen işlem), müdahaleci olmayan bir işlem çözümüdür. Bu modda, dağıtılmış işlem çerçevesi tüm işlem işlemlerini barındıracaktır. İşlemin birinci ve ikinci aşamaları çerçeve tarafından otomatik olarak üretilir Dağıtılmış işlemin ilk aşaması olarak Kullanıcı SQL'i kullanılacak ve ikinci aşama çerçeve tarafından otomatik olarak üretilecektir. Geri alma "işlemi.
1. FMT'nin ilk aşaması
FMT'nin ilk aşaması, dağıtılmış işlem çerçevesi tarafından otomatik olarak oluşturulur Dağıtılmış işlem çerçevesi, bir aşamada iş SQL ifadelerini engeller.İş yürütmeden önce, iş SQL değişikliğinden önceki veriler orijinal anlık görüntü olarak kaydedilir (geri alma günlüğü); SQL yürütüldükten sonra, güncellenen iş verileri yeni bir anlık görüntü (yineleme günlüğü) olarak kaydedilir ve son olarak, dağıtılmış işlemlerin eşzamanlılığını kontrol etmek için tablo adı + birincil anahtar değeri kullanılarak bir satır kilidi oluşturulur.
SQL anlambilimini ayrıştırmanın amacı, işletme tarafından güncellenecek iş verilerinin bulunmasını kolaylaştırmaktır; tablo meta verilerini çıkarmanın amacı, satır kilitlerinin oluşturulmasını kolaylaştırmak için iş tablosunun birincil anahtarını ve benzersiz kısıtlama anahtarını bulmaktır.
2. FMT İkinci Aşama
FMT modunda, ilk aşama, esas olarak, günlüğü geri alma ve günlüğü yineleme gibi ara verileri korumaktır ve bu ara verileri korumanın amacı, ikinci aşama işlemi oluşturmaktır.
- FTM iki aşamalı taahhüt
İkinci aşama kesinleştirme işlemi otomatik olarak oluşturulur İş SQL'i ilk aşamada veritabanına gönderildiği için, ikinci aşama kesinleştirme yalnızca ilk aşamada kaydedilen ara verileri (günlüğü geri alma, günlüğü yineleme ve satır kilidi) silmeye ihtiyaç duyar.
- FMT iki fazlı geri alma
İkinci aşama geri alma işlemi de otomatik olarak oluşturulur.Amaç, birinci aşama iş SQL'i tarafından güncellenen iş verilerini geri almak için geri alma günlüğünü kullanmaktır. Spesifik adımlar şunlardır:
Öncelikle, kirli yazıları doğrulamanız gerekir. Kirli yazma işlemlerini kontrol etme yöntemi, veritabanının mevcut değeri ile karşılaştırmak için yeniden günlüğü kullanır.İki veri parçası tam olarak aynıysa, kirli yazı olmadığı anlamına gelir.İki veri parçası tutarsızsa, kirli bir yazı var demektir; kirli bir yazı varsa, manuel olarak aktarılması gerekir. İşlendiğinde, geri alma günlüğü artık iş verilerini geri almak için kullanılamaz.
Ardından, iş verilerini geri yükleyin. Kirli yazı yoksa, iş verilerini geri almak ve iş verilerini orijinal değerine geri yüklemek için geri alma günlüğünü kullanın.
Son olarak, ara verileri silin. İş verileri geri yüklendikten sonra, geri alma işlemini tamamlamak için tüm ara veriler (geri alma günlüğü, yineleme günlüğü ve satır kilidi) silinebilir.
2.5, XA modu
XA modu, başka bir müdahaleci olmayan dağıtılmış işlem çözümüdür.FMT'den farklı olarak, XA modunda, tüm birinci ve ikinci aşamalar veritabanı tarafından tamamlanır. Karınca dağıtılmış işlem çerçevesi, birinci aşamadaki verilerin birinci aşama XA arayüzünü (xa hazırlama) ve ikinci aşamadaki verilerin ikinci aşama XA arayüzünü (xa yürütme / xa geri alma) çağırır.
XA modu aşağıdaki özelliklere sahiptir:
3. Ant Financial dağıtık işlere yatırım yapıyor Seata topluluğu ortak inşaatı
Alibaba ara katman ekibi, teknoloji birikimine dayalı olarak Ocak 2019'da, toplulukla dağıtılmış bir işlem çözümü oluşturmak için açık kaynak projesi Fescar'ı (Fast and EaSy Commit And Rollback, Fescar) başlattı. Fescar, mikro hizmet mimarisi altında dağıtılmış işlem sorununu çözmek için benzersiz bir yanıt sağladı. Fescar'ın vizyonu, dağıtılmış işlemlerin kullanımını yerel işlemlerin kullanımı kadar basit ve verimli hale getirmektir. Nihai hedef, Fescar'ı tüm dağıtılmış işlem senaryolarına uygulanabilir hale getirmektir.
Daha dağıtık işlem senaryolarına uygun olma hedefine ulaşmak için Ant Financial, TCC modelini oluşturmak ve katılmak için Fescar topluluğuna katıldı.
Ant Financial'ın eklenmesi, topluluğun çekirdek üyeleri arasında tartışmaları tetikledi.Tüm dağıtılmış işlem iş senaryolarına uygulanabilir olma hedefine ulaşmak ve topluluğun daha tarafsız, açık ve ekolojik açıdan zengin olması için, topluluğun çekirdek üyeleri markayı yükseltmeye ve adını değiştirmeye karar verdi. Seata. Seata şu anlama gelir: Tek noktadan dağıtılmış bir işlem çözümü olan Basit Genişletilebilir Otonom İşlem Mimarisi.
Açık kaynaktan beri Seata topluluk katkılarından yararlandı. Şimdiye kadar, dağıtılmış işlem Seata'nın 7000'den fazla Yıldızı ve 55'ten fazla Katkıda Bulunanı vardır.Geliştiricilerin katılımı, topluluk ekolojisini daha zengin ve daha dinamik hale getirdi.
Mayıs 2019'da Seata, sunucu tarafı HA küme desteği ekleyecek.O andan itibaren Seata, üretim ortamlarında kullanılan standartları karşılayabilir.
Dağıtılmış işlemler konusunda tutkulu olan geliştiriciler, birlikte inşa etmek ve Seata'ya daha fazla hayal gücü getirmek için topluluğa katılabilirler.
sonuç olarak
- Canlı video ve ayrıntılı PPT inceleme adresi: https://tech.antfin.com/activities/382
- GitHub adresi: https://github.com/seata/seata
