Günlük blog | Biri tekrar dağıtılmış işlemleri soruyor, bunu ona at
Önsöz
Böyle bir durumla hiç karşılaştın mı bilmiyorum Küçük bir dükkana bir şeyler almak için gittin ve parasını ödedin, ama dükkanın sahibi başka şeylerle uğraştığı için ödediğini unuttu ve tekrar ödemeni istedi. Ya da internetten alışveriş yaptığım zaman parayı zaten düşmüşümdür ama bu bana işlem olmadığını söylüyor. Bu tür durumlar hiçbir işlem yapılmamasından kaynaklanır. Bu, hayattaki olayların bazı önemini göstermektedir. Bir işiniz olduğunda, bir şey satın almak için küçük bir dükkana gidersiniz ve bu, onun için ödeme yapmak ve onu teslim etmek anlamına gelir. Bir işlemle, çevrimiçi alışverişe çıkarsınız ve kesinti bir sipariş işlemi oluşturur.
İşlemin özel tanımı
İşlem, bir faaliyette yer alan tüm işlemleri bölünmez bir yürütme birimine dahil etmek için bir mekanizma sağlar.Bir işlemi oluşturan tüm işlemler, yalnızca tüm işlemler normal şekilde yürütülebildiğinde sunulabilir. Herhangi bir işlem başarısız olduğu sürece, Tüm işlemin geri alınmasına neden olur. Basitçe ifade etmek gerekirse, işlemler "hiçbir şey yapma veya tümünü yapma (Hepsi veya Hiçbir Şey)" mekanizması sağlar.
Veritabanı yerel işlemi
ASİT
Veritabanı işlemleri söz konusu olduğunda, veritabanı işlemlerinin dört ana özelliği olan ACID'nin söylenmesi gerekir:
- A: Atomiklik
Bir işlemdeki tüm işlemler ya tamamlanmıştır ya da hiç tamamlanmamıştır ve bir ara bağlantıda sona ermeyecektir. İşlemin yürütülmesi sırasında bir hata oluşursa, işlem hiç yürütülmemiş gibi işlem başlamadan önceki duruma geri döndürülür (Geri Al).
Tıpkı bir şey satın aldığınızda olduğu gibi, malları birlikte ödemeli ve teslim almalısınız ya da göndermezseniz parayı iade edersiniz.
- C: Tutarlılık
İşlem tutarlılığı, veritabanının bir işlem gerçekleştirilmeden önce ve sonra tutarlı bir durumda olması gerektiği anlamına gelir. İşlem başarıyla tamamlanırsa, sistemdeki tüm değişiklikler doğru şekilde uygulanacak ve sistem geçerli durumda olacaktır. İşlemde bir hata oluşursa, sistemdeki tüm değişiklikler otomatik olarak geri alınır ve sistem orijinal durumuna geri döner.
- I: İzolasyon (İzolasyon)
Bu, eşzamanlı bir ortamda, farklı işlemler aynı verileri aynı anda işlediğinde, her işlemin kendi tam veri alanına sahip olduğu anlamına gelir. Eşzamanlı firmalar tarafından yapılan değişiklikler, diğer eşzamanlı firmalar tarafından yapılan değişikliklerden izole edilmelidir. Bir işlem veri güncellemelerini görüntülediğinde, verilerin durumu ya başka bir işlemin onu değiştirmesinden önceki durumdur ya da başka bir işlemin onu değiştirmesinden sonraki durumdur İşlem, ara durumdaki verileri görüntülemez.
Örneğin, bir şeyler satın alma meselesi diğer insanları etkilemez.
- D: Dayanıklılık
Bu, işlem başarıyla sona erdiği sürece, veritabanında yaptığı güncellemelerin kalıcı olarak kaydedilmesi gerektiği anlamına gelir. Bir sistem çökmesi meydana gelse bile, veritabanı sistemi yeniden başlatıldıktan sonra, veritabanı işlem başarıyla sona erdiğinde durumuna geri yüklenebilir.
Örneğin, bir şey satın aldığınızda, bunu deftere kaydetmeniz gerekir, patron bunu unutsa bile, iyi belgelenmiştir.
InnoDB uygulama prensibi
InnoDB, bir mysql depolama motorudur. Çoğu kişi mysql'e aşinadır. Aşağıda, veritabanı işlem uygulamasının bazı temel ilkelerine kısa bir giriş verilmiştir. Yerel işlemlerde, hizmetler ve kaynaklar, işlem paketi altında tek bir işlem olarak kabul edilebilir:
Yerel ilişkilerimiz kaynak yöneticisi tarafından yönetilir:
İşlemin ACID'si InnoDB günlükleri ve kilitleri ile garanti edilmektedir. İşlem izolasyonu, veritabanı kilitleme mekanizması ile sağlanır, kalıcılık, günlük yineleme (yineleme günlüğü) ile sağlanır ve geri alma günlüğü aracılığıyla atomiklik ve tutarlılık sağlanır. UndoLog prensibi çok basittir: İşlemlerin atomikliğini tatmin etmek için, herhangi bir veriyi çalıştırmadan önce, önce verileri bir yere yedekleyin (veri yedeklemesinin depolandığı bu yere UndoLog denir). Ardından verileri değiştirin. Bir hata oluşursa veya kullanıcı ROLLBACK deyimini yürütürse, sistem verileri işlem başlamadan önceki duruma geri yüklemek için Geri Alma Günlüğündeki yedeklemeyi kullanabilir. Günlüğü Geri Al'ın aksine, RedoLog yeni verilerin yedeğini kaydeder. İşlem gerçekleştirilmeden önce, yalnızca RedoLog'un sürdürülmesi gerekir ve verilerin kalıcı olması gerekmez. Sistem çöktüğünde, veriler kalıcı olmasa da, RedoLog devam etti. Sistem, RedoLog içeriğine göre tüm verileri en son duruma geri yükleyebilir. Spesifik uygulama süreciyle ilgilenen öğrenciler, kendi başlarına uzantıları arayabilirler.
Dağıtılmış işlem
Dağıtılmış işlem nedir
Dağıtılmış işlem, işlemin katılımcılarının, işlemi destekleyen sunucunun, kaynak sunucusunun ve işlem yöneticisinin farklı dağıtılmış sistemlerin farklı düğümlerinde yer alması anlamına gelir. Basitçe ifade etmek gerekirse, büyük bir işlem farklı küçük işlemlerden oluşur.Bu küçük işlemler farklı sunuculara dağıtılır ve farklı uygulamalara aittir.Dağıtılmış işlemler bu küçük işlemlerin başarılı veya başarısız olmasını sağlamalıdır. Temelde, dağıtılmış işlemler, farklı veritabanlarında veri tutarlılığını sağlamak içindir.
Dağıtılmış işlemlerin nedenleri
Yukarıdaki yerel işlem bakış açısından, bunu iki parça olarak görebiliriz, biri hizmet birden çok düğüm üretir ve diğeri kaynak birden çok düğüm oluşturur.
birden çok düğüme hizmet
İnternetin hızla gelişmesiyle birlikte, mikro hizmetler ve SOA gibi hizmet mimarisi modelleri büyük ölçekte kullanılmaktadır. Basit bir örnek olarak, bir şirket içinde, kullanıcıların varlıkları bakiyeler, puanlar, kuponlar vb. Gibi birden çok bölüme ayrılabilir. Bekle. Şirkette, puan işlevinin bir mikro hizmet ekibi tarafından ve kuponların başka bir ekip tarafından sürdürülmesi mümkündür.
Bu durumda, puanlar düşüldükten sonra kuponun başarıyla düşülebileceğinin garantisi yoktur.
birden çok düğümü kaynak
Benzer şekilde, İnternet çok hızlı gelişiyor Genel olarak konuşursak, Mysql'imiz on milyonlarca veriyi yüklediğinde, alt veritabanı ve alt tabloya ihtiyacımız var.Alipay transfer işi için, bir arkadaşınıza para transfer ederseniz, sizin olabilir. Veri tabanı Pekin'de ve arkadaşlarınızın parası Şangay'da, bu nedenle aynı anda başarılı olabileceklerini hala garanti edemiyoruz.
Dağıtılmış işlemlerin temeli
Yukarıdaki bakış açısıyla, internetin hızla gelişmesiyle birlikte dağıtılmış işlemler ortaya çıkmıştır.Bu kaçınılmazdır. Veritabanının dört ACID özelliğinin dağıtılmış işlemlerimizi artık tatmin edemeyeceğini söylemiştik. Şu anda bazı yeni büyükler var. Guy bazı yeni teoriler ortaya attı:
CAP
CAP teoremine Brewer's teoremi de denir. Dağıtılmış sistemler (yalnızca dağıtılmış işlemler değil) tasarlayan mimarlar için CAP, giriş teorinizdir.
- C (Tutarlılık): Belirli bir istemci için, bir okuma işlemi en son yazma işlemini döndürebilir. Farklı düğümlere dağıtılan veriler için, veriler bir düğümde güncelleniyorsa, en son veriler diğer düğümlerde okunabiliyorsa buna güçlü tutarlılık denir.Bir düğüm okumazsa Tutarsızlık dağıtılmış olsun.
- A (Kullanılabilirlik): Hatalı olmayan düğüm, makul bir süre içinde makul bir yanıt verir (bir hata ve zaman aşımı yanıtı değil). Kullanılabilirliğin iki anahtarı makul süre ve makul yanıttır. Makul süre, talebin süresiz olarak engellenemeyeceği ve makul bir süre içinde iade edilmesi gerektiği anlamına gelir. Makul bir yanıt, sistemin sonucu açıkça döndürmesi gerektiği ve sonucun doğru olduğu anlamına gelir Buradaki doğruluk, örneğin 40 yerine 50 döndürmesi gerektiği anlamına gelir.
- P (Bölüm hatası toleransı): Bir ağ bölümü oluştuğunda, sistem çalışmaya devam edebilir. Örneğin, bu kümede birden çok makine var ve bir makinede bir ağ sorunu var, ancak küme yine de normal şekilde çalışabilir.
CAP'ye aşina olan herkes, üçünün paylaşılamayacağını bilir. İlgileniyorsanız, CAP kanıtını arayabilirsiniz. Dağıtılmış bir sistemde, ağ% 100 güvenilir olamaz. Bölümleme aslında kaçınılmaz bir fenomendir. CA'yı seçer ve P'den vazgeçersek, Daha sonra, bölme olgusu oluştuğunda, tutarlılığı sağlamak için, istek şu anda reddedilmelidir, ancak A buna izin vermez, bu nedenle teorik olarak dağıtılmış sistemde CA mimarisini seçmek imkansızdır ve yalnızca CP veya AP mimarisini seçebilir.
CP için, kullanılabilirlikten vazgeçip tutarlılık ve bölüm hata toleransı peşinde koşarak, hayvanat bahçesi görevlimiz aslında güçlü bir tutarlılık peşinde koşuyor.
AP için, tutarlılıktan vazgeçmek (burada belirtilen tutarlılık güçlü tutarlılıktır) ve bölüm hata toleransı ve kullanılabilirliğini takip etmek, birçok dağıtılmış sistemin tasarım seçimidir.Aşağıdaki BASE, AP'ye göre genişletilmiştir.
Bu arada, CAP teorisi ağ gecikmesini göz ardı eder, yani işlem sunulduğunda, A düğümünden B düğümüne kopyalanır, ancak gerçekte bu açıkça imkansızdır, bu nedenle her zaman belirli bir süre tutarsızlığı olacaktır. Aynı zamanda CAP'de iki tane seçmek, örneğin CP'yi seçerseniz, sizden A'dan vazgeçmenizi istemez. P görünme olasılığı çok düşük olduğundan, yine de çoğu zaman CA'yı garanti etmeniz gerekir. Bölüm görünse bile, sonraki A için hazırlanmanız gerekir, örneğin, bazı kayıt araçlarıyla, diğer makineler kullanılabilir olması için geri yüklenir.
TABAN
BASE, Temelde Kullanılabilir, Yumuşak durum ve Sonunda tutarlı üç ifadenin kısaltmasıdır. CAP'deki AP'nin bir uzantısıdır
BASE, CAP'de ağ gecikmesi olmadığı teorisini çözer ve gecikmeden sonra tutarlılığı sağlamak için BASE'de yumuşak durumu ve nihai tutarlılığı kullanır. BASE ve ACID tam tersidir, ACID'in güçlü tutarlılık modelinden tamamen farklıdır, bunun yerine güçlü tutarlılıktan ödün vererek kullanılabilirlik kazanır ve verilerin bir süre tutarsız olmasına izin verir, ancak sonunda tutarlı bir duruma ulaşır.
Dağıtılmış işlem çözümü
Yukarıdaki teorik temelle, birkaç yaygın dağıtılmış işlem çözümüne giriş burada.
Gerçekten dağıtılmış işlemler istiyor musunuz
Çözümden bahsetmeden önce, gerçekten dağıtılmış işlemlere ihtiyacınız olup olmadığını açıkça belirtmelisiniz.
Yukarıda dağıtılmış işlemlerin iki nedeni belirtilmiştir, bunlardan biri çok fazla mikro hizmet olmasıdır. Tek bir kişi tarafından birkaç mikro hizmeti sürdüren çok fazla ekip gördüm, çok fazla ekip aşırı tasarım yapıyor, herkesi yoruyor ve çok fazla mikro hizmet dağıtılmış işlemlere yol açacak. Şu anda aşağıdakilerden herhangi birini kullanmanızı önermeyeceğim Bir çözüm, ancak lütfen işlem gerektiren mikro hizmetleri, veritabanının yerel işlemini kullanarak tek bir sunucuda toplayın. Çünkü ne tür bir şema sisteminizin karmaşıklığını artıracak olursa olsun, maliyet çok yüksektir.Belirli tasarımların peşinden koştuğunuz için gereksiz maliyet ve karmaşıklık getirmeyin.
Dağıtılmış işlemleri başlatmanız gerektiğinden eminseniz, aşağıdaki ortak çözümlere bakabilirsiniz.
2PC
2PC'den bahsetmişken, veritabanı dağıtımlı işlemlerde XA İşlemlerinden bahsetmek zorundayım.
XA protokolünde iki aşama vardır:
İlk aşama: İşlem yöneticisi, işleme dahil olan her veri tabanının bu işlemi önceden başlatmasını (önceden taahhüt etmesini) ve bunun gerçekleştirilip gerçekleştirilemeyeceğini yansıtmasını gerektirir.
İkinci aşama: İşlem koordinatörü, her bir veritabanının verileri göndermesini veya verileri geri almasını ister.
Avantajlar: Verilerin güçlü tutarlılığını sağlamaya çalışın ve uygulama maliyeti düşüktür.Büyük ana veri tabanlarında kendi uygulaması vardır. MySQL 5.5'ten desteklenir.
Dezavantajları:
- Tek nokta problemi: İşlem yöneticisinin tüm süreçteki rolü çok önemlidir.Örneğin, ilk aşama tamamlanmışsa ve ikinci aşama tamamlanmak üzereyken işlem yöneticisi aşağı inerse, kaynak yöneticisi Engellendi ve veritabanının kullanılamaz hale gelmesine neden oldu.
- Eşzamanlı engelleme: Hazır olduktan sonra, kaynak yöneticisindeki kaynak gönderim tamamlanıncaya ve kaynak serbest bırakılıncaya kadar engellenmiştir.
- Veri tutarsızlığı: İki aşamalı kesinleştirme protokolü, dağıtılmış verilerin güçlü tutarlılığı için tasarlanmış olsa da, yine de veri tutarsızlığı olasılığı vardır.Örneğin, ikinci aşamada, koordinatörün bir işlem gerçekleştirme bildirimi gönderdiğini, ancak bildirimin ağ sorunlarından kaynaklandığını varsayalım. Katılımcıların yalnızca bir kısmı kesinleştirme işlemini aldı ve gerçekleştirdi ve geri kalan katılımcılar bildirimi almadıkları için bloke durumundaydı. Şu anda veri tutarsızlığı meydana geldi.
Genel olarak, XA protokolü nispeten basit ve düşük maliyetlidir, ancak tek nokta sorunu ve yüksek eşzamanlılığı destekleyememesi (eşzamanlı engelleme nedeniyle) hala en büyük zayıflıklarıdır.
TCC
TCC (Dene-Onayla-İptal) kavramı ilk olarak Pat Helland tarafından 2007 yılında yayınlanan "Dağıtılmış İşlemlerin Ötesinde Yaşam: Bir Mürted Görüşü" başlıklı bir makalede önerilmiştir. Yukarıda sunulan XA ile karşılaştırıldığında, TCC işlem mekanizması birkaç eksikliği çözer: 1. Koordinatörün ana iş tarafı tarafından başlatılan ve tamamlanan tek noktasını çözer. İş faaliyeti yöneticisi de çok noktalı hale geldi ve kümeleri tanıttı. 2. Eşzamanlı engelleme: Bir zaman aşımı girin, zaman aşımından sonra telafi edin ve tüm kaynağı kilitlemeyecek, kaynağı bir iş mantığı biçimine dönüştürmeyecek ve ayrıntı düzeyini azaltmayacaktır. 3. Ücretlendirme mekanizması ile veri tutarlılığı, tutarlılık iş faaliyeti yöneticisi tarafından kontrol edilir
TTK Açıklaması:
- Deneme aşaması: Tüm iş kontrollerini (tutarlılık) gerçekleştirmeyi, tamamlamayı ve gerekli iş kaynaklarını (yarı izolasyon) ayırmayı deneyin
- Onaylama aşaması: İşin fiili yürütmesinin yürütülmesini herhangi bir iş kontrolü olmadan onaylayın, yalnızca Deneme aşamasında ayrılmış iş kaynaklarını kullanın ve Onaylama işlemi idempotence karşılar. Idempotent tasarımı gereklidir ve Onaylama başarısız olduktan sonra yeniden deneme gerekir.
- İptal aşaması: Yürütmeyi iptal edin ve Deneme aşamasında rezerve edilen iş kaynaklarını serbest bırakın İptal işlemi, İptal aşamasındaki istisnaların idempotansını karşılar ve Onay aşamasındaki istisna işleme şeması temelde aynıdır.
Basit bir örnek vermek gerekirse, 100 yuan'a bir şişe su alırsanız, Deneme aşaması: Cüzdanınızla 100 yuan olup olmadığını kontrol etmeniz ve 100 yuan'ı kilitlemeniz gerekir. Aynı şey su için de geçerlidir.
Biri başarısız olursa, iptal edin (100 yuan'ı ve su şişesini bırakın) İptal başarısız olursa, iptal, başarısızlıktan bağımsız olarak yeniden denenecektir, bu yüzden idempotent olması gerekir.
Her şey başarılıysa, onaylayın, 100 yuan kesintisinin ve su şişesinin satıldığını onaylayın, onay başarısız olursa, ne olursa olsun, sonra yeniden deneyin (yeniden denemek için etkinlik günlüğüne güvenecektir)
Bazıları TCC için uygundur:
- Aktif iş için güçlü izolasyon ve sıkı tutarlılık gereksinimleri.
- Kısa vadeli iş
Uygulama referansı: ByteTCC: https://github.com/liuyangming/ByteTCC/
Yerel mesaj tablosu
Yerel mesaj tablosu çözümü, aslında eBay'in eBay https://queue.acm.org/detail.cfm?id=1394128 tarafından önerilen eksiksiz çözümüydü.
Bu çözümün özü, ileti günlükleri aracılığıyla dağıtılmış işlem gerektiren görevleri eşzamansız olarak yürütmektir. Mesaj günlüğü yerel bir metin, veri tabanı veya mesaj kuyruğunda saklanabilir ve ardından yeniden deneme iş kuralları aracılığıyla otomatik veya manuel olarak başlatılabilir. Manuel yeniden denemeler daha çok ödeme senaryolarında kullanılır ve mutabakat sistemi olay sonrası sorunları ele almak için kullanılır.
Yerel mesaj kuyruğunun özü, büyük işlemleri küçük işlemlere dönüştürmektir. 100 yuan ile bir şişe su satın alma örneğini ele alalım.
1. Parayı düşürdüğünüzde, parayı keseceğiniz sunucuya yeni bir yerel mesaj tablosu eklemeniz gerekir.Kestirilen paranızı koymanız ve yerel mesaj tablosuna aynı işlemin içine yazmanız gerekir (bağlı olarak Veritabanı yerel işlemleri tutarlılığı sağlar.
2. Şu anda, yerel işlem tablosunu yoklamak, gönderilmemiş mesajları emtia envanter sunucusuna göndermek ve ondan su envanterini çıkarmasını istemek için planlanmış bir görev vardır.Mal sunucusuna ulaştıktan sonra, bu sefer önce sunucunun işlemini yazmalıdır. Tablo ve ardından kesinti başarılı olduktan sonra, işlem tablosundaki durumu güncelleyin.
3. Ürün sunucusu, mesaj tablosunu normal bir görev aracılığıyla tarar veya doğrudan kesinti sunucusunu bilgilendirir ve kesinti sunucusunun yerel mesaj tablosu durumu günceller.
4. Bazı anormal durumlar için, başarısız olarak işlenen mesajları periyodik olarak tarayın ve tekrar gönderin. Emtia sunucusu mesajı aldıktan sonra, ilk olarak mükerrer olup olmadığına karar verir. Eğer alınmışsa, uygulanıp uygulanmayacağına karar verilir ve yürütülürse derhal bilgilendirilir. İşlem gerçekleştirilmezse, idempotence sağlamak için işletme tarafından yeniden yürütülmesi gerekir, yani fazladan şişe su düşülmez.
Yerel mesaj kuyruğu BASE teorisine dayanır ve tutarlılık için düşük gereksinimleri olanlar için uygun olan nihai tutarlı modeldir. Bu modeli uygularken yeniden denemelerin idempotansına dikkat etmek gerekir.
MQ işlemi
Dağıtılmış işlem RocketMQ'da gerçekleştirilir. Aslında, yerel mesaj tablosu paketidir.Yerel mesaj tablosu MQ'nun içine taşınır. İşte MQ işlemine kısa bir giriş. Bu konuda daha fazla bilgi edinmek istiyorsanız lütfen şu adrese bakın: https: // www.jianshu.com/p/453c6e7ff81c.
Temel süreç şu şekildedir: Hazırlanan mesajın ilk aşamasında mesajın adresi alınacaktır.
İkinci aşama yerel işleri yürütür.
Üçüncü aşama, mesaja erişmek ve durumu değiştirmek için ilk aşamada elde edilen adresi kullanır. Mesaj alıcısı mesajı kullanabilir.
Onay mesajı başarısız olursa, RocketMq Broker durumu güncellemeyen mesajlar için düzenli bir tarama sağlar.Bir mesaj onaylanmazsa, gönderene rocketmq'de bir dinleyici şeklinde gönderilip gönderilmeyeceğini belirlemek için mesajı gönderene bir mesaj gönderir. , İşlemek için kullanılır.
Tüketim zaman aşımına uğrarsa, her zaman yeniden denemeniz gerekir ve mesaj alıcısının idempotent olması gerekir. Mesaj tüketimi başarısız olursa, bunun manuel olarak işlenmesi gerekecektir, çünkü olasılık düşüktür Bu karmaşık süreci bu kadar küçük bir zaman olasılığı için tasarlarsanız, kazanç kayba değmez.
Saga işleri
Saga, 30 yıl önce bir veri tabanında etik olarak bahsedilen bir kavramdır. Ana fikir, uzun işlemi Saga işlem koordinatörü tarafından koordine edilen birden fazla yerel kısa işleme bölmektir. Normalde biterse, normal şekilde tamamlanacaktır. Bir adım başarısız olursa, tazminat işlemi bir kez ters sırada çağrılacaktır. Saga'nın bileşimi:
Her Saga bir dizi alt işlem Ti'den oluşur. Her Ti'nin karşılık gelen bir tazmin işlemi Ci vardır. Telafi işlemi, Ti'nin neden olduğu sonucu geri almak için kullanılır. Buradaki her T yerel bir işlemdir. Gördüğünüz gibi, TCC ile karşılaştırıldığında, Saga'nın "ayrılmış deneme" eylemi yoktur ve Ti'si doğrudan kütüphaneye gönderilir.
Saga'nın iki yürütme dizisi vardır:
T1, T2, T3, ..., Tn
T1, T2, ..., Tj, Cj, ..., C2, C1, burada 0 < j < n Saga iki kurtarma stratejisi tanımlar:
Geriye doğru kurtarma, yani yukarıda bahsedilen ikinci yürütme dizisi, burada j, hatanın meydana geldiği alt işlemdir Bu yaklaşımın etkisi, tüm Saga'nın yürütme sonucunun iptal edilmesi için önceki tüm başarılı alt işlemlerin iptal edilmesidir. İleri kurtarma, başarılı olması gereken senaryolar için uygun, yürütme sırası şuna benzer: T1, T2, ..., Tj (başarısız), Tj (yeniden deneme), ..., Tn, burada j bir hatadır Alt işlem. Bu durumda Ci gerekli değildir.
Burada, saga modunda izolasyonun garanti edilemeyeceğine dikkat edilmelidir, çünkü hiçbir kaynak kilitli değildir, diğer işlemler hala mevcut işlemi kapsayabilir veya etkileyebilir.
100 yuan'a bir şişe su satın alma örneğini ele alalım, işte tanım
T1 = 100 yuan kesinti T2 = kullanıcıya bir şişe su ekleyin T3 = stoktaki bir şişe suyu azaltın
C1 = 100 yuan ekle C2 = kullanıcıya bir şişe su çıkar C3 = envantere bir şişe su ekle
Bir seferde T1, T2 ve T3 yapıyoruz, bir problem oluşursa C işleminin tersini problemin oluştuğu yerde gerçekleştiriyoruz. Yürütme T3'e ulaştığında bu zamanda bir geri alma işlemi yapmanız gerekirse, ancak kullanıcı suyu içmişse (başka bir işlem), yukarıda belirtilen izolasyon sorunu, geri alma sırasında kullanıcıyı bir azaltamayacağınızı göreceksiniz. Bir şişe su. Bu, işlemler arasında izolasyon olmaması sorunudur
Destan modunun izolasyon üzerinde büyük bir etkisi olmadığı görülebilir.Huawe'nin çözümüne başvurabilirsiniz: işletme seviyesinden başlayarak, bir Oturum ekleme ve işletim kaynaklarının serileştirilebilmesini sağlamak için kilitleme mekanizması. Fonları önceden dondurarak bu kaynakları işletme düzeyinde izole etmek de mümkündür ve son olarak iş operasyonları sürecinde, mevcut durumu zamanında okuyarak en son güncellemeler elde edilebilir.
Belirli örnekler: Huawei'nin servis tarağına başvurabilirsiniz
Sonunda
Yine, dağıtılmış işlemlere ihtiyacınız yoksa, buna gerek yoktur.Eğer onu kullanmak zorunda kalırsanız, güçlü tutarlılığı veya nihai tutarlılığı önemsiyor olun, hangisinin işletmeniz için daha uygun olduğunu görmek için kendi iş analizinizi birleştirin. Yukarıdaki çözümler sadece bazı basit tanıtımlardır.Eğer gerçekten inmek istiyorsanız, aslında her çözümün çok düşünmesi gerekir ve karmaşıklık nispeten büyüktür, bu nedenle dağıtılmış işlemleri kullanıp kullanmayacağınıza karar vermenizi tekrar hatırlatırım. Son olarak, bazı soruları özetlerken, aşağı inip makaledeki cevapları kendiniz bulabilirsiniz:
- Dağıtılmış işlem neden ortaya çıkıyor? Çözmek için hangi acı noktaları kullanılıyor?
Blog yazarı: Kahve latte'nin teknoloji paylaşımı
Günlük blog sütunu, her gün sizin için mükemmel blog yazarlarından yüksek kaliteli teknik makaleler önerir. Aynı zamanda, kullanıcılar katkıda bulunabilirler.Makale resmi hesaba eklendikten sonra, web sitesinin ana sayfasında bunu tavsiye edeceğiz. Her gün yüksek kaliteli baskılar almak için açık kaynaklı China OSC'yi takip edin, tıklayın " daha fazlasını anla "Orijinal makaleyi okuyun.
