Dağıtık İşlem Analizi
Luo Zhaocai, Temmuz 2016'da Qunar.com'un teknik ekibine katıldı. Şu anda tren bileti işletme departmanında / teknik departmanında, tren bileti sisteminin servis bölünmesi, veritabanı ara yazılımı ve günlük sistemi yapımında yer alıyor ve sistem performans optimizasyonu ve yüksek eşzamanlılık sistemleri ile ilgileniyor. Şahsen açık hava ve müzik gibi.
Giriş
Benim izlenimime göre, işlem pek çok kavram, ilke ve model olduğu için iyi anlaşılmamış bir kavramdır.Bu makale, işlem kavramları, özellikler, yerel işlem uygulama ilkeleri, Bahar işlemleri ve dağıtılmış işlemler dahil olmak üzere işlemlerle ilgili bilgileri sıralar. Model ve ilgili açık kaynak uygulama analizi.
Bağımsız işlem
Dağıtık işlem, tek makineli işlem temelinde inşa edilir ve genişletilir, bu nedenle öncelikle ilgili kavramları ve tek makineli işlemin temel uygulama ilkelerini anlamak gerekir.
İşlem özellikleri kavramı
İşlemlerden bahsetmişken, işlemlerin sağladığı ACID özelliklerinden bahsetmeliyiz. Wikipedia, ACID işlem çiftlerini aşağıdaki gibi tanımlar:
1. Atomiklik : İşlem bir bütün olarak yürütülür ve içerdiği veritabanı üzerindeki işlemlerin tümü gerçekleştirilir veya yürütülmez.
2. Tutarlılık : İşlem, veri tabanının durumunun tutarlı bir durumdan başka bir tutarlı duruma değişmesini sağlamalıdır. Tutarlı durumun anlamı, veritabanındaki verilerin bütünlük kısıtlamalarına uyması gerektiğidir.
3. İzolasyon : Birden fazla işlem aynı anda yürütüldüğünde, bir işlemin yürütülmesi diğer işlemlerin yürütülmesini etkilememelidir.
4. Dayanıklılık : Veritabanına taahhüt edilen işlemin değişiklikleri veritabanında kalıcı olarak depolanmalıdır.
Özelliklerin anlaşılması
İşlemlerin ACID'sini anlamak, işlemleri anlamanın anahtarıdır.Aynı zamanda, dağıtılmış işlemlerde ACID, aynı zamanda, tek makineli işlemlerin ACID kavramıdır.Bu nedenle, önce tek makineli işlemlerin ACID'sini anlamak gerekir. İşlemler için ACID özellikleri sağlanmıştır.Atomisite ve dayanıklılığın anlamı nispeten açıktır, ancak tutarlılık ve izolasyonun anlaşılması o kadar kolay değildir.Bu iki özelliğin anlamını analiz etmeye çalışalım.
İzolasyon
Her şeyden önce, izolasyon. İzolasyon, birden fazla işlemin eşzamanlı olarak yürütülmesi için eşzamanlılık güvenliğinin garantisidir. Birden fazla işlemin eşzamanlı olarak yürütülmesi genellikle aşağıdaki sorunlara yol açar. Olguya başvurabilirsiniz:
Eşzamanlı programlama ağı - kirli okuma, tekrarlanamayan okuma, hayalet okuma
1. Kirli okuma : İşlem, diğer geri alınan veya taahhüt edilmeyen işlemlerin veri değişikliklerini okuyabilir.
2. Tekrarlanamayan okuma : Aynı veri parçasını birden çok kez okuyan işlemin sonucu tutarsızdır.
Tekrarlanamayan okuma ile kirli okuma arasındaki fark, kirli okumanın, geri alınan veya taahhüt edilmeyen diğer işlemler tarafından verilerin değiştirilmesi, tekrarlanamayan okuma ise taahhüt edilen işlemin verilerini okur, ancak birden fazla başka olabilir. Bir işlem aynı veri parçasını değiştirir, bu nedenle devam etmekte olan bir işlem, bir veri parçasını okurken birden fazla sonuç okuyabilir.
3. Hayalet okuma : Diğer işlemler tarafından eklenen veriler, işlem birden çok kez okunduğunda okunabilir Hayalet okuma esas olarak değişiklikten ziyade yeni verilerin eklenmesini ifade eder.
Yukarıdaki problemleri çözmek için, işlem izolasyonu getirir.İzolasyonun özü, eşzamanlılığın kontrol edilmesidir.Ancak, uygulamada, izolasyonun işlem eşzamanlılığı üzerindeki etkisini dikkate almak gerekir.Genel olarak, izolasyon ne kadar sıkı olursa, eşzamanlılık o kadar düşük olur. Genellikle ikisi arasında uygun bir denge bulmanız gerekir. Bu nedenle, izolasyonu tanımlayan başka bir kavram olan izolasyon seviyesini tanıtmak gerekir.SQL standart işlem izolasyon seviyeleri şunları içerir:
Taahhüt edilmeyen okuma (onaylanmamış okuma), okuma tamamlanmış (okuma tamamlanmış), tekrarlanabilir okuma (tekrarlanabilir okuma) ve serileştirme (serileştirilebilir)
1. Taahhüt edilmeyen oku : Bir işlem gerçekleştirilmediğinde, yaptığı değişiklikler diğer işlemler tarafından görülebilir.Bu seviyede kirli okumalar, tekrarlanamayan okumalar ve hayali okumalar vardır.
2. Kaydedildi oku (kaydedildi) : Bir işlem gerçekleştirildikten sonra, yaptığı değişiklikler diğer işlemler tarafından görülecektir.Bu seviyede tekrarlanamayan okuma ve hayali okuma.
3. Tekrarlanabilir okuma : Bir işlemin yürütülmesi sırasında görülen veriler her zaman işlemin başlangıcında görülen verilerle tutarlıdır. Elbette, tekrarlanabilir okuma izolasyon seviyesi altında, taahhüt edilmeyen değişiklikler diğer işlemler için de görünmezdir ve bu seviyede hayali okumalar vardır.
4. Serileştirilebilir (serileştirilebilir) : Aynı kayıt satırı için "yazma", "yazma kilidi" ve "okuma", "okuma kilidi" ekleyecektir. Bir okuma-yazma kilidi çakışması meydana geldiğinde, daha sonra erişilen işlemin devam edebilmesi için önceki işlemin tamamlanmasını beklemesi gerekir. Kirli okuma, tekrarlanamayan okuma ve hayali okuma problemleri bu seviyede mevcut değildir.
Daha önce de belirtildiği gibi, bu dört izolasyon seviyesinin tanımlanmasının gerekmesinin nedeni izolasyon ve eşzamanlılık verimliliğini dengelemektir.Farklı izolasyon seviyeleri altında çözülebilen eşzamanlılık problemleri farklıdır. Gerçek uygulamalarda, en iyi eşzamanlılığı elde etmek için işletmenin toleransına göre uygun bir izolasyon seviyesi seçmek gerekir. Yukarıdaki dört izolasyon seviyesi için, "taahhüt edilmeyen okuma" ve "serileştirme" nin iki izolasyon seviyesinin anlaşılması daha kolaydır, yani "taahhüt edilmeyenleri oku" veri erişimine hiç eşzamanlılık kontrolü eklerken "serileştirme" "Her işlemin sırayla yürütüldüğünden kesinlikle emin olun.
"Gönderilen okunması" ve "tekrarlanabilir okunması" nın iki izolasyon seviyesini anlamak zordur. Bu izolasyon seviyelerini göstermek için bir örnek kullanın. Aşağıdaki gibi bir mysql veri tablomuz olduğunu varsayalım, veri tablosu T'de sadece bir sütun var ve bir satır 1 değerine sahip.
Aşağıdaki, iki işlemi kronolojik sırayla yürütme davranışıdır,
Farklı izolasyon seviyeleri altında, şekildeki V1, V2 ve V3'ün dönüş değerleri tutarlı değildir.
1. İzolasyon seviyesi "taahhüt edilmemiş okuma" ise, V1'in değeri 2'dir. Şu anda, B işlemi henüz taahhüt edilmemiştir, ancak sonuç A tarafından görülmüştür. Bu nedenle, hem V2 hem de V32'dir.
2. İzolasyon seviyesi "okuma tamamlama" ise, V11 ve V2'nin değeri 2'dir. B işleminin güncellemesi, tamamlandıktan sonra A tarafından görülebilir. Dolayısıyla V3'ün değeri de 2'dir.
3. İzolasyon seviyesi "tekrarlanabilir okuma" ise, V1 ve V21 ve V32'dir. V2'nin hala 1 olmasının nedeni, bu gereksinimi yerine getirmektir: işlemden önce ve sonra görülen veriler, yürütme sırasında tutarlı olmalıdır.
4. Yalıtım seviyesi "serileştirme" ise, B işlemi 1'den 2'ye değiştirmek için yürütüldüğünde kilitlenecektir. A işlemi gerçekleştirilinceye kadar, B işlemi yürütmeye devam edebilir. Yani A'nın perspektifinden, V1 ve V2'nin değeri 1 ve V3'ün değeri 2'dir.
Uygulamada, veritabanında bir görünüm oluşturulacak ve görünümün mantıksal sonucu erişilirken geçerli olacaktır. "Tekrarlanabilir okuma" izolasyon seviyesi altında, işlem başladığında bu görünüm oluşturulur ve bu görünüm işlemin varlığı boyunca kullanılır (görünüm kavramı sonraki uygulamalarda açıklanacaktır). "Okuma kaydetme" izolasyon seviyesi altında, bu görünüm her SQL ifadesi yürütülmeye başladığında oluşturulur. Burada not edilmelidir ki "işlenmemiş okuma" izolasyon seviyesi altında, kayıttaki en son değer doğrudan döndürülür ve görüş kavramı yoktur; "serileştirme" izolasyon seviyesi altında, kilitlemenin doğrudan paralel erişimi önlemek için kullanılır. Verilerin davranışı, farklı izolasyon seviyelerinde tutarsızdır.
tutarlılık
Veritabanındaki tutarlılık kavramı da nispeten belirsizdir.Anlamak için, lütfen Veri Yoğun Uygulamaların Tasarlanması ve Veritabanı işlemlerinde tutarlılık kavramının nasıl anlaşılacağı bölümlerindeki açıklamalara bakın.
ACID tutarlılığı fikri, verileriniz (değişmezler) hakkında her zaman doğru olması gereken belirli ifadelere sahip olmanızdır - örneğin, bir muhasebe sisteminde, tüm hesaplardaki alacaklar ve borçlar her zaman dengelenmelidir. Bir işlem bir veri tabanıyla başlarsa bu değişmezlere göre geçerlidir ve işlem sırasında yazılanlar geçerliliği korur, o zaman değişmezlerin her zaman karşılandığından emin olabilirsiniz.
Bununla birlikte, bu tutarlılık fikri uygulamanın değişmezler kavramına bağlıdır ve tutarlılığı korumak için işlemlerini doğru şekilde tanımlamak uygulamanın sorumluluğundadır.Bu, veritabanının garanti edebileceği bir şey değildir: değişmezlerinizi ihlal eden kötü veriler yazarsanız, veritabanı sizi durduramaz. (Bazı belirli türden değişmezler veritabanı tarafından, örneğin yabancı anahtar kısıtlamaları veya benzersizlik kısıtlamaları kullanılarak kontrol edilebilir. Ancak, genel olarak uygulama hangi verilerin geçerli veya geçersiz olduğunu tanımlar - yalnızca veritabanı o.)
Atomiklik, izolasyon ve dayanıklılık, veritabanının özellikleridir, oysa tutarlılık (ACID anlamında) uygulamanın bir özelliğidir.Uygulama, tutarlılığı sağlamak için veritabanının atomikliğine ve izolasyon özelliklerine güvenebilir, ancak bu, Bu nedenle, C harfi gerçekten ACID'ye ait değildir.
Genel olarak konuşursak, ACID'deki tutarlılık, kopya yedeklemeyle tutarlılık, tutarlılık karması ve CAP teorisinde tutarlılık gibi genellikle dahil olan diğer tutarlılık kavramlarından farklıdır.
ACID'deki AID, veritabanının bir özelliğidir, yani veritabanının özel uygulamasına bağlıdır. Ve bu C tek başına tutarlılıktır.Aslında, uygulama katmanına, yani geliştiriciye bağlıdır. Buradaki tutarlılık, veritabanındaki verilerin başlangıçta doğru olduğu anlamına gelir. Durum aktarılırken, doğru durum her zaman korunur.Kullanıcı tarafından herhangi bir zamanda yapılan herhangi bir talep doğru sonucu döndürecektir. Sözde doğru durum, mevcut durumun önceden belirlenmiş kısıtlamaları karşıladığı ve doğruluk sınırlamalarının fiilen uygulama katmanı tarafından belirlendiği anlamına gelir. Örneğin, bir sermaye sistemi için, sermaye dengesi gibi uygulama katmanı tarafından tanımlanan kısıtlamaların karşılanması doğru bir durum olarak kabul edilebilir. Veritabanı, verileri yalnızca belirli bir modda depolar. Esas olan gerçek dünyayı modellemektir.Bu nedenle, buradaki doğruluk, verilerin gerçek dünyanın çeşitli kısıtlamalarını karşıladığı anlamına gelir. İşlemin ACID özelliğindeki C özelliği, tutarlılığımızı sağlamak için aslında AID'yi kullanır. İşlem tutarlılığı, veri tabanının işlem başlamadan önce tutarlı bir durumda olmasını ve veri tabanının sondan sonra da tutarlılığı sağlamasını sağlar.
Mysql'deki işlemler
Farklı veritabanları tutarsız işlem uygulamalarına sahiptir.Bu makale esas olarak işlemlerin anlaşılmasını derinleştirmek için en sık kullanılan mysql'deki işlemlerin uygulanmasını analiz eder. İşlemin gerçekleştirilmesi aslında işlemin ACID özelliklerinin gerçekleştirilmesidir.Yukarıdaki analiz, tutarlılığın uygulama katmanına göre olduğunu söyledi.Bu nedenle, gerçek veritabanı esas olarak işlemin AID özelliklerini fark eder.Bunların arasında, A atomikliğinin gerçekleştirilmesi daha kolay anlaşılır çünkü veritabanı için İşlemin temel birimi işlemdir.Bir işlem bir veya daha fazla okuma-yazma işlem ifadesinden oluşur.Aynı zamanda, bir istisna durumunda geri dönülerek işlemin atomikliği sağlanır. Aşağıdakiler esas olarak kalıcılığın ve izolasyonun gerçekleşmesini analiz eder.
Basit yapı
MySQL'in kalıcılık ve izolasyon uygulamasını anlamadan önce, MySQL'in temel mimarisini kısaca açıklamamız gerekir:
Genel olarak konuşursak, MySQL iki bölüme ayrılabilir: Sunucu katmanı ve depolama motoru katmanı.
Sunucu katmanı, depolama motorlarının tamamında tüm yerleşik işlevlerin (tarih, saat, matematik ve şifreleme işlevleri vb.) Yanı sıra MySQL'in temel hizmet işlevlerinin çoğunu kapsayan bağlayıcılar, sorgu önbellekleri, çözümleyiciler, optimize ediciler, yürütücüler vb. İçerir. Bu katmanda depolanan prosedürler, tetikleyiciler, görünümler vb. Gibi işlevler uygulanır.
Veri depolama ve çıkarma işleminden depolama motoru katmanı sorumludur. Mimari modeli eklentidir ve InnoDB, MyISAM ve Memory gibi birden çok depolama motorunu destekler. En yaygın kullanılan depolama motoru, MySQL 5.5.5'ten beri varsayılan depolama motoru haline gelen InnoDB'dir.
Aslında, mysql işlemlerinin uygulanmasının analiz edilmesi motora özel olmalıdır, çünkü tüm Mysql motorları işlemleri desteklemez.Aşağıdaki analiz, işlemlerin en yaygın kullanılan InnoDB motorlarında uygulanmasıdır.
Kalıcılık gerçekleştirme
İşlemlerin dayanıklılığı, tüm taahhüt edilen işlemlerin sürdürülmesi gerektiğine yansır.Normal şartlar altında, kalıcılık ile ilgili bir sorun yoktur.Ana neden, elektrik kesintisi ve kesinti gibi aşırı koşullar altında işlem çökmesini kurtarma mekanizmasını dikkate almaktır.
Her şeyden önce, MySQL'in işlem güncelleme verilerini dahili olarak diske nasıl yazdığını anlamanız gerekir.Verilerin işlem değişikliği genellikle ilk değiştirilmiş bellek verileridir, ancak son güncellenmiş verilerin kalıcılık için diske yazılması gerekir, ancak mysql Yaklaşım, işlem güncelleme verilerini her seferinde diske yazmak değildir, çünkü diske yazma çok yavaş olduğundan mysql, uygulamasında WAL (İleriye Yazma Günlüğü) adı verilen bir optimizasyon mekanizması sunar. WAL mekanizmasının kilit noktası, önce günlüğü yazmak sonra diske yazmaktır Burada bahsedilen günlük, mysql'deki önemli bir günlük modülü olan yineleme günlüğüdür. Özellikle, bir kaydın güncellenmesi gerektiğinde, InnoDB motoru ilk olarak kaydı tekrarlama günlüğüne yazacak ve hafızayı güncelleyecektir Bu sırada güncelleme tamamlanmıştır. Aynı zamanda InnoDB motoru, çalışma kaydını uygun bir zamanda diske güncelleyecektir ve bu güncelleme genellikle sistem nispeten boşta olduğunda yapılır. (WAL teknolojisinin optimizasyonu, rastgele disk yazma yerine sıralı günlük dosyası yazma kullanımında yatmaktadır. Günlük dosyaları sürekli olduğundan, performans büyük ölçüde geliştirilebilir. Bu benzer teknoloji, mesaj kuyrukları gibi diğer mesajlarda da kullanılır.)
InnoDB'nin yineleme günlüğünün sabit bir boyutu vardır. Örneğin, her biri 1 GB boyutunda olan 4 dosyadan oluşan bir set olarak yapılandırılabilir. Ardından, yineleme günlüğü toplamda 4 GB işlem kaydedebilir. Yazmaya baştan başlayın ve ardından aşağıdaki şekilde gösterildiği gibi, sonunda döngüsel olarak yazmak için başa dönün:
yazma konumu o anki kaydın konumudur.Yazarken geriye doğru hareket eder 3. dosyanın sonuna yazıldıktan sonra 0. dosyanın başına döner. Kontrol noktası silinecek mevcut konumdur ve aynı zamanda geriye doğru hareket eder ve döngü yapar Kaydı silmeden önce, kaydın güncellenmesi diske devam ettirilmelidir. Yazma konumu ile kontrol noktası arasındaki kısım, yineleme günlüğünün yeni işlemleri kaydetmek için kullanılabilen boş kısmıdır. Yazma konumu denetim noktasını yakalarsa, bu, yineleme günlüğünün dolu olduğu ve şu anda yeni güncelleme yapılamayacağı anlamına gelir.Önce bazı kayıtları durdurup silmeniz ve denetim noktasını ilerletmeniz gerekir (denetim noktası mekanizması veri yedekleme ve kurtarma için kullanılabilir). Yineleme günlüğü ile InnoDB, veritabanı anormal bir şekilde yeniden başlatılsa bile, önceden gönderilen kayıtların kaybolmayacağını garanti edebilir.Bu özelliğe çökmeye karşı güvenli denir.
Aynı zamanda mysql, işlem güncellemesinde yineleme günlüğü yazmanın yanı sıra, master-slave veri senkronizasyonunu desteklemek için binlog olan önemli bir günlük dosyası yazmalıdır.Binlog'un sunucu katmanında yazıldığı ve yineleme günlüğünün motor katmanında olduğu unutulmamalıdır. Yazılı günlük. Örneğin, basit bir işlem güncelleme bildirimi yürütmek istiyoruz,
Bu ifadenin mysql'de çalıştırılma süreci aşağıdaki gibi basitleştirilmiştir.Yeniden yazma ve binlog yazmanın tutarlılığını sağlamak için mysql bunu başarmak için dahili olarak iki aşamalı bir kesinleştirme protokolü kullanır.İlk olarak yineleme günlüğü hazır duruma getirilir ve ardından binlog yazılır. Günlük, binlong günlüğü başarıyla yazıldıktan sonra, yineleme günlüğünün durumunu commit olarak değiştirin ve işlem tamamlama işlemi tamamlandı.
Mysql'in anormal koşullar altında çökmeye karşı güvenli olmasını sağlamak için anormal kurtarmayı nasıl uyguladığına bir göz atalım.Yukarıdaki şekilde gösterildiği gibi, anormal sistem kesintisi / elektrik kesintisi süresini dört aralığa böler ve bunları yineleme günlüğüne yazarız. Hazırlanmadan önce, A zamanı, B zamanı ve işlem tamamlandıktan sonra. Ardından, MySQL iki aşamalı gönderimin farklı anlarında anormal şekilde yeniden başladığında ne olduğunu analiz edin.
Yineleme günlüğüne yazmaya hazırlanmadan önceki ve işlem tamamlamadan sonraki iki aşama görece basittir. Birincisi işlemi geri alır ve sonraki işlem gerçekleştirilmiştir. Sorun yoktur Anahtar, A zamanı aşaması ve zaman B aşamasıdır.
A zamanı için, şekildeki A zamanında, yani yeniden yapma günlüğünü hazırlık aşamasında yazdıktan sonra ve binlog yazılmadan önce, bir kilitlenme meydana gelir.Binlog henüz yazılmadığı ve yineleme günlüğü henüz gönderilmediğinden, çökme kurtarma İşlem ne zaman geri alınacaktır. Şu anda, binlog henüz yazılmamıştır, bu nedenle hiçbir etkisi olmayan bekleme veritabanına iletilmeyecektir.
B zamanında, yani, binlog yazıldığında ve yineleme günlüğü kaydetmeden önce çöktüğünde, çökme kurtarıldığında MySQL çökme kurtarma karar kuralları aşağıdaki gibidir:
1. Yineleme günlüğündeki işlem tamamlandıysa, yani bir taahhüt işareti varsa, doğrudan gönderin;
2. Yineleme günlüğündeki işlem yalnızca tam bir hazırlığa sahipse, karşılık gelen işlem bin günlüğünün var olup olmadığına ve tamamlanıp tamamlanmadığına karar verin: eğer öyleyse, işlemi gerçekleştirin, aksi takdirde işlemi geri alın.
Mysql yeniden başlatıldıktan sonra, hizmetleri sağlamadan önce, tüm anormal işlemler, taahhüt edilen tüm işlemlerin dayanıklılığını sağlamak için ilk önce yukarıdaki çökme kurtarma işlemini gerçekleştirecektir.
İzolasyon gerçekleştirme
Innodb'de izolasyonun uygulanması, spesifik izolasyon mekanizması ile ilgilidir. "Kararsız okuma" ve "serileştirme" den daha önce de bahsedilmiştir. Uygulamanın anlaşılması daha kolaydır. Burada esas olarak "gönderilen oku" ve "tekrarlanabilir okuma" analizlerini yapıyoruz. "Bu iki izolasyon mekanizmasının gerçekleştirilmesi, çünkü bu ikisi Innodb motorundaki MVCC," anlık görüntü "ve" kilit "gibi bir dizi teknolojiye dayanıyor.
MVCC
İzolasyon, temel olarak birden fazla işlemin aynı anda okuma ve yazma işlemlerinin karşılıklı olarak karışması sorununu çözmektir, esas olarak güncelleme işlemleri, mysql'deki her güncelleme işlemi bir geri alma günlüğü geri alma günlüğü oluşturur, kayıttaki en son değer geri alma işlemi aracılığıyla elde edilebilir Önceki durumun değeri.
Bir değerin sırayla 1'den 2, 3, 4'e değiştirildiği varsayıldığında, geri alma günlüğünde aşağıdakine benzer kayıtlar olacaktır. Geçerli değer 4'tür, ancak bu kayıt sorgulanırken, farklı zamanlarda başlatılan işlemler farklı okuma-görüntüleme görünümlerine sahip olacaktır. Şekilde de görebileceğiniz gibi A, B ve C görünümlerinde bu kaydın değeri sırasıyla 1, 2 ve 4'tür.Sistemde aynı kaydın birden çok sürümü olabilir, bu da veritabanının çok sürümlü eşzamanlılık kontrolü MVCC'si olabilir.
Okuma görünümü A için, 1 elde etmek için, mevcut değeri elde etmek için sırayla şekildeki tüm geri alma işlemlerini gerçekleştirmelisiniz. Bu şekilde, başka bir işlem 4'ten 5'e değişse bile, bu işlem okuma görünümü A, B ve C'ye karşılık gelen işlemlerle çakışmayacaktır. Elbette, geri alma bölümü günlüğü, yani geri alma günlüğü, sistem buna ihtiyaç duymadığında, yani bu geri alma bölüm günlüğünden daha önce bir okuma görünümü olmadığında silinecektir. Burada bahsedilen görünüm okuma görünümü, MVCC'de kullanılan tutarlı bir okuma görünümüdür. Uygulama, işlem başlatıldığında oluşturulan anlık görüntü ve bir dizi veri görünürlüğü kuralı tarafından belirlenir. Anlık görüntü ve veri görünürlük kuralları aşağıda açıklanmıştır.
Enstantane fotoğraf
Daha önce bahsedilen okuma görünümü, anlık görüntünün nasıl oluşturulduğudur? Her şeyden önce, anlık görüntü tüm kitaplığı temel alır. Bir kitaplıkta 100G varsa, bir işlem başlatılırken MySQL 100G veriyi kopyalamaz, bu çok verimsizdir. Uygulama ilkesini kısaca analiz edelim.
InnoDB'deki her işlemin işlem kimliği adı verilen benzersiz bir işlem kimliği vardır. InnoDB'nin işlem sistemine işlemin başlangıcında uygulanır ve uygulama sırasına göre kesinlikle artmaktadır. Ve her veri satırının birden çok sürümü vardır. Bir işlem veriyi her güncellediğinde, yeni bir veri sürümü üretilir ve işlem kimliği, satır trxid olarak kaydedilen bu veri sürümünün işlem kimliğine atanır. Aynı zamanda eski veri versiyonu saklanmalı ve yeni veri versiyonunda doğrudan elde edilebilecek bilgiler bulunmaktadır. Başka bir deyişle, veri tablosundaki bir kayıt satırı aslında birden çok satır sürümüne sahip olabilir ve her sürümün kendi trxid satırı vardır.
Yukarıdaki şekilde gösterildiği gibi, bir kaydın birden fazla işlemle sürekli olarak güncellenmesinden sonraki durumdur .. innodb bir 100G anlık görüntüsünü nasıl tanımlar?
Tekrarlanabilir okuma tanımına göre, bir işlem başlatıldığında, tüm taahhüt edilen işlemlerin sonuçlarını görebilirsiniz. Ancak daha sonra, bu işlemin yürütülmesi sırasında, diğer işlemlerin güncellemeleri ona görünmez. Bu nedenle, bir işlemin yalnızca başlatıldığında bildirilmesi gerekir, "Mevcut başlangıcımın zamanına bağlıdır. Başlamadan önce bir veri sürümü oluşturulursa, tanınacaktır; başlattıktan sonra üretilirse, onu tanımayacağım. , Onun önceki sürümünü bulmalıyım ". Elbette, "önceki sürüm" görünmüyorsa, ileriye bakmaya devam etmelisiniz. Ayrıca, işlemin kendisi tarafından güncellenen verilerse, yine de tanıması gerekir.
Uygulama açısından InnoDB, işlemin başladığı anda şu anda "aktif" olan tüm işlem kimliklerini depolamak için her işlem için bir dizi oluşturur. "Etkin", etkinleştirildiği ancak henüz gönderilmediği anlamına gelir. Dizideki işlem kimliğinin minimum değeri düşük su işareti olarak kaydedilir ve mevcut sistemde oluşturulan işlem kimliğinin maksimum değeri artı 1 yüksek su işareti olarak kaydedilir. Bu görünüm dizisi ve yüksek su işareti, mevcut işlemin tutarlı bir görünümünü oluşturur (okuma görünümü). Veri sürümünün görünürlük kuralı, verilerin trxid satırının karşılaştırma sonucuna ve bu tutarlı görünüme dayanır. Bu görünüm dizisi, tüm sıralı trxidleri birkaç farklı duruma böler.
Bu şekilde, mevcut işlemin başlangıç anı için, trxid satırının veri sürümü için birkaç olasılık vardır:
1. Yeşil kısma düşerse, bu sürümün taahhüt edilmiş bir işlem olduğu veya mevcut işlemin kendisi tarafından oluşturulduğu ve bu verilerin görünür olduğu anlamına gelir;
2. Kırmızı kısma düşerse, bu sürümün gelecekte başlatılan bir işlemle oluşturulduğu ve kesinlikle görünmez olduğu anlamına gelir.
3. Sarı kısma düşerse, iki durumu içerir:
a. Trxid satırı dizide ise, bu sürümün henüz kaydedilmemiş ve görünür olmayan bir işlem tarafından oluşturulduğu anlamına gelir;
b. Satır trxid dizide değilse, bu sürümün önceden kaydedilmiş ve görünür olan bir işlem tarafından oluşturulduğu anlamına gelir.
Örneğin, bir önceki şekildeki veriler için, eğer bir işlem varsa, düşük su işareti 18'dir, o zaman bu veri satırına eriştiğinde, V4'ten U3'e kadar V3'ü hesaplayacaktır, yani görünümünde bu satır Değer 11'dir. İşlem başladığında tüm aktif işlem kimliği dizilerinin kaydedilmesinin gerekli olmasının nedeni, verilerin görünür olup olmadığını basitçe satır trxid değerini karşılaştırarak belirlemenin imkansız olmasıdır, çünkü işlemi takip edecek küçük bir işlem kimliği ile veri güncelleme işlemleri olabilir. Kimlik daha büyükse, bu durumda, daha büyük bir işlem kimliğine sahip bir işlem bir anlık görüntü oluşturduğunda, daha küçük bir kimliğe sahip olan taahhüt edilmemiş işlem, yukarıdaki belirleme kurallarına göre doğru olanın elde edilebilmesi için etkin diziye kaydedilecektir. sonuç.
Bu ifade belirleme kuralı ile, sistemdeki sonraki güncellemelerin işlem tarafından görülen içerikle hiçbir ilgisi yoktur, çünkü sonraki güncelleme, üretilen sürüm yukarıdaki 2 veya 3 (a) durumuna ait olmalıdır ve bunun için Başka bir deyişle, bu yeni veri sürümleri mevcut değildir, bu nedenle bu işlemin anlık görüntüsü "statiktir". Bu nedenle InnoDB, "saniyeler içinde anlık görüntüler oluşturma" yeteneğini elde etmek için "tüm verilerin birden çok sürümü vardır" özelliğini kullanır.
kilit
İki işlem bir veri parçasını güncellediğinde, veri satırına bir satır kilidi eklemeniz gerekir.Kilitleme kuralları, mysql'deki sözde iki aşamalı kilit protokolünü izler. İki aşamalı kilit protokolü, InnoDB işlemlerindeki satır kilidiyle ilgilidir. Gerektiğinde eklenir, ancak ihtiyaç duyulmadığında hemen serbest bırakılmaz, ancak işlem bittiğinde serbest bırakılır.
Örneğin, ilk verisi (1,1) olan bir veri tablosu t için yukarıdaki işlem işlemini yürütür, C işlemi güncellemeden hemen sonra sunulmaz, sunulmadan önce B işleminin güncelleme beyanı başlatılır. Daha önce de belirtildiği gibi, C işlemi henüz tamamlanmamış olmasına rağmen, sürüm (1,2) de oluşturulmuştur ve en son sürümdür. Daha sonra, B işleminin güncelleme ifadesinin "iki fazlı kilit protokolü" tarafından kilitlenmesi gerekir. İşlem C taahhüt edilmemiştir, bu da bu sürümdeki (1,2) yazma kilidinin henüz serbest bırakılmadığı anlamına gelir. Ve B işlemi şu anda okuyor, yani en son sürümü okumalı ve kilitlenmeli, böylece kilitlenmelidir.C işleminin kilidi serbest bırakmasını beklemelisiniz, güncelleme işlemine başarılı bir şekilde devam edebilmesi için.
başarmak
Yukarıdaki MVCC kavramları, görünümler ve kilitlerle, Innodb motorunun "gönderilen okundu" ve "tekrarlanabilir okuma" yı nasıl uyguladığını anlayabilirsiniz.
"Tekrarlanabilir okuma" nın özü "tutarlı okuma" dır; bir işlem verileri güncellediğinde, yalnızca mevcut okuma kullanılabilir. Mevcut kaydın satır kilidi başka işlemler tarafından işgal edilmişse, kilit beklemeye girmeniz gerekir. "Okuma tamamlama" mantığı "tekrarlanabilir okuma" mantığına benzer. Aralarındaki temel fark, iki izolasyon seviyesi arasındaki farkın görünüm oluşturmanın zamanlamasında yatmasıdır.
1. "Tekrarlanabilir okuma" izolasyon düzeyi altında, yalnızca işlemin başında tutarlı bir görünüm oluşturmanız gerekir ve ardından işlemdeki diğer sorgular bu tutarlı görünümü paylaşır;
2. "Okuma kaydetme" izolasyon seviyesi altında, her ifade yürütülmeden önce yeni bir görünüm yeniden hesaplanacaktır.
Hayali okuma sorunu
Genel olarak, tekrarlanabilir okuma altında hala bir fantom okuma problemi vardır, ancak innodb motorun gerçek kullanımında, fantom okuma problemi yoktur.Bunun nedeni, innodb motor uygulamasının, fantom okuma problemini çözmek için aralıklı kilit Gap-Lock mekanizmasını tanıtmasıdır.
Hayali okumanın temel nedeni, satır kilidinin yalnızca satırı kilitleyebilmesidir, ancak yeni bir kayıt ekleme eylemi, kayıtlar arasındaki "boşluğun" güncellenmesini gerektirir. Bu nedenle, fantom okuma problemini çözmek için, innodb motorunun yeni bir kilit, yani boşluk kilidi Gap Lock'u tanıtması gerekiyordu. Adından da anlaşılacağı gibi boşluk kilidi, iki değer arasındaki boşluğu kilitler. Örneğin, aşağıdaki şekilde gösterildiği gibi bir veri tablosu t için, başlangıçta 6 kayıt eklenir ve bu da 7 boşlukla sonuçlanır.
Bu şekilde, güncelleme için d = 5 olan t'den * seçimini yürütürken, d indekssiz olduğu için, tam bir tablo taramasına eşdeğerdir ve mysql'deki kilit kuralı, belirli bir değer tarandığında karşılık gelen değeri elde etmektir. Kilitle, böylece bu ifade yalnızca veritabanındaki mevcut 6 kayda satır kilitleri eklemekle kalmaz, aynı zamanda yeni kayıtların eklenememesini sağlamak için 7 boşluk kilidi ekler. "Bu boşluğa bir kayıt ekle" işlemi olan boşluk kilidi ile çelişkili bir ilişki olduğu unutulmamalıdır İki boşluk kilidi arasında herhangi bir çakışma ilişkisi yoktur. Aynı zamanda, aralıklı kilitlerin kullanılması, işlemlerin eşzamanlılığını azaltacaktır, "satır kilidi + aralıklı kilit" mysql'de sonraki tuş kilidi olarak da adlandırılır.
Dağıtılmış işlem
konsept
Wikipedia'daki dağıtılmış işlemlerin tanımını şu şekilde alıntı yapmak:
Dağıtılmış bir işlem, iki veya daha fazla ağ ana bilgisayarının dahil olduğu bir veritabanı işlemidir. Genellikle ana bilgisayarlar işlem kaynaklarını sağlarken işlem yöneticisi bu tür kaynaklarla ilgili tüm işlemleri kapsayan küresel bir işlem oluşturmak ve yönetmekle sorumludur. diğer işlemler dört ACID (atomiklik, tutarlılık, izolasyon, dayanıklılık) özelliğinin hepsine sahip olmalıdır; burada atomiklik iş birimi için ya hep ya hiç sonuçları garanti eder (işlem paketi).
Kabaca konuşursak, bir işlem tek makineli işlemleri destekleyen birden çok ve farklı ağ düğümlerinden oluştuğunda, bu dağıtılmış bir işlemdir. Dağıtılmış işlem neden bir problemdir?
Her şeyden önce, geleneksel monolitik bir uygulama için, bir işin aynı veri kaynağındaki verilerin üç modül üzerinden güncellenmesiyle tamamlandığını varsayalım.Tüm iş sürecinin veri tutarlılığı yerel işlemler ile garanti edilebilir.
Bununla birlikte, iş gereksinimleri ve mimarideki değişikliklerle birlikte, monolitik uygulama mikro hizmetlere ayrılmıştır: orijinal 3 Modül, bağımsız veri kaynakları kullanılarak 3 bağımsız hizmete bölünmüştür ve iş süreci 3 hizmet tarafından çağrılacaktır. Yapılacak.
Şu anda, her hizmetin dahili veri tutarlılığı yerel işlemlerle hala garanti edilmektedir, ancak tüm iş seviyesinin küresel veri tutarlılığı garanti edilemez. Mikro hizmet mimarisi altında karşılaştığımız şey budur, bu nedenle işletmenin genel veri tutarlılığını sağlamak için dağıtılmış bir işlem çözümüne ihtiyacımız var.
model
Dağıtılmış işlem yeni bir kavram değildir.Sektörde halihazırda olgun çözümler vardır.Bu, iş geliştirmeden sonra yapı bölündükten sonra karşılaşılması gereken bir sorundur.Çözümler, işletmenin sahip olup olmadığına bağlı olarak temel olarak aşağıdaki modelleri içerir. İzinsiz giriş bölümü:
1. Müdahaleci olmayan program: XA modeli
2. İzinsiz giriş planı:
(1) Güvenilir mesajlara dayalı nihai tutarlılık çözümü
(2) TCC modeli
(3) Sagas modeli
XA modeli
XA modeli, X / Open organizasyonu tarafından önerilen dağıtılmış işlem işleme spesifikasyonunu ifade eder. XA belirtimi esas olarak Transaction Manager (TM) ve Resource Manager (RM) arasındaki arayüzü tanımlar. Yapı aşağıdaki şekilde gösterilmiştir:
XA işlem modelinde üç önemli bileşen vardır:
1. İşlem Koordinatörü (TC) : Küresel işlemin çalışma durumunu koruyan işlem koordinatörü, küresel işlemin tamamlanmasını veya geri alınmasını koordine etmekten ve yürütmekten sorumludur.
2. İşlem Yöneticisi (TM) : Global işlemin sınırını kontrol edin, global bir işlemi açmaktan sorumlu olun ve son olarak global bir taahhüt veya global geri alma çözümü başlatın.
3. Kaynak Yöneticisi (RM) : Şube kaydı, durum bildirimi ve işlem koordinatöründen talimatlar almaktan sorumlu şube işlemlerini kontrol edin, bu da şube (yerel) işlemlerinin tamamlanmasını ve geri alınmasını sağlar.
Tipik bir dağıtılmış işlem süreci:
(1) TM, global bir işlem başlatmak için TC için geçerlidir Global işlem başarıyla oluşturulur ve küresel olarak benzersiz bir XID oluşturulur.
(2) XID, mikro hizmet çağırma bağlantısı bağlamında yayılır.
(3) RM, TC'ye şube işlerini kaydeder ve bunları küresel ilişkilerle ilgili XID'nin yetki alanı altına koyar.
(4) TM, XID için TC'ye genel bir gönderim veya geri alma çözünürlüğü başlatır.
(5) TC, XID'nin yetki alanı altındaki tüm şube işlemlerini gönderim veya geri alma taleplerini tamamlamak için planlar.
XA işlem modelinde RM, veritabanının ilk seviyesinde uygulanmaktadır, bu da veritabanının XA işlemlerini desteklemesi gerektiği anlamına gelir ve uygulamalar da XA işlemlerini destekleyerek bağlanır ve çalıştırılır.Aynı zamanda XA aslında iki aşamalı bir kesinleştirme protokolü olduğu için, Aşağıdaki sorular:
1. Veritabanının XA için destek sağlamasını zorunlu kılın. XA'yı desteklemeyen (veya iyi desteklemeyen, örneğin 5.7'den önceki MySQL sürümleri gibi) bir veritabanıyla karşılaşırsanız, onu kullanamazsınız.
2. Protokolün kendisi tarafından kısıtlanan işlem kaynaklarının (veri kayıtları, veritabanı bağlantıları) kilit döngüsü uzundur. Uzun vadeli kaynak kilitleme, iş açısından genellikle gereksizdir ve işlem kaynak yöneticisi veritabanının kendisi olduğu için, uygulama katmanı müdahale edemez. Bu şekilde oluşan durum, XA tabanlı uygulamaların zayıf performansa sahip olma eğiliminde olması ve optimize edilmesinin zor olmasıdır.
3. Halihazırda yerleştirilmiş olan XA tabanlı dağıtılmış çözümler, mikro hizmet mimarisi için uygun olmayan ağır uygulama sunucularına (Tuxedo / WebLogic / WebSphere, vb.) Dayanır.
Güvenilir mesaj modeli
Güvenilir mesajlara dayalı işlem modeli, esasen işlem günlüğünü yerel iş veritabanında depolamak, yerel işlemler aracılığıyla işlem günlüğünün ve yerel işlemin tutarlılığını sağlamak ve ardından dağıtımı sağlamak için işlem günlüğünü eşzamansız olarak itmek ve telafi etmek için güvenilir mesajlar kullanmaktır. İşlemin tutarlılığı. Bununla birlikte, işlem günlüğünün saklama konumu da iki uygulamaya bölünmüştür, biri mesaj tablosunu yerel iş sistemi kitaplığında depolamak, diğeri ise güvenilir mesajı ortada saklamaktır.
Yerel depolama işlem günlüğü tablosunun uygulanmasına dayalı işlem akışı şu şekildedir:
1. İşlemin aktif başlatıcısı, yerel işlemler yoluyla başlatıcının "iş yerel işleminin" ve "mesaj tablosunun" işlem tutarlılığını sağlar ve pasif tarafa karşılık gelen işlem mantığını bir mesaj yoluyla yürütmesi için bilgi verir;
2. İstisna ortadan kalktığında veya bildirim başarısız olduğunda, mesaj kurtarma sistemi gönderime devam etmek için periyodik olarak gönderilmemiş mesajları tarayacaktır.
Bu uygulama formunun dağıtılmış işlem modeli (şirketin qmq işlemi bu modele göre uygulanır) ayrıca kullanıldığında bazı kısıtlamalara sahiptir:
1. İşlemin pasif tarafının sonucu, işi başlatanın sonucunu etkilemeyecektir;
2. Pasif tarafın işlem işleme mantığının idempotence desteklemesi gerekir;
3. Mesaj ara depolamaya dayalı işlem günlüğü tablosunun uygulama prensibi aşağıdaki gibidir:
İşleme akışı şu şekildedir:
1. İşlem başlatıcı, işlemi gerçekleştirmeden önce mesaj ara yazılımına bir mesaj gönderecektir.Bu anda, mesaj ara yazılımı mesaj tablosunda saklamaktan sorumludur.Şu anda mesaj hazırlık aşamasındadır ve işlemin pasif tarafına gönderilmeyecektir;
2. İşlem başlatıcı işlemi gönderdikten sonra, mesaj ara yazılımına bir onay mesajı gönderir Bu sırada, mesaj ara yazılımı mesaj tablosunun durumunu taahhüt durumuna değiştirir ve mesajı işlemin pasif tarafına gönderir;
3. İş başlatıcısı anormal olduğunda, hazırlık durumundaki mesaj tablosundaki kayıt işlemi başlatan kişiye işlemin tamamlandığını veya geri alındığını sorar ve işlemi bir kerede yapar;
4. Mesaj ara yazılımı anormal olduğunda, işlenmemiş mesaj tablosu kayıtlarını işlemek için bir mesaj yeniden deneme mekanizması vardır.
Bu yöntemin kısıtlamaları öncekiyle aynıdır, ancak bu yöntemin aynı zamanda mesaj ara yazılımı desteğine ihtiyacı vardır.Mesaj ara yazılımı, mesaj tablosunu artık yerel kitaplığa bağlı olmayacak şekilde sarar.
1. İşlemin pasif tarafının sonucu, işi başlatanın sonucunu etkilemeyecektir;
2. Pasif tarafın işlem işleme mantığının idempotence desteklemesi gerekir;
3. Mesaj ara yazılımı, işlem mesajı depolamayı desteklemelidir;
4. İşlem başlatıcının bir işlem sonucu sorgu arayüzü sağlaması gerekir.
TCC modeline göre
TCC işlem modeli, son derece tutarlı bir dağıtılmış işlem modelidir ve işleme akışı:
1. Ana sunucu bir TCC işlemi başlatır ve iş faaliyeti yöneticisi işlemi kaydedip başlatır;
2. İş faaliyeti yöneticisi sırayla her bir bağımlı hizmetin deneme arayüzünü çağırır ve her bir yardımcı hizmet bu aşamada işi işler ve gerekli kaynakları kilitler;
3. confirm cancel
4.
TCC
1. try confirm cancel
2.
3.TCC
sagas
Sagas 1987 Hector Garcia-Molina Kenneth Salem Paper long lived transactionSaga
Sagas Saga sub-transaction Ti Ti Ci Ti TCC Saga Try Ti Saga
1.T1, T2, T3, ..., Tn
2.T1, T2, ..., Tj, Cj,..., C2, C10 < j < n
Saga
1. backward recovery j sub-transaction sub-transation Saga
2. forward recovery T1, T2, ..., Tj(), Tj(),..., Tn j sub-transaction Ci
sagas ServiceComb
1.
2.
3. ACID sagas
özet
