Örnek: Kafka filigran yedekleme mekanizması
Yazar | Zhang Chenghui tarafından düzenlendi | Liu Jing
Yüksek kullanılabilirlik, birçok dağıtılmış sistemdeki temel özelliklerden biridir.Kafka günlüklerinin yüksek kullanılabilirliği, lider-takipçi tabanlı çok kopyalı senkronizasyon yoluyla elde edilir.Her bölümün altında birden fazla kopya vardır ve bunlardan yalnızca biri lider kopyadır. Mesaj gönderme ve tüketme, geri kalanı takipçi kopyalarıdır ve mesajları senkronize etmek için lider kopyaya sürekli olarak getirme istekleri gönderir. Lider, tüm küme işlemi sırasında başarısız olmazsa, takipçi kopyası herhangi bir rol oynamayacaktır. Sorun herhangi bir sistemde yatmaktadır. Kararlı çalışması garanti edilemez. Lider kopyanın bulunduğu aracı çöktüğünde, takipçi kopyalarından biri bölümdeki yeni lider kopya haline gelecektir.
Öyleyse soru, yeni bir lider kopyası olarak seçildiğinde mesajlar kaybolacak mı yoksa dağılacak mı? Kafka, lider kopya değiştiğinde mesajın yanlış gitmemesi sorununu nasıl çözer? Lider ve takipçi kopyaları arasındaki veri senkronizasyonu nasıl yapılır? Bu birkaç soruyla, aşağı bakalım ve Kafka filigran yedeklemesinin gizemini ortaya çıkaralım.
Filigranla ilgili kavramlar
Filigran yedeklemesini açıklamadan önce, önce birkaç anahtar terimi ve bunların anlamlarını bulmalıyız. aşağıdaki Kafka bölüm kopyalarının yer değiştirme bilgilerini göstermek için bir resim kullanıyorum:
Yukarıdaki şekilde gösterildiği gibi, yeşil kısım tamamen yedeklenmiş ve tüketiciler tarafından görülebilen mesajı, mor kısım ise tamamen yedeklenmemiş ve tüketiciler tarafından görülemeyen mesajı gösterir.
-
LEO (son bitiş ofseti): Kopyalama nesnesinin temelindeki günlük dosyasına sonraki mesajın yer değiştirme değerini kaydeden günlüğün sonunun yer değiştirmesi Kopya mesajı yazdığında, LEO değerini otomatik olarak güncelleyecektir.
-
HW (yüksek filigran): Bu değere yüksek filigran değeri denildiği adından bilinmektedir.HW, LEO değerinden büyük olmamalıdır. HW değerinden küçük mesajlar "taahhütlü" veya "yedeklenmiş" mesajlar olarak kabul edilir ve gözle görülür.
Lider, biri kendi LEO'su ve diğeri uzak LEO değeri olmak üzere iki tür LEO değeri kaydeder.Uzak LEO değeri, takipçi kopyasının LEO değeridir, bu, takipçi kopyasının LEO değerinin iki kez kaydedileceği ve biri de lidere kaydedileceği anlamına gelir. Kopyalardan birini kendinize kaydedin.
Uzak LEO değerinin kullanımı nedir?
HW değerinin boyutunu belirlemede anahtardır. Donanım güncelleneceği zaman, LEO değeri (lider LEO dahil) karşılaştırılacak ve en küçük olan en son HW değeri olarak kullanılacaktır.
Aşağıda LEO ve HW değerlerinin güncelleme mekanizması açıklanmaktadır:
LEO güncellemesi:
Lider kopyanın LEO değerinin güncellenmesi: Üretici mesajı gönderildiğinde, yani lider kopyanın en son depolanan mesaj yer değiştirme pozisyonu +1;
Follower kopyanın LEO değeri güncellenir: mesaj lider kopyadan alındığında ve yerel günlük dosyasına yazıldığında, follower kopyası şu anda lider kopyanın en son mesaj yer değiştirme konumunu +1 ile senkronize eder;
Lider kopyasında uzaktan LEO değer güncellemesi: takipçi kopyası bir getirme isteği gönderdiği her seferinde, takipçinin mevcut LEO değeri dahil edilecek ve lider, değeri aldığında uzak LEO değerini güncellemeye çalışacaktır.
lider donanım güncellemesi:
Arıza durumunda güncelleme:
Lider kopya olarak bir kopya seçildiğinde: Bölümün lider kopyası olarak bir takipçi kopyası seçildiğinde, Kafka HW değerini güncellemeye çalışır;
Bir replika ISR'den atıldığında: Bir replika lider replikanın ilerleyişine ayak uyduramazsa veya bulunduğu aracı ISR'den atılmasına neden olursa, lider HW değerinin güncellenmesi gerekip gerekmediğini de kontrol eder. Sonuçta, HW değer güncellemesi yalnızca ISR'deki replikayı takip eder LEO ilişkilidir.
Normal olduğunda güncelle:
Üretici lider kopyaya bir mesaj yazdığında: lider LEO değeri mesaj yazıldığında güncellenir, bu nedenle HW değerinin güncellenmesi gerekip gerekmediğini kontrol etmek gerekir;
Lider takipçi FETCH talebini işlediğinde: takipçinin getirme talebi LEO değerini taşıyacak ve lider karşılık gelen uzak LEO değerini bu değere göre güncelleyecektir ve ayrıca HW değerinin güncellenmesi gerekip gerekmediğini kontrol etmesi gerekir.
takipçi donanım güncellemesi:
Follower, LEO'yu güncelledikten sonra HW'yi günceller.Her follower Fetch yanıt gövdesi, liderin HW değerini içerecek ve ardından mevcut LEO değerini karşılaştıracak ve en küçük değeri yeni HW değeri olarak alacaktır.
Grafik filigran yedekleme işlemi
Kafka filigran yedekleme mekanizması ile ilgili kavramları anladıktan sonra, aşağıdaki Resmi, Kafka'nın filigran yedekleme işlemini daha iyi anlamanıza yardımcı olması için kullanıyorum. Bir bölümün iki kopyası olduğunu varsayın, min.insync.replica = 1:
Aşama 1 : Lider ve takipçi kopyaları başlangıç değerindedir ve takipçi kopyası bir getirme isteği gönderir Lider kopyada veri olmadığı için senkronizasyon işlemi gerçekleştirilmez;
Adım 2 : Üretici, bölüm liderinin kopyasına m1 mesajı gönderir ve lider, mesajı yazdıktan sonra LEO = 1'i günceller;
Aşama 3 : Takipçi, en son ofset = 0 ile bir getirme isteği gönderir. Lider getirme talebini işlediğinde, uzak LEO = 0 güncellenir.Minimum LEO değeri 0'dır, bu nedenle HW = 0, lider replika cevap mesajı verisi ve lider HW = 0 takipçiye gönderilir. Follower mesajı yazdıktan sonra LEO değeri güncellenir ve lider HW değeri karşılaştırılır ve en küçük değer yeni HW değeri olarak alınır Bu zamanda follower HW = 0, yani follower HW lider HW değerini aşmayacaktır.
4. adım : Takipçi, mevcut en son ofset = 1'i taşıyarak, getirme talebinin ikinci turunu gönderir. Lider getirme talebini işlediğinde, uzak LEO = 1'i günceller ve minimum LEO değeri 1'dir, yani HW = 1'dir. Şu anda, liderin yeni mesaj verisi yoktur. Yani lider HW = 1'i doğrudan follower'a döndürün Takipçi, mevcut en son LEO değerini lider HW değeri ile karşılaştırır ve en küçük değeri yeni HW değeri olarak alır. Şu anda follower HW = 1.
Filigran yedekleme mekanizmasına dayalı bazı kusurlar
Yukarıdaki adımlardan, liderde kaydedilen uzak LEO değerinin güncellenmesinin her zaman tamamlanması için ek bir getirme RPC talebi turu gerektirdiği görülebilir, bu da lider değiştirme işlemi sırasında veri kaybı ve veri tutarsızlığı sorunları olacağı anlamına gelir. aşağıdaki Sorunu göstermek için bir resim kullanıyorum:
-
veri kaybı
Daha önce belirtildiği gibi, liderdeki HW değeri, takipçinin bir sonraki getirme RPC isteklerinde güncellenir.Yukarıdaki şekilde gösterildiği gibi, B'nin lider kopya, A'nın takipçi kopyası olduğu ve ilki A'da gerçekleştirilen A ve B kopyaları vardır. İkinci getirme talebini aldıktan ve yanıtı aldıktan sonra, B, HW'yi 2'ye güncellemiştir. Bu, yanıt işlenmeden önce çöktü ise, yani takipçi HW değerini zamanında güncellemez ve A yeniden başladığında otomatik olarak LEO olacaktır. Değer önceki HW değerine ayarlandığında, günlük kesilecek ve ardından B'ye bir getirme isteği gönderilecek, ancak maalesef B de şu anda kapalı ve Kafka A'yı yeni bölüm lideri olarak seçecek. B yeniden başladığında, A'ya bir getirme isteği gönderecektir. Getirme yanıtını aldıktan sonra, HW değerini alın ve yerel HW değerini güncelleyin. Şu anda, HW 1'e ayarlandı (önceden 2 idi) ve B, günlük kesmesi yapacak , Bu nedenle, uzaklık = 1 olan mesaj kalıcı olarak silinir.
Takipçi kopyası neden kesilsin diye sorabilirsiniz.
Bunun nedeni, mesajın önce lidere kaydedilmesidir ve ardından takipçi, senkronizasyon için liderden mesajı çekecektir, bu da lider LEO'nun takipçininkinden daha büyük olmasına yol açar (takipçiler arasındaki uzaklıklar aynı olmamakla birlikte sonunda aynı olacaktır, ancak süreç Şu anda bir lider anahtarı varsa, yeni lider olmak için daha küçük LEO'ya sahip bir takipçi seçmek mümkündür.Şu anda, kopyanın LEO'su yeni standart olacak ve bu da takipçi LEO değeri olasılığına yol açacaktır. Lider LEO değerinden daha büyük olacaktır, bu nedenle takipçi senkronize edilmeden önce, liderden LastOffset değerini alması gerekir (bu değer daha sonra açıklanacaktır), eğer LastOffset mevcut LEO'dan daha küçükse, günlüğün kesilmesi gerekir ve ardından liderden çekilir Senkronizasyona ulaşmak için veri alın.
Ayrıca şunu da sorabilirsiniz, günlüğün kesilmesi veri kaybına neden olur mu?
Daha önce bahsedildiği gibi, HW değerinin üzerindeki mesajlar "kaydedilmez" veya "yedeklenmez", bu nedenle mesajlar tüketiciler tarafından da görünmezdir, yani bu mesajlar kullanıcılara vaatlerde bulunmaz, yani günlük HW değerinden kesilir. Veri kaybına neden olmaz (kullanıcıların vaadi dahilinde).
-
Tutarsız / ayrık veriler
Yukarıdaki durum yalnızca aşağıdaki koşullardan biri karşılanırsa gerçekleşir:
Kesinti süresinden önce, B artık ISR listesinde değildir, kirli.leader.election.enable = true, yani ISR olmayan çoğaltmanın lider olmasına izin verilir;
B Mesaj pagecache'e yazılmıştır, ancak henüz diske boşaltılmamıştır.
Bölümün iki kopyası vardır, burada A lider kopya, B takipçi kopyadır, A iki mesaj yazmıştır ve HW 2 olarak güncellenmiştir, B sadece 1 mesaj yazmıştır ve HW 1'dir. Şu anda A ve B aynı anda aşağıdadır Önce makine B yeniden başlar ve B lider kopya olur. Bu sırada üretici bir mesaj gönderir ve bunu B'ye kaydeder. Bölüm şu anda yalnızca B'ye sahip olduğundan, B mesajı yazarken HW'yi 2 olarak günceller. Yeniden başlatın ve lider HW'nin 2 olduğunu bulun, bu da kendi donanımıyla aynıdır, bu nedenle günlük kesmesi yapılmaz Bu, ofset = 1 olan A'nın günlüğünün ofset = 1 olan B'nin günlüğünden farklı olmasına neden olur.
lider dönem
HW güncelleme zamanlamasının eşzamansız gecikmesini çözmek için ve HW, günlüğün başarıyla yedeklenip yedeklenmediğini belirleyen bir işarettir, bu da veri kaybına ve veri tutarsızlığına neden olur, Kafka, her replika günlük dizininde bir lider oluşturmak için lider dönem mekanizmasını sunar. -epoch-checkpoint dosyası, lider dönem bilgilerini kaydetmek için aşağıdaki gibi kullanılır, lider dönem aşağıdaki gibi görünür:
Formatı (epoch offset), epoch lider versiyona atıfta bulunur, monoton olarak artan pozitif tam sayı değeridir, lider her değiştiğinde epoch versiyonu +1 olur, offset her nesil lider tarafından yazılan ilk mesajdır. Yer değiştirme değeri, örneğin:
(0, 0) (1, 30 0)Yukarıdaki ikinci versiyon deplasman kaynaklıdır 30 0 mesaj yazmaya başlar, yani ilk versiyonda 0-299 arası mesajlar yazılır.
Lider çağının spesifik çalışma mekanizması aşağıdaki gibidir:
-
Kopya lider olduğunda:
Şu anda, yapımcıdan şu anda yeni bir mesaj gönderilirse, yeni lider dönemi ve LEO ilk olarak lider-dönem-kontrol noktası dosyasına eklenecektir.
-
Kopya takipçi olduğunda:
İzleyicideki en son epoch sürümünü içeren lider kopyaya bir LeaderEpochRequest isteği gönderin;
Liderin takipçiye verdiği yanıt bir LastOffset içerir. Follower last epoch = lider last epoch ise, o zaman LastOffset = lider LEO ise, aksi takdirde başlangıç ofseti değeri follower'ın son dönemindeki en küçük lider döneminden daha büyüktür.Örneğin: follower last diyelim epoch = 1, bu zamanda liderde (1, 20) (2, 80) (3, 120), ardından LastOffset = 80;
Follower LastOffset'i aldıktan sonra, mevcut LEO değerinin LastOffset'ten büyük olup olmadığını karşılaştıracaktır.Eğer mevcut LEO LastOffset'ten büyükse, log LastOffset'ten kesilecektir;
Takipçi, mesajı senkronize tutmak için lidere getirme istekleri göndermeye başlar.
Lider çağının çalışma mekanizmasına dayanarak, filigran yedekleme hatasını nasıl çözdüğüne bir göz atalım:
(1) Veri kaybını çözün:
Yukarıdaki şekilde gösterildiği gibi, A yeniden başladıktan sonra, B'ye bir LeaderEpochRequest isteği gönderir. B henüz bir mesaj eklemediğinden, epoch = request epoch = 0, bu nedenle LastOffset = lider LEO = 2'yi A'ya döndürür. A LastOffset'i aldıktan sonra, şuna eşit olduğu bulunur. Mevcut LEO değeri, bu nedenle günlük kesilmesi gerekmez. Bu anda, B aşağı iner ve A lider olur B geri dönmeye başladıktan sonra, A'nın eylemlerini tekrar günlük kesilmeden tekrarlayacak ve veriler kaybolmayacaktır.
(2) Veri tutarsızlığını / ayrıklığını çözün:
Yukarıdaki şekilde gösterildiği gibi, A ve B aynı anda düştükten sonra, B yeniden başlar ve bölümün lideri olur.Bu sırada, yapımcı bir mesaj gönderir ve lider dönemi 1 olarak güncellenir. Bu sırada, A geri başladıktan sonra, LeaderEpochRequest'i gönderir (follower epoch = 0) B'ye göre B, takipçi döneminin en son döneme eşit olmadığına karar verir, bu nedenle takipçi dönem = 1'den daha büyük olan en küçük dönemi bulun, yani, LastOffset = dönem başlangıç uzaklığı = 1. A, LastOffset'i aldıktan sonra, mevcut LEO değerinden daha düşük olduğuna karar verilir, dolayısıyla LastOffset'ten Konumdaki kesintiyi günlüğe kaydedin ve ardından, tutarsız / ayrık mesajlar sorununu ortadan kaldırarak mesajları senkronize etmeye başlamak için B'ye bir getirme isteği göndermeye başlayın.
Feragatname: Bu makale yazar tarafından sunulmuştur ve telif hakkı yazara aittir.
SON
