|
|
Yayınlandı 13.04.2021 11:45:31
|
|
|
|
Kafka, LinkedIn tarafından geliştirilen, günlük toplama, veri akışı, çevrimiçi ve çevrimdışı mesaj dağıtımı gibi senaryolarda yaygın olarak kullanılan yüksek performanslı, dağıtık bir mesajlaşma sistemidir. Geleneksel bir MQ olarak tasarlanmasa da, Kafaka çoğu durumda ActiveMQ gibi geleneksel mesajlaşma sistemlerinin yerini alabilir.
Kafka, mesaj akışını konulara göre düzenler ve mesajları saklayan sunucuya broker denir; tüketiciler bir veya daha fazla konuya abone olabilir. Yükü dengelemek için, bir konunun mesajları birden fazla bölüme ayrılabilir ve ne kadar çok bölüm olursa, Kafka'nın paralelliği ve verimliliği o kadar yüksek olur.
Kafka kümeleri kümeleri oluşturmak için zookeeper desteğine ihtiyaç duyar ve zookeeper zaten en son Kafka dağıtımında yer almaktadır; bu dağıtım aynı anda hem zookeeper sunucusu hem de Kafka sunucusu başlatabilir veya mevcut diğer zookeeper kümelerini kullanabilir.
Geleneksel MQ'nun aksine, tüketiciler bir ofseti kendi başlarına tutmalıdır ve kafka'dan mesaj alırken, sadece mevcut ofsetten sonra mesajları çekerler. Kafka'nın scala/java istemcisi, ofseti hayvanat bahçesi görevlisine kaydederek bu mantığın bu kısmını zaten uygular. Her tüketici bir kimlik seçebilir ve aynı kimliğe sahip tüketiciler aynı mesajı yalnızca bir kez alır.Bir konunun kullanıcıları aynı kimlik kullanıyorsa, bu geleneksel bir Kuyruk olur. Her tüketici farklı bir kimlik kullanıyorsa, bu geleneksel bir pub-sub'tır.
Eleştiri:
Kafka tüketimi
1. Aynı group_id tüketicileri, yalnızca bir kullanıcı mesaj tüketebilir (Kuyruk kuyruğu modu）
2. Farklı group_id tüketiciler aynı haberi alır
Kafka'nın Avantajları
Dağıtık ve yüksek ölçeklenebilir. Kafka kümeleri, kümelere yeni sunucular eklemek için şeffaf şekilde ölçeklenebilir.
Yüksek performans. Kafka'nın performansı, özellikle toplu işlemleri destekleyen Kafka gibi ActiveMQ ve RabbitMQ gibi geleneksel MQ uygulamalarının büyük ölçüde üstündedir. Aşağıdaki görsel, LinkedIn'in tüketici performans stres testinin sonuçlarını göstermektedir:
Hata toleransı. Kafka'daki her bölümden gelen veriler birkaç sunucuya çoğaltılır. Bir broker başarısız olduğunda, ZooKeeper hizmeti üreticiyi ve tüketiciyi bilgilendirir ve tüketici başka bir broker'a geçer.
Kafka'nın Dezavantajları:
Mesajları tekrar et. Kafka, her mesajın en az bir kez teslim edileceğini garanti eder ve olasılıklar düşük olsa da, bir mesajın birden fazla kez teslim edilme ihtimali vardır.
Haber sıradan çıktı. Bir bölüm içindeki mesajların düzenli olması garanti edilse de, bir konuda birden fazla bölüm varsa, bölümler arasındaki mesajın düzenli olması garanti edilmez.
Karmaşıklık. Kafka, hayvanat bahçesi görevlisi kümelerinin desteğini gerektirir ve konular genellikle genel mesaj kuyruklarından daha pahalı olan yapım, dağıtım ve bakım için manuel emeği gerektirir
.NET/C# mesaj kuyruğu Kafka operasyonları
İlk olarak, .NET Core 3.1 kullanarak Kafka-Consumer ve Kafka-Producer olmak üzere iki yeni konsol projesi oluşturun
Confluent.Kafka paketine şu şekilde referans vermek için nuget kullanın, aşağıdaki komutla:
GitHub adresi:Bağlantı girişi görünür.
Önce Üretici programını başlatırız ve önce tüketiciyi başlatırsak aşağıdaki hatayı alırız:
Hata meydana geldi: Broker: Bilinmeyen konu veya bölüm
Bu makale ayarları tüketecekEnableAutoOffsetStore yanlış, yani ofset depolamayı manuel olarak ayarlamak (manuel onay mesajına benzer)
Tüketiciler, tüketimden sonra OffsetStore'u ayarlamaz
Üreticiyi kullanarak iki mesaj üretmeye çalışın, tüketici tüketimini açın, MaxPollIntervalMs = 10000 // 10 saniye manuel ayar yapmadan, diğer istemcilerin tüketmesine izin verin, tabii ki 10 saniye içinde diğer istemci tarafından tüketilmez
MaxPollIntervalMs açıklar
İleri tüketiciler için ise maksimum mesaj kullanımı için arama süresi (örneğin, rd_kafka_consumer_poll()) olarak verilirdi. Bu aralık aşılırsa, tüketici başarısız sayılır ve grup yeniden dengelenir, böylece bölüm başka bir tüketici grubu üyesine yeniden atanır. Uyarı: Şu anda ofset commit'ler mümkün olmayabilir. Not: Uzun süre işlem gören uygulamalar için "enable.auto.offset.store=false" ayarlanması ve mesaj işlendikten sonra ofsetin otomatik olarak bağlanmaması için ofseti açıkça (offsets_store()) kullanarak* saklanması önerilir. Saniyede bir kez iki aralıkla kontrol edin. Daha fazla bilgi için KIP-62'ye bakınız.
Çizimler aşağıdaki gibidir:
OffsetStore, tüketici harcamayı tamamladıktan sonra ayarlanır
kod
Kurulum tamamlandıktan sonra 10 saniye bekleyin, yine de çalışıyorSon mesajı aldım(Tüketici aracı kuruma bağlandığında,Tüketimle ofset pozisyonundan başlatEğer c.Commit(cr) ayarlanmışsa; Son mesaj tekrar tekrar alınmayacak.
Kaynak kodunu görüntüle
commit +1 commit ve sonunda Librdkafka.topic_partition_list_destroy(cOffsets) çağırır;
Bağlantı girişi görünür.
Bağlantı girişi görünür.
Farklı bir GroupId kur
Komut satırı parametresi üzerinden farklı bir GroupId ayarlayın ve ardından üretici aracılığıyla bir mesaj gönderin, aşağıdaki görselde gösterildiği gibi:
Hem clinet1 hem de client2Tarihsel mesajlar alın, ve yapımcı bir mesaj gönderdikten sonra, ikisi de neredeyseMesajları aynı anda alın。
Yeni tüketiciler sadece yeni mesajlar alır
Yeni bir müşteriye sadece yeni mesajlar gönderip geçmiş verileri görmezden gelmesini nasıl sağlarsınız?
Ayarlar şu şekildedir:
Aşağıda gösterildiği gibi:
Üretici kodu
Şöyle:
Tüketici kodu
Şöyle:
Kaynak kodu indirme
Turistler, bu gönderinin gizli içeriğini görmek isterseniz lütfen Yanıt
|
Önceki:.NET/C# İstisnası, Tencent Enterprise Posta Kutusu kullanılıyor: İşlem zamanlamış.Önümüzdeki:NuGet önbelleği temizler
|
Ev sahibi|
Yayınlandı 15.04.2021 09:31:05
|
Yayınlandı 16.06.2021 12:41:09
|
