Kafka üzerinde RabbitMQ kullanmak için herhangi bir sebep var mı?

Kafka yerine RabbitMQ'yu değerlendirmem istendi, ancak Kafka'dan daha iyi bir şey yapmasının bir nedenini bulmakta zorlandım. Verim, dayanıklılık, gecikme veya kullanım kolaylığı açısından gerçekten daha iyi olup olmadığını bilen var mı?

RabbitMQ, AMQP, MQTT, STOMP, vb.Gibi çeşitli protokolleri destekleyen sağlam, genel amaçlı bir mesaj brokeridir . Yüksek verimi işleyebilir. RabbitMQ için yaygın bir kullanım örneği, arka plan işlerini veya dosya tarama , görüntü ölçekleme veya PDF dönüştürme gibi uzun süredir devam eden görevleri işlemektir . RabbitMQ ayrıca, uygulamalar arasında iletişim kurma ve mesaj ileten darboğazları önleme görevi gören mikro hizmetler arasında da kullanılır.

Kafka, yüksek veri akışı ve tekrar oynatma için optimize edilmiş bir mesaj veri yoludur. Çok miktarda veri taşımak, verileri gerçek zamanlı olarak işlemek veya belirli bir süre boyunca verileri analiz etmek istediğinizde Kafka'yı kullanın. Başka bir deyişle, verilerin toplanması, saklanması ve işlenmesi gerektiği yerler. Bir web mağazasındaki kullanıcı etkinliğini izlemek ve satın almak için önerilen öğeleri oluşturmak istediğinizde bir örnek verilebilir. Başka bir örnek, izleme, yutma, günlük tutma veya güvenlik için veri analizidir.

Kafka, uygulamaların diskteki akışlı verileri işleyebildiği ve yeniden işleyebildiği dayanıklı bir mesaj aracısı olarak görülebilir . Kafka'nın çok basit bir yönlendirme yaklaşımı var. İletilerinizi karmaşık yollarla tüketicilerinize yönlendirmeniz gerekiyorsa RabbitMQ daha iyi seçeneklere sahiptir. Çevrimdışı olabilecek toplu tüketicileri veya düşük gecikme süresinde mesaj isteyen tüketicileri desteklemeniz gerekiyorsa Kafka'yı kullanın. 

Kafka'dan veri okumayı anlamak için öncelikle tüketicilerini ve tüketici gruplarını anlamamız gerekiyor. Bölümler, verileri birden çok düğüme bölerek bir konuyu paralelleştirmenize olanak tanır. Bir bölümdeki her kayıt benzersiz ofseti ile atanır ve tanımlanır. Bu ofset, bir bölümdeki kaydı gösterir. Kafka'nın en son sürümünde, Kafka bir bölümdeki her kayıt için sayısal bir ofset tutar. Kafka'daki bir tüketici periyodik olarak otomatik olarak ofset yapabilir veya bu taahhütlü pozisyonu manuel olarak kontrol etmeyi seçebilir. RabbitMQ, tüketilen / onaylanan / onaylanmayan mesajlarla ilgili tüm durumları saklayacaktır. Kafka'nın anlaşılması gereken mesajın kuyruğa alındığı TavşanMQ örneğinden daha karmaşık olduğunu düşünüyorum.

RabbitMQ'nun kuyrukları boş olduklarında en hızlı olurken, Kafka çok az yük ile büyük miktarda veri tutar - Kafka büyük hacimli mesajları tutmak ve dağıtmak için tasarlanmıştır. (RabbitMQ'da çok uzun kuyruklara sahip olmayı planlıyorsanız, tembel kuyruklara bir göz atabilirsiniz .)

Kafka sıfırdan yatay ölçeklendirme (daha fazla makine ekleyerek ölçeklendirme) düşünülerek oluşturulurken, RabbitMQ çoğunlukla dikey ölçeklendirme (daha fazla güç ekleyerek ölçeklendirme) için tasarlanmıştır.

RabbitMQ, bir web tarayıcısından RabbitMQ sunucunuzu izlemenizi ve yönetmenizi sağlayan yerleşik kullanıcı dostu bir arayüze sahiptir. Diğer şeylerin yanı sıra, kuyruklar, bağlantılar, kanallar, exchange'ler, kullanıcılar ve kullanıcı izinleri ele alınabilir - oluşturulabilir, silinebilir ve tarayıcıda listelenebilir ve mesaj oranlarını izleyebilir ve manuel olarak mesaj gönderebilir / alabilirsiniz. Kafka, bir dizi açık kaynak araca ve ayrıca bir kez ticari , yönetim ve izleme işlevlerine sahiptir. RabbitMQ'yu iyi anlamanın kolaylaştığını / hızlandığını söyleyebilirim.

Daha fazla okuma ve bazı karşılaştırma verileri burada bulunabilir: https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html

Ayrıca endüstri belgesini tavsiye ediyoruz: "Kafka'ya karşı RabbitMQ: İki endüstri referansı yayınlama / abone olma uygulamasının karşılaştırmalı bir çalışması": http://dl.acm.org/citation.cfm?id=3093908

Hizmet olarak Apache Kafka ve RabbitMQ sağlayan bir şirkette çalışıyorum.

Bu soruyu her hafta duyuyorum ... RabbitMQ (IBM MQ veya JMS veya genel olarak diğer mesajlaşma çözümleri gibi) geleneksel mesajlaşma için kullanılırken, Apache Kafka akış platformu (mesajlaşma + dağıtılmış depolama + veri işleme) olarak kullanılır. Her ikisi de farklı kullanım durumları için üretilmiştir.

Kafka'yı "geleneksel mesajlaşma" için kullanabilirsiniz, ancak Kafka'ya özgü senaryolar için MQ kullanamazsınız.

“ Apache Kafka mı, Kurumsal Servis Otobüsü (ESB) -Arkadaşlar, Düşman mı, yoksa Frenemiler mi? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/ ) ”, Kafka'nın neden rekabetçi değil, entegrasyon ve mesajlaşma çözümlerini tamamlayıcı olduğunu tartışıyor (RabbitMQ dahil) ve her ikisinin nasıl entegre edileceği.

5 Kafka ve RabbitMQ arasındaki büyük farklar , bunları kullanan müşteri:

Hangi mesaj sistemini seçmeli veya mevcut mesajlaşma sistemimizi değiştirmeliyiz?

Yukarıdaki sorunun cevabı yok. Hangi mesajlaşma sistemini karar vermek zorunda veya sistemin mevcut değişir gerektiğini incelemeye Olası bir yaklaşım “olduğunu kapsamını ve maliyetini değerlendirin ”

Unutmayacağınız önemli bir fark, RabbitMQ'nun push tabanlı mesajlaşma sistemidir, Kafka ise çekmeli mesajlaşma sistemidir. Bu, mesajlaşma sisteminin farklı işleme yeteneklerine sahip farklı tüketici türlerini karşılamak zorunda olduğu senaryoda önemlidir. Çekme tabanlı sistem ile tüketici, itme sistemlerinin mesajları tüketicinin durumuna bakılmaksızın ileteceği ve böylece tüketiciyi yüksek risk altına sokabileceği kapasitelerine göre tüketebilir.

RabbitMQ geleneksel bir genel amaçlı mesaj brokeridir. Web sunucularının isteklere hızlı yanıt vermesini ve birden çok hizmete mesaj göndermesini sağlar. Yayıncılar, tüketicileri alabilmeleri için iletileri yayınlayabilir ve kuyruklarda kullanılabilir hale getirebilir. İletişim asenkron veya senkron olabilir.

Öte yandan Apache Kafka değil sadece bir mesaj komisyoncu. Başlangıçta LinkedIn tarafından bir mesaj kuyruğu olarak kullanılmak üzere tasarlanmış ve uygulanmıştır. 2011 yılından bu yana, Kafka açık kaynaklı ve hızlı bir şekilde gerçek zamanlı veri boru hatlarının ve akış uygulamalarının uygulanması için kullanılan dağıtılmış bir akış platformuna dönüştü.

Yatay olarak ölçeklendirilebilir, hataya dayanıklı, hızlı fitil ve binlerce şirkette üretim yapmaktadır.

Modern kuruluşlar, sistemler veya hizmetler arasındaki iletişimi kolaylaştıran çeşitli veri boru hatlarına sahiptir. Makul sayıda hizmetin gerçek zamanlı olarak birbirleriyle iletişim kurması gerektiğinde işler biraz daha karmaşık hale gelir.

Bu hizmetlerin karşılıklı iletişimini sağlamak için çeşitli entegrasyonlar gerektiğinden mimari karmaşıklaşır. Daha doğrusu, m kaynağı ve n hedef hizmeti kapsayan bir mimari için nxm farklı entegrasyonlarının yazılması gerekir. Ayrıca, her entegrasyon farklı bir spesifikasyonla gelir, yani biri farklı bir protokol (HTTP, TCP, JDBC, vb.) Veya farklı bir veri gösterimi (İkili, Apache Avro, JSON, vb.) Gerektirebilir, bu da işleri daha da zorlaştırır . Ayrıca, kaynak hizmetleri, gecikmeyi potansiyel olarak etkileyebilecek bağlantılardan artan yükü de ele alabilir.

Apache Kafka, veri boru hatlarını ayırarak daha basit ve yönetilebilir mimarilere öncülük ediyor. Kafka, kaynak hizmetlerinin veri akışlarını zorladığı yüksek verimli dağıtılmış bir sistem gibi davranarak, hedef hizmetlerin gerçek zamanlı olarak çekmesini sağlar.

Ayrıca, Kafka Kümelerini yönetmek için birçok açık kaynak ve kurumsal düzeyde Kullanıcı Arabirimi artık kullanılabilir. Daha fazla ayrıntı için makalelere bakın Apache Kafka kümeleri için kullanıcı arayüzü izleme araçlarına genel bakış ve Neden Apache Kafka?

RabbitMQ veya Kafka'ya gidip gitmeme kararı projenizin gereksinimlerine bağlıdır. Genel olarak, basit / geleneksel bir pub-sub mesaj komisyoncusu istiyorsanız RabbitMQ için gidin. Üstüne organizasyonunuzun gerçek zamanlı olarak etkinliklerde bulunacağı etkinlik odaklı bir mimari inşa etmek istiyorsanız, bu mimari tip için daha fazla işlevsellik sağladığı için Apache Kafka'ya gidin (örneğin Kafka Akarsuları veya ksqlDB).

Biraz geç olduğunu biliyorum ve belki de zaten, dolaylı olarak söylediniz, ama yine, Kafka hiç bir sıra değil, bir günlük (yukarıda birisinin söylediği gibi, anket tabanlı).

Basitleştirmek için, Kafka yerine RabbitMQ'yu (veya herhangi bir kuyruk tekno) tercih etmeniz gereken en belirgin kullanım örneği şudur:

Bir kuyruktan tüketen birden fazla tüketiciniz var ve kuyrukta yeni bir ileti ve kullanılabilir bir tüketici olduğunda, bu iletinin işlenmesini istiyorsunuz. Kafka'nın nasıl çalıştığına yakından bakarsanız, bunun nasıl yapılacağını bilmediğini fark edeceksiniz, bölüm ölçeklendirme nedeniyle, bir bölüme adanmış bir tüketiciniz olacak ve açlık sorununa gireceksiniz. Basit kuyruk tekno kullanarak kolayca kaçınılabilir sorunu. Aynı bölümden farklı iletileri gönderecek bir ileti dizisi kullanmayı düşünebilirsiniz, ancak yine de Kafka'nın seçici bir onay mekanizması yoktur.

Yapabileceğiniz en fazla şey bu adamlar olarak yapmak ve Kafka'yı kuyruk olarak dönüştürmeye çalışmak: https://github.com/softwaremill/kmq

Yannick

Aşağıdaki durumlarda RabbitMQ kullanın:

• Bigdata ile başa çıkmak zorunda değilsiniz ve izleme için kullanışlı bir yerleşik UI'yi tercih edersiniz
• Otomatik olarak kopyalanabilir kuyruklara gerek yok
• Mesajlar için çoklu abone yok - Bir günlük olan Kafka'nın aksine, RabbitMQ bir kuyruktur ve mesajlar tüketildikten ve onaylandıktan sonra kaldırılır
• Mesajlar için joker karakterler ve normal ifade kullanma gereksinimleriniz varsa
• Mesaj önceliğini tanımlamak önemliyse

Kısacası: RabbitMQ, düşük veri trafiğine sahip, öncelik kuyruğu ve esnek yönlendirme seçeneklerinden yararlanan basit kullanım durumları için iyidir. Büyük veri ve yüksek iş hacmi için Kafka'yı kullanın.

Her ikisiyle de deneyimlerime dayanarak objektif bir cevap vereceğim, zaten bildiğinizi ve / veya diğer cevapların yeterince sağladığını varsayarak, onların arkasındaki teoriyi de atlayacağım.

RabbitMQ : Gereksinimlerim kanallar / kuyruklar aracılığıyla sistem iletişimi ile başa çıkmak için yeterince basitse bunu seçerim, tutma ve akış bir gereklilik değildir. Örneğin, üretim sistemi varlığı inşa ettiğinde, sözleşmeleri yapılandırmak için sözleşme sistemini bilgilendirir.

Kafka : Olay kaynağı gereksinimi, genellikle akışlarla (bazen sonsuz) uğraşmanız gerektiğinde, bir kerede düzgün bir şekilde dengelenmiş büyük miktarda veri, belirli bir durumu sağlamak için ofsetleri yeniden oynatır vb. Konular / bölümler / aracılar / kaldırıldı olarak işaretleme mesajları gibi kavramları birinci sınıf bir önem olarak içerdiğinden, bu mimarinin de daha fazla karmaşıklık getirdiğini unutmayın.

Düşünebildiğim tek fayda İşlem özelliği, geri kalan her şey Kafka kullanılarak yapılabilir

Her ikisini de ölçeklendirmek dağıtılmış hataya dayanıklı bir şekilde zordur, ancak RabbitMQ ile büyük ölçekte çok daha zor olduğunu söyleyebilirim. Kürek, Federasyon, Aynalı Msg Kuyrukları, ACK, Mem sorunları, Arıza toleransı vb. Anlamak önemsiz değildir. Bununla birlikte, Kafka ile yapmadığınız RMQ ile bir Polyglot değişimi aldınız. Akış istiyorsanız Kafka'yı kullanın. Basit IoT veya benzeri yüksek hacimli paket teslimatı istiyorsanız Kafka kullanın. Akıllı tüketicilerle ilgili. Msg esnekliği ve daha yüksek maliyetler ve muhtemelen bazı karmaşıklıklarla daha yüksek güvenilirlik istiyorsanız, RMQ kullanın.

Karmaşık yönlendirme gereksinimleriniz varsa ve aracıyı izlemek için yerleşik bir GUI istiyorsanız, RabbitMQ uygulamanız için en iyisi olabilir. Aksi takdirde, yüksek iş hacmini işlemek ve akış geçmişine erişim sağlamak için bir mesaj komisyoncusu arıyorsanız Kafka muhtemelen daha iyi bir seçimdir.

Apache Kafka, veri boru hatlarına güç vermek için popüler bir seçimdir. Apache kafka, popüler etl kullanım örneklerini desteklemek için kafka akışını ekledi. KSQL, boru hattındaki verileri dönüştürmeyi kolaylaştırır ve iletileri başka bir sisteme temiz bir şekilde inmeye hazır hale getirir. KSQL, Apache Kafka için akışlı SQL motorudur. Java veya Python gibi bir programlama dilinde kod yazmaya gerek kalmadan Kafka'da akış işleme için kullanımı kolay ancak güçlü bir etkileşimli SQL arabirimi sağlar. KSQL ölçeklenebilir, elastik, hataya dayanıklı ve gerçek zamanlıdır. Veri filtreleme, dönüşümler, toplamalar, birleştirmeler, pencereleme ve oturumlaştırma da dahil olmak üzere çok çeşitli akış işlemlerini destekler.

https://docs.confluent.io/current/ksql/docs/index.html

Rabbitmq, etl sistemleri için değil, daha az verimi olan basit mesajlaşma sistemleri gerektiren sistemler için popüler bir seçim değildir.

Bunun eski bir soru olduğunu anlıyorum, ancak RabbitMQ'nun daha iyi bir seçim olabileceği bir senaryo, veri redaksiyonu ile uğraşırken.

RabbitMQ ile, varsayılan olarak mesaj tüketildikten sonra silinir. Kafka ile varsayılan olarak mesajlar bir hafta boyunca saklanır. Bunu çok daha uzun bir süreye ayarlamak, hatta asla silmemek yaygındır.

Her iki ürün de iletileri saklayacak (ya da saklayamayacak şekilde) yapılandırılabilse de, CCPA veya GDPR uyumluluğu bir endişe kaynağıysa, RabbitMQ ile devam ediyorum.

Kafka, verim, dayanıklılık, gecikme açısından RabbitMQ'dan daha iyidir. 10k / sn'den daha az işlem bekliyorsanız RabbitMQ için gidebilirsiniz, ancak bu da uygulamanıza bağlıdır.

Kafka'yı 70k / sn'den fazla işlem gerçekleştirdiğimiz ürünümüzde uyguladım ve gecikme süresi ortalama 15 ms idi ve az sayıda artış 40 ms'ye ulaştı. Konu boyutu 100 kb idi.

KAFKA ve RabbitMQ hakkında PFB daha fazla veri noktası: Apache Kafka, aslında en iyi bilinen ve en popüler kısmı olan aracının kendisini içerir ve akış işleme senaryoları için tasarlanmış ve belirgin bir şekilde pazarlanmıştır. Buna ek olarak, Apache Kafka kısa süre önce kendisini Apache Spark, Apache Flink, Apache Beam / Google Cloud Veri Akışı ve Spring Cloud Veri Akışı gibi akış platformlarına alternatif olarak konumlandıran Kafka Streams'i ekledi. Belgeler, Web Sitesi Etkinlik İzleme, Metrikler, Günlük Birleştirme, Akış İşleme, Etkinlik Kaynaklandırma ve İşlem günlükleri gibi popüler kullanım durumlarını tartışmak için iyi bir iş çıkarır. Açıkladığı bu kullanım durumlarından biri, biraz karışıklık yaratabilecek mesajlaşmadır. Öyleyse bunu biraz açalım ve Kafka için hangi mesajlaşma senaryolarının en iyi olduğu konusunda netlik kazanalım:

A'dan B'ye karmaşık yönlendirme olmadan, maksimum verim (100k / sn +) ile en az bir kez bölümlenmiş sırayla aktarılır. Uygulamanızın akış geçmişine erişmesi gerektiğinde, bölümlenmiş sırada en az bir kez yayınlanır. Kafka dayanıklı bir mesaj deposudur ve müşteriler, bir kez mesaj gönderildikten sonra kuyruktan kaldırıldığı daha geleneksel mesaj simgelerinin aksine, olay akışının "tekrarını" alabilirler. Akış İşleme Olayı Kaynak Oluşturma RabbitMQ, kullanıcı sonucu beklerken kaynak yoğun yordamlar uygulamak zorunda kalmak yerine genellikle web sunucularının isteklere hızlı yanıt vermesine izin vermek için kullanılan genel amaçlı bir mesajlaşma çözümüdür. Tüketim için bir mesajı birden fazla alıcıya dağıtmak veya aşırı yük altında çalışanlar (20k + / sn) arasındaki yükleri dengelemek için de iyidir. Gereksinimleriniz verimin ötesine geçtiğinde, RabbitMQ'nun sunabileceği çok şey vardır: güvenilir teslimat, yönlendirme, federasyon, HA, güvenlik, yönetim araçları ve diğer özellikler için özellikler. RabbitMQ için en iyi bazı senaryoları inceleyelim, örneğin:

Uygulamanızın AMQP 0-9-1, STOMP, MQTT, AMQP 1.0 gibi mevcut protokollerin herhangi bir kombinasyonu ile çalışması gerekir. Her mesaj için daha hassas bir tutarlılık kontrolüne / garantisine ihtiyacınız vardır (ölü mektup kuyrukları, vb.) Ancak, Kafka son zamanlarda işlemler için daha iyi destek eklemiştir. Uygulamanızın noktadan noktaya, istekte bulunma / yanıtlama ve yayınlama / abone olma konusunda çeşitli gereksinimlere sahip olması ek yazılım yardımı. RabbitMQ genellikle uygulamanın akış geçmişine erişmesi gerektiğinde Apache Cassandra ile veya “sonsuz” kuyruğa ihtiyaç duyan uygulamalar için LevelDB eklentisi ile kullanılır, ancak hiçbir özellik RabbitMQ'nun kendisiyle birlikte gönderilmez.

Kısa cevap "mesaj alındı" dır. RabbitMQ, mesaj onayı gerektirecek şekilde yapılandırılabilir. Bir alıcı başarısız olursa, mesaj tekrar kuyruğa gider ve başka bir alıcı tekrar deneyebilir. Bunu Kafka'da kendi kodunuzla gerçekleştirebilmenize rağmen, kutusundan çıkarak RabbitMQ ile çalışır.

Deneyimlerime göre, bir bilgi akışını sorgulamak için gereksinimleri olan bir uygulamanız varsa, Kafka ve KSql en iyi seçimdir. Bir kuyruk sistemi istiyorsanız RabbitMQ ile daha iyi durumdasınız.

En çok oy verilen cevap çoğu bölümü kapsıyor, ancak yüksek ışık kullanım durumu bakış açısını istiyorum. Can kafka tavşan mq yapabilir, cevap evet ama tavşan mq kafka yaptığı her şeyi yapabilir, cevap hayır. Tavşan mq'in yapamayacağı şey, kafka'yı parçalara ayıran şey, bu mesaj işleme. Bu ile şimdi en çok oyu alan cevabı tekrar okuyun ve daha mantıklı olacaktır. Ayrıntılı olarak, örneğin facebook'ta "beğeniler" gibi süper yüksek bir verime sahip bir mesajlaşma sistemi oluşturmanız gereken bir kullanım durumu alın ve bunun için tavşan mq'yi seçtiniz. Tüm yayıncıların (bu durumda FB kullanıcıları) 'beğeniler' mesajlarını yayınlayabileceği bir değişim ve kuyruk ve tüketici oluşturdunuz. Veriminiz yüksek olduğundan, iletileri paralel olarak işlemek için tüketicide birden çok iş parçacığı oluşturacaksınız, ancak yine de tüketicinin çalıştığı makinenin donanım kapasitesi ile sınırlısınız. Bir tüketicinin tüm mesajları işlemek için yeterli olmadığını varsayarsak - ne yapardınız? Kuyruğa bir tüketici daha ekleyebilir misiniz - hayır bunu yapamazsınız. Yeni bir kuyruk oluşturabilir ve bu kuyruğu 'beğeniler' mesajını yayınlayacak şekilde değiştirmek için bağlayabilir misiniz? Kafka'nın çözdüğü temel sorun budur. Birbiriyle konuşan dağıtılmış bölümler (Queue in mq in Queue) ve dağıtılmış tüketici oluşturmanıza olanak tanır. Bu, bir konudaki iletilerinizin çeşitli düğümlere (Makineler) dağıtılan tüketicilerin işlemlerini almasını sağlar. Kafka brokerleri, mesajların bu konunun tüm bölümlerinde yük dengelenmesini sağlar. Tüketici grubu, tüm tüketicilerin birbirleriyle konuştuğundan ve mesajın iki kez işlenmediğinden emin olur. Ancak gerçek hayatta, geçme oranı çok yüksek olmadığı sürece bu sorunla karşılaşmazsınız, çünkü tavşan mq bir tüketici ile bile verileri çok hızlı işleyebilir.