g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Kafka'nın ilkelerini anlatır mısınız?

Yazar | cxuan

Sorumlu Editör | Elle

Eğer sadece Kafka uygulamaları geliştirmek içinse veya sadece Kafka'yı bir üretim ortamında kullanmak içinse, Kafka'nın iç işleyişini anlamak gerekli değildir. Bununla birlikte, Kafka'nın iç işleyişini anlamak, Kafka'nın davranışını anlamaya ve aynı zamanda sorunları hızlı bir şekilde teşhis etmeye yardımcı olur. Aşağıda bu üç sorunu inceleyelim

Kafka nasıl kopyalanır
Kafka üreticilerden ve tüketicilerden gelen talepleri nasıl ele alıyor?
Kafka'nın depolama detayları nelerdir

Eğer ilgileniyorsanız, lütfen biraz zaman ayırın ve bu makaleyi sabırla okuyun.

Küme üyeleri arasındaki ilişki

Kafka'nın ZooKeeper üzerinde çalıştığını biliyoruz, çünkü ZooKeeper bir küme şeklinde görünür, böylece Kafka bir küme şeklinde de görünebilir. Bu aynı zamanda birden çok üreticinin ve birden çok tüketicinin nasıl koordine ettiği konusunu da içerir Kümeler arasındaki ilişkinin bu bakımı, ZooKeeper tarafından da yapılır. Önceki makalemi okuduysanız (gerçekten, bu Kafka'ya başlamak için yeterlidir), Kafka kümeleri arasında birden fazla ana bilgisayar (aracı) olacağını ve her aracının bir broker.id olacağını bilmelisiniz. Her broker.id kimliğini ayırt etmek için benzersiz bir tanımlayıcı vardır Bu tanımlayıcı, yapılandırma dosyasında manuel olarak belirtilebilir veya otomatik olarak oluşturulabilir.

Kafka, broker.id.generation.enable ve saklıdır.broker.max.id aracılığıyla yeni bir broker.id oluşturabilir.

Broker.id.generation.enable parametresi, broker.id dosyasının otomatik olarak oluşturulmasının etkinleştirilip etkinleştirilmeyeceğini yapılandırmak için kullanılır. Varsayılan olarak, bu işlevi etkinleştirmek doğrudur. Otomatik olarak oluşturulan broker.id dosyasının varsayılan değeri 1000'dir; bu, otomatik olarak oluşturulan broker.id'nin varsayılan olarak 1001'den başlayacağı anlamına gelir.

Kafka başladığında, ZooKeeper'daki / brokers / id'ler yolu altındaki mevcut aracı ile aynı kimliğe sahip geçici bir düğümü kaydedecektir. Kafka'nın sağlık kontrolü bu düğüme bağlıdır. Bir aracı kümeye katıldığında veya kümeden çıktığında, bu bileşenler bilgilendirilecektir.

Aynı kimliğe sahip başka bir komisyoncu başlatmak istiyorsanız, bir hata alırsınız - yeni komisyoncu kaydolmaya çalışacak, ancak ZooKeeper'da aynı kimliğe sahip bir aracı olduğu için başarılı olmayacaktır.
Aracı çalışmadığında, bir bölüm olduğunda veya çöp toplama işlemi uzun bir süre durakladığında, aracının ZooKeeper ile olan bağlantısı kesilir.Bu sırada, aracı tarafından başlangıçta oluşturulan geçici düğüm ZooKeeper'dan kaldırılacaktır. Aracıların listesini izleyen Kafka bileşeni, aracının kaldırıldığı konusunda bilgilendirilir.
Broker kapatıldığında, karşılık gelen düğümü de kaybolacak, ancak kimliği, konunun kopya listesi gibi diğer veri yapılarında var olmaya devam edecek ve kopya listesi kopyalanacaktır.Aşağıda bunun hakkında konuşalım. Bir aracıyı tamamen kapattıktan sonra, aynı kimliğe sahip yeni bir komisyoncu başlatırsanız, hemen kümeye katılır ve eski komisyoncu ile aynı bölüme ve konuya sahip olur.

Broker Denetleyicisinin rolü

Daha önce Kafka Rebalance hakkında konuştuğumuzda, gruplar arasındaki ilişkiyi koordine etmekle görevli bir grup koordinatöründen bahsetmiştik ve ayrıca Kafka'nın temel bileşeni olan brokerler arasında bir denetleyici bileşeni (Denetleyici) var. Ana işlevi, ZooKeeper'ın yardımıyla tüm Kafka kümesini yönetmek ve koordine etmektir. Kümedeki her aracı bir denetleyici olarak adlandırılabilir, ancak Kafka kümesi başlatıldıktan sonra, yalnızca bir aracı Denetleyici olur. Kafka kümesi ZooKeeper kümesine bağlı olduğundan, önce ZooKeeper'ın ne olduğunu tanıtmak gerekir. Yazarın bu makalesine başvurabilirsiniz (ZooKeeper yalnızca bir kayıt merkezi değildir, ne biliyorsunuz?) Ayrıntılar için, burada basittir Znode düğümleri sorunundan bahsedin.

ZooKeeper'ın verileri düğümlerde depolanır.Her düğüm ayrıca znode olarak adlandırılır. Znode düğümü, Linux işletim sisteminin dosya yoluna çok benzeyen ağaç şeklinde bir dosya yapısıdır. ZooKeeper'ın kök düğümü / şeklindedir.

Znodes, verilerin kalıcılığına göre geçici düğümlere ve kalıcı düğümlere ayrılabilir. Kalıcı düğümler, ZooKeeper durumundaki değişiklikler nedeniyle kaybolmaz, ancak ZooKeeper yeniden başladığında geçici düğümler otomatik olarak kaybolur.

Znode düğümü bir Watcher mekanizmasına sahiptir: Veri değiştiğinde, ZooKeeper bir Watcher olayı oluşturur ve bunu istemciye gönderir. İzleyici izleme mekanizması, Zookeeper'da çok önemli bir özelliktir.Zookeeper'da oluşturulan düğümlere dayanarak, izleme olaylarını bu düğümlere, düğüm veri değişikliklerini, düğüm silme işlemlerini, alt düğüm durum değişikliklerini ve diğer olayları izleme gibi bağlayabiliriz.Bu olay mekanizması sayesinde, Dağıtılmış kilit ve küme yönetimi gibi işlevler ZooKeeper temel alınarak gerçekleştirilebilir.

Denetleyici seçimi

Kafka'nın denetleyicileri seçmek için geçerli kuralları şunlardır: Kafka kümesinde başlatılan ilk aracı, ZooKeeper'da geçici bir düğüm / denetleyici oluşturarak kendisini bir denetleyici denetleyicisi yapar. Diğer aracılar da başlangıçta bu düğümü yaratmaya çalışacaklardır, ancak bu düğüm zaten var olduğu için, / controller düğümünü daha sonra oluşturmak istediğinizde, düğümün zaten var olduğuna dair bir istisna alacaksınız. Daha sonra diğer aracılar bu denetleyiciye bir ZooKeeper izleme nesnesi kaydeder. / Controller düğümü değiştiğinde, diğer aracılar düğüm değişikliği bildirimini alır. Bu şekilde yalnızca bir denetleyicinin var olduğundan emin olabilirsiniz. O zaman yalnızca tek bir düğümle ilgili bir sorun olmalı ve bu tek noktalı bir sorundur.

Denetleyici kapatılırsa veya ZooKeeper ile bağlantısı kesilirse, ZooKeeper'daki geçici düğüm kaybolur. Kümedeki diğer düğümler, izleme nesnesinin denetleyiciyi çevrimdışı olarak gönderdiği mesajını aldıktan sonra, diğer aracı düğümleri kendilerini yeni denetleyici yapmaya çalışır. Diğer düğümlerin oluşturma kuralları, ilk düğümün yaratma ilkeleriyle aynıdır.ZooKeeper'da başarıyla bir denetleyici düğümü oluşturan ilk aracı, yeni denetleyici olacak ve ardından diğer düğümler, düğümün mevcut istisnalarını alacaktır. Ardından, izlenecek yeni denetleyici düğümünde tekrar bir izleme nesnesi oluşturun.

Denetleyicinin rolü

Peki kontrol nedir? Denetleyicinin rolü nedir? Veya kontrolörün böyle bir bileşeninin tasarımı nedir? Merak etmeyin, bundan sonra bunun hakkında konuşacağız.

Kafka, bir durum makinesini simüle eden çok iş parçacıklı bir denetleyici olarak tasarlanmıştır ve aşağıdaki gibi çalışabilir:

Kontrolör, departmandaki departman üyelerini (komisyoncu) yönetmek için kullanılan departmandaki (küme) departman yöneticisine (komisyoncu kontrolörü) eşdeğerdir
Denetleyici, aracıların çevrimiçi ve çevrimdışı durumlarını izlemek için kullanılan tüm aracıların bir monitörüdür
Aracı kapandıktan sonra, denetleyici yeni bir bölüm Lideri seçebilir
Denetleyici, aracının yeni seçilen Liderine mesajlar gönderebilir

Aşağıdaki 5 noktaya bölünebilir

Konu yönetimi: Kafka Controller, Kafka konularına bölüm oluşturma, silme ve ekleme işlemlerini tamamlamamıza yardımcı olabilir.Kısacası, bölümler üzerinde en yüksek uygulama yetkisine sahiptir.

Diğer bir deyişle, kafka-topics komut dosyasını çalıştırdığımızda, arka plan çalışmasının çoğu denetleyici tarafından yapılır.

Bölüm yeniden dağıtımı: Bölüm yeniden dağıtımı, esas olarak kafka-reassign-partitions betiği tarafından sağlanan mevcut konu bölümlerinin ayrıntılı olarak tahsis edilmesini ifade eder. Fonksiyonun bu kısmı da kontrolör tarafından gerçekleştirilir.
Tercih edilen lider seçimi: Tercih edilen lider seçimi, esas olarak Kafka'nın bazı Broker'ların aşırı yüklenmesinden kaçınmak için lideri değiştirme planıdır.
Küme üye yönetimi: ana yönetim yeni komisyoncu, komisyoncu kapatma, komisyoncu kapalı kalma süresi
Veri hizmeti: Denetleyicinin son ana görevi, diğer aracılara veri hizmetleri sağlamaktır. En eksiksiz küme meta veri bilgileri denetleyicide saklanır ve diğer tüm aracılar, belleklerindeki önbelleğe alınmış verileri güncellemek için denetleyiciden düzenli olarak meta veri güncelleme istekleri alır. Aşağıda tartışacağımız bu veriler

Denetleyici, bir aracının kümeden ayrıldığını tespit ettiğinde (ilgili ZooKeeper yolunu gözlemleyerek), denetleyici bir mesaj alır: Bu aracı tarafından yönetilen bölümlerin yeni bir lidere ihtiyacı var. Denetleyici, kimin yeni Lider olabileceğini belirlemek için sırayla her bölümü geçecek ve ardından yeni Lider veya mevcut İzleyici içeren tüm bölümlere bir mesaj gönderecektir.İstek mesajı, yeni Liderin ve İzleyicinin kim olduğu hakkında bilgi içerir. Daha sonra, yeni Lider, üreticilerden ve tüketicilerden gelen talepleri işlemeye başlar ve Takipçi, yeni Liderden kopyalamak için kullanılır.

Bu, bir dış kaynak şirketinin bir departmanına çok benziyor.Bu departman iş gezilerine adanmıştır.Herkes farklı bir yerde çalışıyor, ancak merkezde bir departman yöneticisi var.Şimdi departman yöneticisi aniden istifa etti. Şirket dışarıdan personel almayı planlamaz, departman içerisinden yetkin bir kişiyi lider olarak seçmeye karar verir.Sonra liderin ekip üyelerine bir mesaj göndermesi gerekir.Bu mesaj randevu mesajıdır ve kimi yönettiğini açıklar. Hepsini öğrenin ve sonra her departman için çalışın.

Denetleyici, bir aracının kümeye katıldığını tespit ettiğinde, yeni katılan aracının var olan bölümün bir kopyasını içerip içermediğini kontrol etmek için aracı kimliğini kullanır. Bir denetleyici varsa, ileti yeni katılmış olan aracıya ve mevcut aracıya gönderilir.

Yukarıdaki bölüm kopyasının içeriği hakkında konuşacağız.

komisyoncu denetleyici veri depolama

Yukarıda, aracı denetleyicisinin büyük miktarda Kafka küme verisini depolamak için veri hizmetleri sağlayacağından bahsetmiştik. Aşağıda gösterildiği gibi

Yukarıda saklanan bilgiler, esas olarak üç kategoriye ayrılabilir.

Aracıdaki tüm bölümler, aracının tüm bölüm kopyaları, hangi aracıların şu anda çalışmakta olduğu ve hangi aracıların kapatıldığı dahil olmak üzere aracıya ilişkin tüm bilgiler.
Lider eşlemenin kim olduğu, hangi eşlemelerin ISR kümesinde olduğu gibi belirli bölüm bilgileri dahil olmak üzere tüm konu bilgileri.
İşletme ve bakım görevlerini içeren tüm bölümler. Şu anda Tercih edilen lider seçimi ve bölüm yeniden atamasından geçen bölümlerin listesini içerir.

Kafka, ZooKeeper'dan ayrılamaz, bu nedenle bu veri bilgileri ZooKeeper'a da kaydedilir. Denetleyici her başlatıldığında, ilgili meta verileri ZooKeeper'dan okuyacak ve kendi önbelleğine dolduracaktır.

broker denetleyicisi yük devretme

Daha önce de söylediğimiz gibi, ZooKeeper'da / brokers / id'ler altında bir düğüm yaratan ilk aracı, aracı denetleyici olarak görev yapar; bu, yalnızca bir aracı denetleyicisi olduğu anlamına gelir, bu nedenle kaçınılmaz olarak tek bir hata noktası olacaktır. Kafka, bu durumu dikkate almak için bir yük devretme işlevi sağlar, yani Yük Devretme. Aşağıda gösterildiği gibi

En başta, broker1 bir denetleyici olarak başarılı bir şekilde kaydolan ilk kişi olacak ve ardından broker1, ağ gerginliği veya diğer nedenlerden dolayı bırakılacaktır. ZooKeeper, İzleme mekanizması aracılığıyla broker1'in düşüşünü algılayacaktır. Bundan sonra, hayatta kalan tüm aracılar denetleyici olmak için rekabet etmeye başlayacak ve ardından ilk kaydolan broker3 olacak Başarılı, ZooKeeper tarafından depolanan denetleyici bilgileri artık broker1 tarafından kullanılıyor. > broker3, bundan sonra broker3, meta veri bilgilerini ZooKeeper'dan okuyacak ve kendi önbelleğinde başlatacaktır.

Not: ZooKeeper'da depolanan, önbellek bilgisi değildir, ancak aracıda depolanan, önbellek bilgisidir.

Broker denetleyicisiyle ilgili sorunlar

Kafka 0.11 sürümünden önce, denetleyicinin tasarımı oldukça külfetliydi. Yukarıda bir cümleden bahsetmiştik: Kafka denetleyici, bir durum makinesini simüle eden çok iş parçacıklı bir denetleyici olarak tasarlanmıştır.Bu tasarımın aslında bazı sorunları vardır.

Denetleyici durum değişiklikleri, farklı dinleyiciler tarafından eşzamanlı olarak yürütülür, bu nedenle karmaşık senkronizasyon gereklidir, hataya açık ve hata ayıklaması zordur.
Durum yayılımı senkronize değildir ve aracının belirsiz zamanlarda birden çok durumu olabilir ve bu da gereksiz ek veri kaybına neden olur.
Denetleyici denetleyicisi ayrıca konu silinmesi için ek G / Ç iş parçacıkları oluşturarak performans kaybına neden olur.
Denetleyicinin çok iş parçacıklı tasarımı, paylaşılan verilere de erişecektir.Paylaşılan verilere çok iş parçacıklı erişimin iş parçacığı senkronizasyonunun en zahmetli kısmı olduğunu biliyoruz. Veri güvenliğini korumak için, denetleyicinin kodda ReentrantLock senkronizasyon mekanizmasını kapsamlı bir şekilde kullanması gerekir, bu da daha da yavaşlar Tüm denetleyicinin işlem hızı.

Broker denetleyicisinin iç tasarım ilkesi

Kafka 0.11'den sonra Kafka denetleyicisi, çok iş parçacıklı çözümü tek iş parçacıklı ve olay kuyruğu çözümüne dönüştürerek yeni bir tasarım benimser. Aşağıda gösterildiği gibi

Ana değişiklikler aşağıdaki gibidir

İlk iyileştirme, bir olay yürütme iş parçacığı olan bir Olay Yürütme İş Parçacığının eklenmesidir.Şekilden görülebileceği gibi, ister Olay Kuyruğu olay kuyruğu ister Denetleyici bağlamı olsun, denetleyici bağlamı, işlem için olay yürütme iş parçacığına aktarılacaktır. Tüm orijinal işlemleri bağımsız olaylar olarak modelleyin ve bunları bu iş parçacığı tarafından tüketilmek üzere ayrılmış olay kuyruğuna gönderin.

İkinci iyileştirme, önceden senkronize edilmiş tüm ZooKeeper'ı asenkron çalışmaya değiştirmektir. ZooKeeper API, okumak ve yazmak için iki yol sağlar: eşzamanlı ve eşzamansız. Daha önce, kontrolör ZooKeeper'ı senkronize bir modda çalıştırdı.Bu sefer senkron mod asenkron olarak değiştirildi Teste göre verimlilik 10 kat arttı.

Üçüncü iyileştirme, istekleri önceliğe göre işlemektir Önceki tasarım, aracının denetleyici tarafından gönderilen tüm istekleri adil bir şekilde işleme almasıydı. Bu ne anlama geliyor? Adalet hala kötü mü? Bazı durumlarda bu doğrudur.Örneğin, aracı üretim isteğini işlemek için kuyruğa giriyor. Şu anda, denetleyici bir StopReplica isteği gönderiyor. Ne yapardınız? Hala ürün taleplerini işliyor musunuz? Bu üretim talebi hala yararlı mı? Şu anda, en makul işleme emri, StopReplica isteğine önceden işlenebilmesi için daha yüksek bir öncelik vermek olmalıdır.

Kopyalama mekanizması

Çoğaltma işlevi, Kafka mimarisinin temel işlevidir.Kafka belgelerinde Kafka, kendisini dağıtılmış, bölümlenebilir ve çoğaltılabilir kaydetme günlük hizmeti olarak tanımlar. Çoğaltmanın bu kadar kritik olmasının nedeni, mesajların kalıcı olarak depolanmasının çok önemli olmasıdır, bu da Kafka'nın birincil düğüm kapatıldıktan sonra hala yüksek oranda erişilebilir olmasını sağlayabilir. Kopyalama mekanizması, genellikle aynı veri yedeklemesini / kopyasını birden çok ağ etkileşim makinesinde depolayan dağıtılmış bir sistemi ifade eden bir yedekleme mekanizması (Replikasyon) olarak da adlandırılabilir.

Kafka, verileri düzenlemek için konular kullanır. Her konu birkaç bölüme ayrılmıştır. Bölümler bir veya daha fazla aracıya dağıtılacaktır. Her bölümün birden çok kopyası olacaktır, bu nedenle kopyalar aracıda da depolanacaktır. Komisyoncu binlerce kopya saklayabilir. Aşağıdaki şekil bir kopyanın şematik diyagramıdır

Yukarıdaki şekilde gösterildiği gibi, basitlik uğruna sadece iki aracı çizdim. Her aracı bir konuyu kaydeden bir mesaja başvurur. Broker1'de bölüm 0 liderdir, bölümlerin çoğaltılmasından sorumlu ve bölüm 0'ı broker1'de çoğaltır. Broker2 konu A'nın 0 bölümünün bir kopyası. Aynısı konu A'nın 1. bölümü için de geçerlidir.

İki tür kopya vardır: biri Lider (lider) kopya ve diğeri Takipçi (takipçi) kopya.

Lider kopyası

Kafka, bir bölüm oluştururken bir kopya seçmelidir ve bu seçilmiş kopya, Lider kopyasıdır.

Takipçi kopyası

Lider kopyası dışındaki kopyalar toplu olarak Takipçi kopyası olarak anılır ve Takipçi harici hizmetler sağlamaz. Lider kopyası şu şekilde çalışır

Bu resmin aşağıdaki noktalara dikkat etmesi gerekiyor

Kafka'da takipçi kopyası yani takipçi kopyası dışarıdan hizmet vermez. Bu, herhangi bir takipçi kopyasının tüketicilerden ve üreticilerden gelen taleplere cevap veremeyeceği anlamına gelir. Tüm talepler lider kopya tarafından ele alınır. Diğer bir deyişle, tüm istekler Lider kopyasının bulunduğu aracıya gönderilmelidir Takipçi kopyası yalnızca veri çekme için kullanılır ve Asenkron olarak çekilir ve Lider ile senkronizasyonu sağlamak için gönderim günlüğüne yazılır.
Lider kopyasının bulunduğu komisyoncu düştüğünde Kafka, onu gerçek zamanlı olarak tespit etmek ve yeni bir seçim turu başlatmak ve Lider olarak takipçi kopyalarından birini seçmek için ZooKeeper tarafından sağlanan izleme işlevine güvenir. Aşağı broker yeniden başlatılırsa, bölümün kopyası takipçi olarak yeniden birleştirilir.

Liderin bir başka görevi de hangi takipçinin durumunun kendisiyle tutarlı olduğunu bulmaktır. Takipçinin liderin durumu ile tutarlı olmasını sağlamak için, yeni bir mesaj gelmeden önce liderden mesajı kopyalamaya çalışır. Lider ile tutarlı olmak için, takipçi, lidere veri talebi başlatır.Bu talep, mesajı okumak için tüketicinin gönderdiği bilgiyle aynıdır.

Bir takipçinin lidere bir mesaj göndermesi süreci şu şekildedir: Önce mesaj 1'i isteyin, sonra mesaj 1'i alın, süre talep 1'e geldikten sonra, takipçiye göndermek için lideri almadan önce talep 2'yi gönderin, takipçiye Mesaj göndermeye devam etmeyecek. Süreç aşağıdaki gibidir

Takipçi kopyanın yanıt mesajını almadan önce mesaj göndermeye devam etmemesi önemlidir. Lider, her takipçinin talep ettiği en son ofsete bakarak, her takipçinin kopyasının ilerlemesini bilecektir. Takipçi 10 saniye içinde herhangi bir mesaj istemezse veya takipçinin bir istek göndermesine rağmen 10 saniye içinde bir mesaj almazsa, eşzamansız olarak kabul edilecektir. Bir kopya lider ile senkronize değilse, lider çevrimdışı olduktan sonra, mesajın kopyası tamamen olmadığı için kopya lider olarak adlandırılmaz.

Aksine, takipçinin senkronize edilmiş mesajı liderin kopyası ile tutarlıysa, bu takipçinin kopyasına da senkronize kopya denir. Başka bir deyişle, lider çevrimdışı olursa, yalnızca senkronize edilmiş kopya lider olarak adlandırılabilir.

Kopyalama mekanizması hakkında çok şey söyledik, öyleyse kopyalama mekanizmasının faydaları nelerdir?

Yazılı mesajı hemen görebilirsiniz, yani üretici API'yi kullanarak bölüme başarıyla bir mesaj yazdıktan sonra, tüketiciyi hemen yazılan mesajı okumak için kullanabilirsiniz.
Mesaj idempotansına ulaşmak ne demektir? Üretici tarafından üretilen mesaj için, tüketici tüketirken mesajın her seferinde var olduğunu görecek ve mesajın olmadığı bir durum olmayacaktır.

Eşzamanlı çoğaltma ve eşzamansız çoğaltma

Eşleme mekanizmasını öğrenirken bir sorum vardı: Lider eşleme ve takipçi eşleme göndermeyi bekleyen mekanizmalar olduğu için bu eşzamanlı bir eşleme yöntemidir, öyleyse takipçi eşlemesinin lider kopyayı eşitlediğini neden söylüyorsunuz? Eşzamansız işlemler ne olacak?

Bence durum budur. Takipçi kopya, lider kopyayı senkronize ettikten sonra mesajı yerel günlüğe kaydedecektir. Bu sırada, takipçi lider kopyaya bir yanıt mesajı verecek ve liderin başarıyla kaydedildiğini ve senkronizasyon çoğaltmasının lideri Yapımcı, tüm takipçi kopyalarının başarılı bir şekilde yazılmasını bekleyecek ve ardından yapımcıya başarı mesajı yazma mesajını geri verecektir. Eşzamansız çoğaltma, lider kopyanın takipçi kopyanın başarılı bir şekilde yazılıp yazılmadığına dikkat etmesine gerek olmadığı anlamına gelir Lider kopya, mesajı yerel günlüğe kaydettiği sürece, üreticiye bir başarı mesajı döndürecektir. Aşağıda, eşzamanlı çoğaltma ve eşzamansız çoğaltma işlemidir

Eşzamanlı çoğaltma

Üretici, lideri belirlemesi için ZooKeeper'ı bilgilendirir
Yapımcı, lidere bir mesaj yazar
Mesajı aldıktan sonra, lider mesajı yerel günlüğe yazacaktır.
Takipçiler liderden haberleri alacak
Takipçiler günlüğü yerel olarak yazar
Takipçi, lidere başarılı bir mesaj gönderir
Lider, tüm takipçilerden mesaj alacak
Lider, yapımcıya başarılı bir yazma mesajı gönderir

Eşzamansız çoğaltma

Senkronize çoğaltmadan farkı, lider yerel günlüğe yazdıktan sonra, tüm takipçilerin kopyalamasını beklemeden istemciye doğrudan bir yazma başarılı mesajı göndermesidir.

ISR

Kafka, ISR olarak adlandırılan bir dizi Eşzamanlı Kopyaları (bir dizi Eşzamanlı Kopyalar) dinamik olarak korur. ISR de çok önemli bir kavramdır. Daha önce de söylediğimiz gibi, takipçi kopyaları hizmet sağlamaz, ancak eşzamansız olarak düzenli olarak çekilir. Lider kopya sadece veridir.Bu işlemi yapmak kopyalamaya eşdeğerdir. Ctrl-c + ctrl-v herkese aşina olmalıdır. Öyleyse, ISR kümesindeki replika mesajlarının sayısının lider replika mesajlarının sayısıyla aynı olacağı anlamına mı geliyor? Bu mutlaka doğru değildir. Yargı, aracıdaki replica.lag.time.max.ms parametresinin değerine dayanır.Bu parametrenin anlamı, takipçi kopyanın lider kopyanın gerisinde kalabileceği en uzun zaman aralığıdır.

Replica.lag.time.max.ms parametresinin varsayılan süresi 10 saniyedir. Follower replikası, lider replikanın gerisinde en fazla 10 saniye kalıyorsa, Kafka lider ve follower'ın senkronize edildiğini düşünür. Takipçi kopyasında saklanan mesaj lider kopyadan daha küçük olsa bile. Takipçi kopya lider kopyanın 10 saniyeden fazla gerisindeyse, takipçi kopya ISR'den kaldırılacaktır. Kopya liderin ilerlemesini yavaşça yakalarsa, ISR'ye geri eklenebilir. Bu aynı zamanda ISR'nin statik değil dinamik olarak ayarlanmış bir koleksiyon olduğunu da gösterir.

Temiz olmayan lider seçimi

ISR dinamik olarak ayarlanabildiğinden, kaçınılmaz olarak ISR kümesinin boş olması durumu olacaktır. Lider kopyanın ISR kümesinde görünmesi gerektiğinden, ISR kümesi boştur, bu da lider kopyanın da kapatıldığı anlamına gelir, yani şu anda Kafka'nın yeni bir lideri yeniden seçmesi gerekiyor, öyleyse nasıl seçilir? Şimdi fikrinizi değiştirmeniz gerekiyor. Yukarıda ISR kümesinin liderle senkronize edilmiş bir kopya olması gerektiğini, bu nedenle ISR kümesindeki kopyanın liderle senkronize olmayan bir kopya olması gerektiğini, yani ISR listesinde takipçi olmaması gerektiğini söyledik. Kopya bazı mesajları kaybedecek. Aracı tarafı parametresini unclean.leader.election.enable'ı etkinleştirirseniz, sonraki lider bu eşzamansız kopyalardan seçilir. Bu seçim aynı zamanda Temiz olmayan lider seçimi olarak da adlandırılır.

Dağıtılmış projelerle temas halindeyseniz, CAP teorisini bilmeniz gerekir, o zaman bu Temiz olmayan lider seçimi aslında veri tutarlılığından ödün verir ve Kafka'nın yüksek kullanılabilirliğini sağlar.

Gerçek iş senaryonuza göre Temiz olmayan lider seçimini etkinleştirip etkinleştirmeyeceğinize karar verebilirsiniz. Veri tutarlılığı kullanılabilirlikten daha önemli olduğu için genellikle bu parametrenin etkinleştirilmesi önerilmez.

Kafka istek işleme akışı

Aracının işinin çoğu, istemcilerden, bölüm çoğaltmalarından ve denetleyicilerden bölüm liderlerine kadar gelen istekleri işlemektir. Bu tür bir istek genellikle istek / yanıttır, sanırım onunla iletişim kurduğunuz en erken istek / yanıt yolu HTTP isteği olmalıdır. Aslında, HTTP istekleri eşzamanlı veya eşzamansız olabilir. Genel olarak, normal HTTP istekleri eşzamanlıdır ve eşzamanlı yöntemin en büyük özelliği isteği göndermektir. > Sunucu işlemesi bekleniyor > İşlem tamamlandıktan sonra, istemci tarayıcısı bu süre boyunca hiçbir şey yapamaz. Eşzamansız yöntemin en büyük özelliği, isteğin bir olay tarafından tetiklenmesidir. > Sunucu işleme (tarayıcı şu anda başka şeyler de yapabilir) - > İşlem tamamlandı.

O zaman senkronize isteklerin sıralı olarak işlendiğini söyleyebilirim, ancak asenkron isteklerin yürütme yöntemi belirsizdir, çünkü asenkron, birden fazla yürütme iş parçacığı oluşturulmasını gerektirir ve her iş parçacığının yürütme sırası farklıdır.

Burada dikkat edilmesi gereken bir nokta, yalnızca HTTP isteklerini örnek olarak kullanıyoruz, Kafka ise Soket tabanlı iletişim kurmak için TCP kullanıyor.

Peki bu iki yöntemin dezavantajları nelerdir?

Akıllı olan sizlerin, senkronizasyon yönteminin en büyük dezavantajının, verimin çok zayıf olması ve kaynak kullanımının son derece düşük olması olduğunu hemen düşünebilmeniz gerektiğine inanıyorum.İstekler yalnızca sırayla işlenebildiği için, her istek bir önceki talebin işlenmesini beklemelidir. uğraşmak. Bu yöntem yalnızca çok seyrek istekleri olan sistemler için uygundur.

Eşzamansız yöntemin dezavantajı, her istek için bir iş parçacığı oluşturma uygulamasının son derece pahalı olması ve hatta bazı senaryolarda tüm hizmeti alt üst edebilmesidir.

Duyarlı model

Bunu uzun süredir söylemişken, Kafka eşzamanlı mı yoksa eşzamansız mı? Hayır, Kafka reaktif (Reaktör) bir model kullanıyor, öyleyse reaktif model nedir? Basitçe ifade etmek gerekirse, Reactor modu, aşağıdaki şekilde gösterildiği gibi, birden çok istemcinin sunucuya eşzamanlı olarak istek gönderdiği senaryolar için özellikle uygun olan, olay odaklı mimarinin bir uygulamasıdır.

Kafka'nın aracısı, bir işlemciye benzer bir SocketServer bileşenine sahiptir. SocketServer, TCP tabanlı bir Soket bağlantısıdır. İstemci isteklerini kabul etmek için kullanılır. Tüm istek mesajları, aşağıdaki bilgileri içeren bir ileti başlığı içerir

İstek türü (aka API Anahtarı)
Talep sürümü (broker, farklı sürümlerin istemci isteklerini ele alabilir ve istemci sürümüne göre farklı yanıtlar verebilir)
Korelasyon Kimliği - istek mesajını tanımlamak için kullanılan ve aynı zamanda yanıt mesajında ve hata günlüğünde görünecek olan benzersiz bir numara (sorunları teşhis etmek için kullanılır)
İstemci Kimliği - İsteği gönderen müşteriyi tanımlamak için kullanılır

Aracı, izlediği her bağlantı noktasında bir Acceptor iş parçacığı çalıştırır. Bu iş parçacığı bir bağlantı oluşturur ve bunu İşlemciye (ağ iş parçacığı havuzu) devreder. İşlemci sayısı num.network.threads kullanılarak yapılandırılabilir. Varsayılan değerdir Değer 3'tür, yani her broker başladığında, istemci tarafından gönderilen istekleri işlemek için 3 iş parçacığı oluşturulacaktır.

Acceptor iş parçacığı, yığın isteğini ağ iş parçacığı havuzuna adil bir şekilde göndermek için yoklamayı kullanır. Bu nedenle, gerçek kullanımda, bu iş parçacıkları genellikle bekleyen istek kuyruğuna tahsis edilme ve daha sonra yanıt kuyruğundan elde edilme olasılığına sahiptir. Mesajlara yanıt olarak, müşteriye gönderin. Ağ iş parçacığı havuzu yanıt işlemindeki işlemci istekleri hala daha karmaşıktır, aşağıda ağ iş parçacığı havuzundaki işlem akış şeması verilmiştir

İşlemci ağ iş parçacığı havuzu, istemci ve diğer aracılar tarafından gönderilen mesajı aldıktan sonra, ağ iş parçacığı havuzu mesajı istek kuyruğuna koyacaktır.Bunun paylaşılan bir istek kuyruğu olduğuna dikkat edin.Ağ iş parçacığı havuzu çok iş parçacıklı bir mekanizma olduğundan, istek kuyruğunun mesajı istenir. Birden fazla iş parçacığı tarafından paylaşılan ve daha sonra IO iş parçacığı havuzu tarafından işlenen bir alandır.Mesajın türüne göre, ne yapılacağına karar verilir.Örneğin, bir PRODUCE isteği mesajı günlüğe yazar.Eğer bu bir FETCH isteği ise, diskten veya sayfadan önbelleğe alınacaktır. Mesajı oku. Başka bir deyişle, IO iş parçacığı havuzu, gerçekten yargıda bulunan ve istekleri işleyen bir bileşendir. IO iş parçacığı havuzu işlendikten sonra, yanıt kuyruğuna mı yoksa Araf'a mı yerleştirildiğine karar verilecek. Araf nedir? Aşağıda bunun hakkında konuşalım. Şimdi yanıt kuyruğundan bahsedelim. Yanıt kuyruğu, reaktif model nedeniyle her iş parçacığı için benzersizdir. İsteğin nereye gönderildiği umurunda değil, bu nedenle yanıt her iş parçacığına bırakılıyor, bu nedenle paylaşmaya gerek yok.

Not: GÇ iş parçacığı havuzu, aracı tarafı parametresi num.io.threads aracılığıyla yapılandırılabilir.Varsayılan iş parçacığı sayısı 8'dir, yani her aracı başlatıldıktan sonra 8 GÇ işleme iş parçacığı otomatik olarak oluşturulur.

İstek Türü

Aşağıda birkaç yaygın istek türü bulunmaktadır

Üretim talebi

Gerçekten Kafka'ya giriş hakkında bir şeyler okumak yeterli.Makalede acks yapılandırma öğesinin anlamından bahsediliyordu.

Basitçe söylemek gerekirse, farklı konfigürasyonların farklı yazma başarısı tanımları vardır. Acks = 1 ise, lider bir mesaj aldığı sürece, yazmanın başarılı olduğu anlamına gelir. Acks = 0 ise, lider bir mesaj gönderdiği sürece yazmak anlamına gelir. Başarı, geri dönüş değerinin etkisini dikkate almak zorunda değildir. Acks = all ise, liderin yazma başarısını ifade etmeden önce mesajın tüm kopyalarını alması gerektiği anlamına gelir.

Mesaj bölümün liderine yazıldıktan sonra, eğer acks yapılandırmasının değerinin tamamı ise, bu istekler Araf tamponunda saklanacaktır, lider kopya, takipçi kopyasının mesajı kopyaladığını bulana kadar, cevap Müşteriye gönderildi.

İstek alın

Aracının isteği alma yolu, üretim talebinin işlenme şekline benzer. İstemci bir istek gönderir ve aracıdan konu bölümünde belirli bir kayma olan bir ileti ister. Kayma varsa, Kafka mesajı istemciye göndermek için sıfır çoğaltma teknolojisini kullanır. Kafka Mesaj, daha iyi performans elde etmek için herhangi bir tampondan geçmeden doğrudan dosyadan ağ kanalına gönderilecektir.

İstemci, istenen veriyi elde etmek için üst ve alt sınırları ayarlayabilir Üst sınır, istemci tarafından yeterli mesaj almak için ayrılan bellek alanıyla ilgilidir. Bu sınır daha önemlidir. Üst sınır çok büyükse, istemcinin belleğini doğrudan tüketme olasılığı yüksektir. Alt sınır, yeterli veri paketinin kaydedilip gönderilmesinin anlamı olarak anlaşılabilir, bu da proje yöneticisinin programcıya 10 hata atamasına eşdeğerdir.Programcı her hata değiştirdiğinde proje yöneticisine rapor edecektir, bazen de değişir. Bazen düzeltilemeyebilir, bu da iletişim maliyetini ve zaman maliyetini artırır, bu nedenle alt sınır, programcının siz 10 hatayı düzelttikten sonra bana rapor vermesidir! ! ! Aşağıda gösterildiği gibi

Resimde gördüğünüz gibi mesaj çekiliyor --- > Mesajlar arasında mesaj birikimini bekleme süreci vardır, bu mesaj birikimini bir zaman aşımı süresi olarak düşünebilirsiniz, ancak zaman aşımı sona erdiğinde bir istisna meydana gelir ve mesajların birikimi sona erdikten sonra bir alındı mesajı yanıtlanır. Gecikme süresi replica.lag.time.max.ms aracılığıyla yapılandırılabilir; bu, replikanın iletileri çoğaltırken izin verebileceği maksimum gecikme süresini belirtir.

Meta veri isteği

Hem üretim talebi hem de yanıt isteği lider kopyaya gönderilmelidir. Aracı belirli bir bölüm için bir istek alırsa ve isteğin lideri başka bir aracıda ise, isteği gönderen istemci bölüm olmayan bölümün liderini alacaktır. Hata yanıtı; lider içermeyen bir aracıya belirli bir bölüm için istek gönderilirse aynı hata ortaya çıkar. Kafka istemcisinin, isteği ve yanıtı doğru aracıya göndermesi gerekir. Bu saçma değil mi? Nereye göndereceğimi nasıl bilebilirim?

Aslında, müşteri, istemcinin ilgilendiği konuların bir listesini içeren bir meta veri isteği kullanacaktır ve sunucunun yanıt mesajı konu bölümünü, lider kopyayı ve takipçi kopyasını belirtir. Meta veri istekleri, tüm aracılar bu bilgileri önbelleğe aldığından herhangi bir aracıya gönderilebilir.

Normal koşullar altında, istemci bu bilgileri önbelleğe alır ve doğrudan üretim isteklerini ve karşılık gelen istekleri hedef aracına gönderir.Bu önbelleklerin aralıklarla yenilenmesi gerekir. Meta verileri bilmek üzere yapılandırmak için metadata.max.age.ms parametresini kullanın. Değişti mi? Örneğin, yeni bir komisyoncu katıldıktan sonra, yeniden dengeleme tetiklenecek ve bazı kopyalar yeni komisyoncuya taşınacaktır. Bu sırada, istemci lider olmayan bir hata alırsa, istemci, isteği göndermeden önce meta veri önbelleğini yeniler.

Kafka yeniden dengeleme süreci

Gerçekten, Kafka'ya giriş için bu makaleyi okumak yeterli. Tüketicileri anlatırken kabaca tüketici grupları arasındaki ilişkiden ve yeniden dengelemeden bahsetmiştim. Aslında, bu gruptaki tüm tüketim için tek bir nokta olarak özetlenebilir. Tüketici örneği, hangi konu bölümlerinin kullanılacağını kabul eder.

Bir tüketici grubunun bir grup koordinatörüne (Koordinatör) sahip olması gerektiğini biliyoruz ve yeniden dengeleme süreci Koordinatör yardımı ile tamamlandı.

Burada yeniden dengelemenin gerçekleştiği koşulları beyan etmeniz gerekir.

Tüketici tarafından abone olunan herhangi bir konu değişir
Tüketici sayısındaki değişiklikler
Bölüm sayısı değişti
Henüz oluşturulmamış bir konuya abone olursanız, konu oluşturulduğunda yeniden dengeleme gerçekleşir. Abone olduğunuz konu silinirse, yeniden dengeleme de gerçekleşir
Tüketici, grup koordinatörü tarafından, tüketici çarpışmasından veya uzun süre çalışır durumda olmasından kaynaklanabilecek ÖLÜ durumda kabul edilir.Bu, tüketicinin makul bir zaman aralığı içinde grup koordinatörüne hiçbir şey göndermediği anlamına gelir. Yeniden dengelemeye de yol açabilen kalp atışı.

Yeniden dengelemeyi anlamadan önce, bu iki rolü bilmeniz gerekir

Koordinatör: Koordinatör, tüketici grubundaki tüm tüketicilerden kalp atışı mesajları alabilen bir komisyoncudur. En eski sürümde, meta veri bilgileri ZooKeeper'da depolanır, ancak şu anda meta veri bilgileri aracıda depolanır. Her tüketici grubu, gruptaki grup koordinatörü ile senkronize edilmelidir. Uygulama düğümünde tüm kararlar alınacağı zaman, grup koordinatörü JoinGroup talebini karşılayabilir ve tahsis ve mahsup gibi tüketici grubu hakkında meta veri bilgileri sağlayabilir. Grup koordinatörü aynı zamanda tüm tüketicilerin kalp atışlarını bilme hakkına sahiptir.Tüketici grubunda lider olan başka bir rol daha vardır, onu lider kopya ve kafka denetleyiciden ayırmaya dikkat edin. Lider, grupta karar vermekten sorumlu olan roldür, bu nedenle lider çevrimdışı olursa, grup koordinatörü tüm tüketicileri gruptan atma hakkına sahiptir. Bu nedenle, tüketici grubunun çok önemli bir davranışı, bir lider seçmek ve koordinatörle birlikte tahsis ve bölümleme ile ilgili meta veri bilgilerini okumak ve yazmaktır.

Tüketici lideri: Her tüketici grubunun bir lideri vardır. Tüketici kalp atışı göndermeyi bırakırsa, koordinatör bir yeniden dengeleme başlatacaktır.

Yeniden dengelemeyi anlamadan önce, bir durum makinesinin ne olduğunu bilmeniz gerekir.

Kafka, koordinatörün tüm yeniden dengeleme sürecini tamamlamasına yardımcı olmak için bir dizi tüketici grubu durum makinesi (Durum Makinesi) tasarladı. Tüketici durumu makinesinin beş ana durumu vardır: Boş, Çalışmıyor, Yeniden Dengeleme Hazırlanıyor, Yeniden Dengeyi Tamamlanıyor ve Kararlı.

Bu durumların anlamını anladıktan sonra, tüketici durumlarının rotasyonunu temsil etmek için birkaç yol kullanalım.

Tüketici grubu ilk başta Boş durumdadır. Yeniden dengeleme açıldığında, yeni tüketicilerin katılmasını beklemek için Hazırlama Yeniden Dengesi durumuna getirilecektir. Yeni bir tüketici katıldığında, tüketici grubu Tahsisi Tamamlanıyor Yeniden Dengeleme durumunda olacaktır. Yeni bir tüketici gruba katıldığı veya ayrıldığı sürece, yeniden dengeleme tetiklenecek ve tüketicinin durumu Yeniden Dengeleme Hazırlanıyor durumundadır. Tahsis mekanizmasının belirlenip tahsis işlemini tamamlamasını bekleyin, ardından akış şeması şöyle olur