MQ teknoloji ürünleri patladı, Tencent'in açık kaynak mesajlaşma ara yazılımı TubeMQ | The Force Project hakkında konuşalım
Yazar | kimmking
Kaynak | CSDN blogu, sorumlu editör | Xi Yan
Üretildi | CSDN (ID: CSDNnews)
Dağıtılmış teknolojinin gelişmesiyle birlikte, MQ teknoloji ürünleri de bir patlama yaşadı. Şu anda, Apache's ActiveMQ, Kafka, Pulsar, RocketMQ (hem Apache hem de Ali, başlıklar aynı zamanda RocketMQ'ya dayanmaktadır) ve RabbitMQ (büyük ölçüde Meituan ve Autohome tarafından kullanılmaktadır) gibi yaygın olarak kullanılan çeşitli MQ'lara ek olarak, tüm büyük üreticiler Kendi ürünlerimi geliştirdim, Tencentin CMQ ve TubeMQu, JDnin JMQu, Qunarın QMQu, Didinin DDMQu (RocketMQya dayalı), çoğu açık kaynak. Bu yıl açık kaynak TubeMQ hakkında konuşmama izin verin.
Tencent'in açık kaynak TubeMQ
Resmi tanıtım aşağıdaki gibidir:
https://github.com/Tencent/TubeMQ/blob/master/docs/tubemq_basic_introduction_cn.md
TubeMQ, 2013 yılında Tencent Big Data tarafından geliştirilen ve büyük veri senaryosu altında büyük verilerin yüksek performanslı depolanmasına ve iletilmesine odaklanan dağıtılmış bir mesajlaşma ara yazılım sistemidir (MQ). Yaklaşık 7 yıl boyunca trilyonlarca dolarlık muazzam veri yağışından sonra, TubeMQ kitle uygulamasında belirli avantajlara (kararlılık + performans) ve birçok açık kaynak MQ bileşenine kıyasla düşük maliyete sahiptir. Son zamanlarda, TubeMQ'nun açık kaynak kodlu ve tasarımıyız. , Daha fazla bilgi düzenleniyor.
TubeMQ küme mimarisi:
Yıllar süren evrimden sonra, TubeMQ kümesi aşağıdaki 5 bölüme ayrılmıştır:
-
Portal: Harici etkileşim ve işletim ve bakım işlemlerinden sorumlu Portal bölümü, API ve Web'i içerir. API, kümenin dışındaki yönetim sistemine bağlanır.Web, API'ye dayalı günlük işlem ve bakım işlevleri için bir sayfa kapsüllemesidir;
-
Usta: Küme kontrolünden sorumlu olan Kontrol bölümü Bu bölüm bir veya daha fazla Ana düğümden oluşur.Master HA, Ana düğümler arasında canlı ve gerçek zamanlı sıcak bekleme geçişi yapılarak tamamlanır. (Bu, TubeMQ'nun Lib'sini kullandığınızda, ilgili kümedeki tüm Ana düğümleri doldurmanız gerekir. Adres nedeni), ana yönetici, tüm kümenin durumunun yönetilmesinden, kaynak planlamasından, izin kontrolünden, meta veri sorgusundan, vb. Sorumludur;
-
Komisyoncu: Gerçek veri depolamadan sorumlu Mağaza bölümü. Bu bölüm bağımsız Broker düğümlerinden oluşur.Her Broker düğümü, Topic'in eklenmesi, silinmesi, değiştirilmesi ve sorgulanması, Topic'te mesaj depolama dahil olmak üzere düğümdeki Konu koleksiyonunu yönetir. Tüketim, eskime, bölüm genişletme, veri tüketiminin ofset kayıtları, vb. Konu sayısı, iş hacmi ve kapasite dahil olmak üzere kümenin harici yetenekleri, yatay olarak genişleyen Broker düğümleriyle tamamlanır;
-
Müşteri: Veri üretimi ve tüketiminden sorumlu Müşteri bölümü. Bu bölümü Lib biçiminde sağlıyoruz. Tüketici tarafı herkes tarafından en çok kullanılan taraftır. Bir öncekiyle karşılaştırıldığında, tüketici tarafı artık Push ve Pull veri çekme modlarını ve veri tüketimi davranışı destek siparişini destekliyor Ve filtreleme tüketimi. Çekme tüketim modeli için, işletmenin bir defaya mahsus tüketimi desteklemek için müşteri aracılığıyla kesin dengelemeyi sıfırlamasına destek olun Aynı zamanda, tüketici tarafı, küme arası geçişi yeniden başlatması gerekmeyen BidConsumer istemcisini yeni başlattı;
-
Hayvan bakıcısı: Ofset depolamanın zk kısmından sorumlu olan fonksiyonun bu kısmı, bir sonraki çok düğümlü kopyalama fonksiyonu dikkate alınarak, sadece ofsetin kalıcı olarak depolanmasını sağlamak için zayıflatılmıştır, bu modül geçici olarak rezerve edilmiştir.
Geleneksel dağıtılmış MQ yapısıyla karşılaştırıldığında, aracı işlevi daha ağırdır.
Kafka ile karşılaştırıldığında, TubeMQ'nun sistem özellikleri:
Saf Java uygulama dili: TubeMQ, geliştiricilerin projeye ve problem işlemeye çabucak aşina olmaları için uygun olan saf Java dilinde geliştirilmiştir;
Ana koordinasyon düğümünü tanıtın: Üst veri yönetimini tamamlamak ve HA garantisini gerçekleştirmek için Zookeeper'a güvenen Kafka ile karşılaştırıldığında, TubeMQ sistemi kendi kendini yöneten bir meta veri tahkim mekanizmasını benimser ve Ana düğüm, gömülü veritabanı BDB'yi kullanarak kümedeki meta verileri tamamlar TubeMQ kümesinin depolama, güncelleme ve HA istekli işlevleri, TubeMQ kümesinin işlem kontrolü ve yapılandırma yönetimi işlemlerinden sorumludur ve harici arayüzler sağlar.Master düğüm aracılığıyla, TubeMQ kümesindeki Broker yapılandırma ayarları, değişiklikler ve sorgular, tam otomatik kapalı döngü yönetimi sağlar ve bu da azalır Sistem bakımının karmaşıklığı;
Sunucu tarafı tüketim yükü dengeleme: TubeMQ, istemci tarafı işlemleri yerine sunucu tarafı yük dengeleme çözümü kullanır; bu, sistemin yönetim ve kontrol yeteneklerini geliştirir ve istemci uygulamasını basitleştirerek dengeleme algoritmasını yükseltmeyi kolaylaştırır;
Sistem satır düzeyinde kilitleme işlemi: Tekrarlama sorunlarını önlemek için Broker mesaj okuma ve yazmada ara durumlarla eşzamanlı işlemler için satır düzeyinde kilidi kullanın;
Ofset yönetimi ayarlaması: Ofset, her Broker tarafından bağımsız olarak yönetilir ve ZK yalnızca kalıcı veri depolaması için kullanılır (ilk başta, ZK bağımlılığını tamamen kaldırdığı düşünülür ve sonraki işlev genişletmesi dikkate alınarak geçici olarak tutulacaktır);
Mesaj okuma mekanizmasının iyileştirilmesi: Kafka'nın sıralı blok okuma ile karşılaştırıldığında TubeMQ rastgele bir mesaj okuma modu kullanır.Aynı zamanda mesaj gecikmesini azaltmak için hafıza önbelleği okuma ve yazma ekler.SSD cihazları olan makineler için mesaj gecikmesini artırın SSD tüketimine geçişin işlenmesi, tüketim ciddi ölçüde geciktiğinde azalan verim, küçük SSD disk kapasitesi ve sınırlı yanıp sönme süreleri sorunlarını çözer, böylece hızlı iş üretimi ve tüketiminin ihtiyaçlarını karşılayabilir (aşağıdaki bölümlerde ayrıntılı olarak açıklanmıştır);
Tüketici davranışı kontrolü: Sistem yükü yüksek olduğunda belirli hizmetler için mevcut sınırlama, tüketimi askıya alma ve veri çekme sıklığını dinamik olarak ayarlama vb. Dahil olmak üzere stratejiler aracılığıyla sistem tarafından erişilen tüketici davranışlarının gerçek zamanlı ve dinamik kontrolünü destekler;
Hizmet hiyerarşik yönetimi ve kontrolü: Sistem çalıştırma ve bakımı, iş özellikleri ve makine yük durumunun farklı ihtiyaçlarına yanıt olarak, sistem, yetkilendirilmiş tüketim, tüketim gecikme sınıflandırma garantisi ve tüketim akımı limiti gibi stratejiler aracılığıyla farklı tüketicilerin tüketim davranışlarını dinamik olarak kontrol etmek için çalıştırma ve bakımı destekler. Kontrol ve veri çekme frekansı kontrolü, vb .;
Sistem güvenliği yönetimi ve kontrolü: İşletmenin farklı veri hizmeti ihtiyaçlarına ve sistem işletim ve bakım güvenliğinin dikkate alınmasına göre TubeMQ sistemi, bir TLS taşıma katmanı şifreleme hattı, üretim ve tüketim hizmetlerinin kimlik doğrulaması ve yetkilendirmesi ve dağıtılmış erişim kontrolü için erişim belirteci yönetimi ekler , Sistem güvenliği açısından iş ve sistem işletme ve bakım ihtiyaçlarını karşılamak;
İyileştirilmiş kaynak kullanımı: Kafka ile karşılaştırıldığında TubeMQ, bağlantı kaynağı tüketimini azaltmak için bir bağlantı çoğullama modunu benimser; mantıksal bir bölüm yapısı aracılığıyla, sistemin dosya tutamaçlarını işgalini azaltır ve sunucu tarafı filtreleme modu, ağ bant genişliği kaynak kullanımını azaltır; Zookeeper kullanımını ortadan kaldırarak, Zookeeper'in güçlü bağımlılığını ve darboğaz kısıtlamalarını azaltın;
İstemci iyileştirme: İş kullanımının rahatlığına dayalı olarak, en küçük işlev setini elde etmek için istemci mantığını basitleştirdik Kötü Broker düğümlerini otomatik olarak kaldırmak için yanıt mesajlarına dayalı alım kalitesi istatistikleri algoritmasını kullanıyoruz. Kullanırken, büyük miktarlarda veri gönderirken engellemekten kaçınmak için bağlantı girişiminde bulunun (ayrıntılar için aşağıdaki bölümlere bakın).
Bu bölüm temel olarak diğer MQ'nun özelliklerini ve bazı özelliklerini açıklar. Aslında Kafka ile karşılaştırıldığını tahmin edebilirsiniz. Birçok yer Kafka'ya katıldı ve onu geliştirdi ve yönetim yeteneklerinde birçok düşünce ve yeni fikir üretti. Gerçekleşme.
TubeMQ istemcisinin evrimi:
TubeMQ ile en fazla teması olan işletme tüketici tarafındadır. İş özelliklerine nasıl daha iyi adapte olunur ve iş kullanımı için daha uygun hale nasıl getirilir? Bu alanda daha fazla iyileştirme yaptık:
Veri çekme modu, Push ve Pull'u destekler:
-
Push client: TubeMQ'nun ilk tüketici versiyonu sadece Push modunda tüketim sağlar.Bu mod, verileri nispeten hızlı tüketebilir ve sunucu üzerindeki baskıyı azaltabilir, ancak aynı zamanda bir sorun da beraberinde getirir.İşletme kullanıldığında çekme sıklığı kontrol edilmez. Bu nedenle, işlenemeyen bir veri biriktirme listesi oluşturmak kolaydır;
-
Tüketim askıya alma / sürdürme ile istemciyi itin: İtme çekme eyleminin kontrol edilmesinin gerekip gerekmediğine ilişkin iş geri bildirimi aldıktan sonra, işletmenin su seviyesi kontrol mekanizmasını simüle edebilmesi ve durum meşgul olduğunda duraklatConsume çağrısı yapabilmesi için resumeConsume / pauseConsume işlev çiftini ekledik Durum geri yüklendikten sonra Lib arka planının veri çekmesini durdurma işlevi, verileri çekmeye devam etmek için Lib arka planını bilgilendirmek için resumeConsume öğesini çağırın;
-
Çekme istemcisi: Push istemcisinden farklı olan Pull istemcisini sonraki sürümde ekledik.İletileri aktif olarak çeken ve veri işleme sonuçlarının başarısını onaylayan Lib'den ziyade iştir. Veri işleme girişimi işletmeye bırakılmıştır. Bu işlemden sonra, sunucu tarafındaki baskı artmış olsa da, iş tüketiminin birikmiş yükü büyük ölçüde hafifletilebilir.
-
Veri tüketimi davranışı sipariş ve filtrelenmiş tüketimi destekler: TubeMQ tasarımının başlangıcında, farklı işletmelerin farklı konular kullandığını düşündük.Gerçek operasyonlarda, birçok işletmenin verileri proxy modu aracılığıyla gerçekten raporladığını ve verinin konu altındaki dosya kimliğini veya tabloyu geçtiğini gördük. Kimlik öznitelikleri ayırt edilir.Bir veri parçasını tüketmek için, bir işletmenin konu altındaki tüm verileri tam olarak tüketmesi gerekir. Tid alanını, belirtilen özniteliklerin filtreleme tüketim modunu desteklemek için kullanırız ve istemcinin çıkışını ve veri işleme baskısını azaltmak için veri filtrelemesini sunucuya yerleştiririz.
-
İşin bir kez ayıklanarak tüketimini destekleyin: Verileri işlerken doğru geri alma ihtiyacını çözmek için, istemci sürümü, istemci aracılığıyla kesin ofseti sıfırlama işlevini sağlar.İşletme sistemi yeniden başlattığında, yalnızca müşterinin bekleyen geri aramayı sağlaması gerekir Zaman noktasının tüketim bağlamında, TubeMQ belirtilen kesin konuma göre tüketime devam edebilir. Bu özellik şu anda Flink gibi gerçek zamanlı hesaplama çerçevelerinde kullanılıyor ve kontrol noktası mekanizmasına dayalı bir kez ayıklanan veri işleme için Flink'e güveniyor.
İt ve çek Bunlar, mesaj işlemenin en temel iki modudur. İtme, sunucu işlemi için daha basittir.İtme işlemi yapmanız fark etmez, aracı daha hafif hale gelir, ancak birim zamanda çok fazla itme olabilir, bu da tüketici tarafında bir birikime neden olur ve istemci sistemi bunaltıcıdır. Çekme, herhangi bir zamanda veri almaya geldiğinizde, komisyoncunun durumu sürdürmesi ve bir biriktirme listesi oluşturması ve ayrıca yeniden deneme stratejileriyle uğraşması gerektiği anlamına gelir. Bir ofsetin olması, mesajın herhangi bir zamanda geri izlenebileceği anlamına gelir, ancak bu tekrarlamaya neden olabilir.Dahili tekilleştirme yoksa, bir kez çıkarılmaz, en az bir kez çıkar ve mesaj tekrarlanır.
Diğer birkaç mq
Didi'nin DDMQ'su:
https://github.com/didi/DDMQ/blob/master/README_CN.md
Qunar QMQ:
https://github.com/qunarcorp/qmq
Birkaç ilginç nokta
TubeMQ ile kafka, rocketmq ve pulsar gibi ana akım MQ mimarileri arasındaki fark nedir?
Resmi görüş:
Kafka, sıralı yazma + sıralı blok okuma modunda uygulanır.Tek bir örnek altındaki performans verileri çok güçlüdür, ancak örnek sayısı arttıkça performansı kararsız bir düşüş gösterecektir; TubeMQ maksimumda bile sıralı yazma + rastgele okuma modunu benimser Kısıtlama altında, sistem 1G'nin üzerinde uzun vadeli istikrarlı girişler elde edebilir ve aynı zamanda sunucu tarafı filtreleme ve filtreleme tüketimi ile birlikte çok düzgündür.
Şahsen ben bu konuda çekincelerim var. Çok sayıda konu oluşturmak Kafka'nın tasarım ilkelerine uygun değildir (genellikle tek bir kümedeki konu sayısının 100 dahilinde olmasını tavsiye ederiz. Çok fazla küçük konu rastgele okuma ve yazmalara neden olur, ancak bunlar birleştirilebilir ve ardından mesajları farklılaştırabilir ve yönlendirebilir. Aynı zamanda, bir SSD diskine geçerseniz, verimi ve gecikmeyi de artırabilirsiniz.Binlerce konu büyük bir sorun değildir. Üstelik Kafka'nın gecikme süresi yukarıdaki belgede bahsettiğimiz 250ms gibi değil, aslında 10-40ms arasında kullanıyoruz.
TubeMQ bir göz attı: Genel tasarım, pulsar'a biraz benziyor, çünkü esas olarak aracı ve depolama ayrılmış; mesaj işleme modu, ActiveMQ'ya biraz yakın.
Birkaç ilginç yer:
1. TubeMQ birden fazla kopyayı desteklemez. Böyle tek bir telefon aşırı durumlarda yine de veri kaybedebilir. Ancak, birden fazla kopya, çeşitli dağıtılmış mesaj kuyruklarının standart yapılandırmasıdır (Tencent Cloud'da CMQ'nun ticari sürümüne bakın. .)
2. Sunucu tarafı tüketim yük dengesi, Kafka'nın önceki sürümü şöyle, birçok sorun var
3. Mesajlar rastgele okunur.Bu, bellek önbelleğe alma ve SSD'ye bağımlılık gerektirir ki bu çok gariptir. Eşzamanlılık için kilitler eklenir. Bu çok karmaşıktır. ActiveMQ, belleğin işlenmesinin çok karmaşık olması, bu da büyük bir miktara yol açması ve hiç kimsenin onu iyi kullanamamasıdır.
4. Aynı anda hem itme hem de çekmeyi destekleyin.Bu da çok ilginç.Birinciyle ilgisi var.İtmeyi destekliyorsa, sunucunun bir durumu olması gerekir.
5. Sunucu tarafında mesaj filtrelemeyi destekleyin Şimdi genel MQ istemci tarafında filtreleme yapıyor ve aynı şey de geçerli.
MQ, ActiveMQ, Kafka / RocketMQ ve Pulsar tarafından temsil edilen şimdiye kadar üç nesil deneyimledi. Trend bakış açısına göre, gittikçe daha fazla dağıtılmış ve bulut yerel için destek giderek daha fazla vatansız hale geliyor ve giderek daha fazla aracı kurum Çürük.
Kısacası, bu şema geleneksel ve mevcut MQ'nun bazı özelliklerinin bir sentezi gibi görünüyor, ancak gerçekleştirilmesi çok ağır.
Ayrıca bir ipucu var, TubeMQ'daki bileşen isimleri biraz dağınık, master denen şey aslında komisyoncu ve broker denen şey aslında depolamadır (pulsarda bahisçi).
:)
Orijinal bağlantı:
https://blog.csdn.net/KimmKing/article/details/103133789
Bugünün faydaları
Lu Qi ile tanışın
Ayrıca "Milyonlarca Kişi Yapay Zekayı Öğreniyor" un önemli bir parçası olarak, 2020 AIProCon Geliştiriciler Konferansı 3 - 4 Temmuz tarihleri arasında çevrimiçi olarak canlı yayınlanacak ve geliştiricilerin mevcut yapay zeka en son teknolojisini tek noktadan öğrenmelerine olanak tanıyacak Araştırma, temel teknoloji ve uygulamalar ile kurumsal vakalarda pratik deneyim ve ayrıca heyecan verici ve çeşitli geliştirici salonlarına ve programlama projelerine çevrimiçi olarak katılabilirsiniz. Bir dizi ileriye dönük aktiviteye ve çevrimiçi canlı yayın etkileşimlerine katılın. Yalnızca on binlerce geliştiriciyle iletişim kurmakla kalmaz, aynı zamanda özel canlı yayın hediyeleri kazanma ve teknik uzmanlarla bağlantı kurma fırsatına da sahip olursunuz.
Tek noktadan katil yapay zeka geliştirme platformu burada! Parçalı modelleme araçlarını değiştirmeye elveda deyin
Pekin'deki Dördüncü Çevre Yolu'nda trafik sıkışıklığının tetiklediği büyük akıllı ulaşım fikri
Lütfen bana yığının ne olduğunu sorma!
Pekin'deki Dördüncü Çevre Yolu'nda trafik sıkışıklığının tetiklediği büyük akıllı ulaşım fikri
Şirketinizin sanal makinesi hala boşta mı? Jenkins ve Kubernetes'e dayalı sürekli entegrasyon testi uygulamasına bir göz atın!
Web1.0'dan Web3.0'a: İnternetin son yıllarda gelişimi ve gelecekteki yönünün ayrıntılı analizi
