Bu makale öncelikle, mesaj aracı yazılımının genellikle çözmesi gereken sorunlara, bu sorunların çözümünde karşılaşılan zorluklara, Apache RocketMQ'nun Alibaba tarafından yüksek performanslı, yüksek verimli dağıtık mesaj aracı açık kaynak olarak çözülüp çözülemeyeceğine ve bu sorunların spesifikasyonda nasıl tanımlandığına yol açmaktadır. Bu makale, okuyuculara RocketMQ hakkında hızlı bir anlayış sağlamak için RocketMQ'nun mimari tasarımını tanıtacaktır.
1. Mesaj ara yazılımının çözmesi gereken hangi sorunlar var? Yayınlama/Abone Ol, mesaj ara yazılımının en temel işlevidir ve aynı zamanda geleneksel RPC iletişimiyle de ilişkilidir. Burada detaylara girmeyeceğim.
Mesaj Önceliği spesifikasyonunda tanımlanan öncelik, bir mesaj kuyruğuna atıfta bulunur; her mesajın farklı bir önceliği vardır ve genellikle tam sayılarla tanımlanır, yüksek öncelikli mesaj önce teslim edilir; eğer mesaj tamamen bellek kuyruğundaysa, teslimattan öncesi önceliğe göre sıralanabilir, böylece yüksek öncelikli önce teslim edilir.
RocketMQ'daki tüm mesajlar kalıcı olduğundan, önceliğe göre sıralanırlarsa ek yük çok büyük olur; bu nedenle RocketMQ mesaj önceliğini özel olarak desteklemez, ancak benzer işlevleri geçici çözümlerde uygulayabilir; yani yüksek öncelikli bir kuyruk ve normal öncelikli bir kuyruk yapılandırabilir ve farklı öncelikleri farklı kuyruklara gönderebilir.
Öncelikli konular için 2 kategoriye özetlenebilir:
- Öncelik sağlandığı sürece, bu kesinlikle öncelik değildir ve öncelik genellikle yüksek, orta, düşük veya birkaç daha fazla seviyeye ayrılır. Her öncelik farklı bir konu ile temsil edilebilir ve bir mesaj gönderirken, önceliği temsil etmek için farklı konular belirler; bu da öncelikli sorunların çoğunu çözebilir ancak iş önceliklerinin doğruluğunu tehlikeye atar.
- Kesin öncelik, öncelik tam sayı olarak ifade edilir, örneğin 0 ~ 65535, bu tür öncelik problemleri genellikle farklı konularla çözülmeye uygun değildir. MQ'nun bu sorunu çözmesini istiyorsanız, bu MQ'nun performansı üzerinde çok büyük bir etkiye sahip olacaktır. İşin gerçekten bu katı önceliklendirmeye ihtiyacı olduğundan emin olmak için bir nokta var ve öncelikler birkaç önceliğe sıkıştırılırsa, bu iş üzerinde ne kadar etkisi olur?
Mesaj Sırası, gönderildiği sırayla tüketilebilen bir mesaj türü anlamına gelir. Örneğin, bir emir 3 mesaj oluşturur: emir oluşturma, sipariş ödemesi ve sipariş tamamlanması. Tüketirken, bu sırayla tüketmek anlamlıdır. Ama aynı zamanda, siparişler paralel olarak tüketilebilir.
RocketMQ, mesajların düzenli olmasını kesin şekilde garanti edebilir.
Mesaj FiltresiBroker Mesaj Filtreleme
Broker'da, tüketicinin gereksinimlerine göre filtreleme, gereksiz mesajların tüketiciye iletilmesini azaltma avantajına sahiptir.
Dezavantajı, aracı kurumun üzerindeki yükü artırması ve uygulanmasının nispeten karmaşık olmasıdır.
1. Taobao Notify çeşitli filtreleme yöntemlerini destekler; bunlar arasında mesaj türüne göre doğrudan filtreleme ve esnek sözdizimi ifadesi filtreleme gibi neredeyse en zorlu filtreleme ihtiyaçlarını karşılayabilir.
2. Taobao RocketMQ, basit Mesaj Etiketi ile Mesaj Başlığı ve gövde ile filtrelemeyi destekler.
3. Esnek sözdizimi ifade filtreleme de CORBA Bildirim spesifikasyonunda desteklenmektedir.
Tüketici tarafı mesaj filtreleme
Bu filtreleme uygulama tarafından tamamen özelleştirilebilir, ancak dezavantajı ise çok sayıda gereksiz mesajın tüketiciye gönderilmesidir.
Mesaj kalıcılığı için kullanılan birkaç yaygın süreklilik yöntemi vardır:
- Mysql gibi bir veritabanında devam edin.
- LevelDB, Berkeley DB ve diğer KV depolama sistemleri gibi KV depolamaya devam edin.
- Kafka, RocketMQ gibi dosya kayıtları şeklinde ısrarlılık
- Beanstalk, VisiNotify gibi kalıcı bir hafıza verisi görüntüsü oluşturun
- (1), (2) ve (3) üç süreklilik yöntemi de bellek kuyruk tamponunu uzatma yeteneğine sahiptir ve (4) sadece bir bellek görüntüsüdür; aracı telefonu kapatıp yeniden başlattıktan sonra da önceki bellekten verileri geri getirebilen bir bellek görüntüsüdür.
JMS ve CORBA Bildirim spesifikasyonları nasıl devam edeceğini açıkça belirtmez, ancak süreklilik kısmının performansı doğrudan tüm mesaj ara yazılımının performansını belirler.
RocketMQ, performansı artırmak için Linux dosya sistemi bellek önbelleğini tam olarak kullanır.
Mesaj güvenilirliğinin mesaj güvenilirliğini etkilediği birkaç durum vardır:
- Broker normal şekilde kapanır
- Broker çöküşü
- Işletim sistemi çökmesi
- Makine güç kaybeder, ancak güç kaynağı hemen geri kazanılabilir.
- Makine açılmıyor (CPU, anakart, bellek gibi önemli cihazlara zarar görebilir).
- Disk cihazı hasarı.
(1), (2), (3) ve (4) donanım kaynaklarının hemen geri alınabildiği durumlardır ve RocketMQ, mesajların kaybedilmemesini veya az miktarda verinin kaybolmasını sağlayabilir (flashing yönteminin senkron veya asenkron olmasına bağlı olarak).
(5) (6) Tek bir arıza noktasıdır ve geri kazanılamaz; bir kez gerçekleştiğinde, bu tek noktadaki tüm mesajlar kaybolur. Her iki durumda da RocketMQ, mesajların %99'unun asenkron çoğaltma yoluyla kaybedilmemesini sağlar, ancak yine de çok az mesaj kaybolabilir. Senkron çift yazma teknolojisi, tek noktalardan tamamen kaçınabilir; bu da kaçınılmaz olarak performansı etkiler; bu da Parayla ilgili uygulamalar gibi son derece yüksek mesaj güvenilirliği gereksinimleri olan durumlar için uygun hale getirir.
RocketMQ, 3.0 sürümünden itibaren senkron çift yazmayı destekler.
Düşük gecikmeli mesajlaşma, mesaj aracı kuruma ulaştıktan hemen sonra kullanıcıya ulaşabilir ve mesaj birikmeden gerçekleşir.
RocketMQ, mesajın çok gerçek zamanlı olmasını sağlamak için uzun bir anket çekme yöntemi kullanır ve gerçek zamanlı mesajın push'tan daha düşük olmadığını garanti eder.
En az bir kez her mesajın bir kez teslim edilmesi gerektiği anlamına gelir.
RocketMQ Tüketici önce mesajı yerel alana çeker ve tüketim tamamlandıktan sonra ack'i sunucuya geri gönderir.
Tam olarak sadece bir kez- Mesaj gönderme aşaması tekrarlanan mesajların gönderilmesine izin vermez.
- Mesajı Tüket aşamasında, tekrarlanan mesajların tüketilmesine izin verilmez.
Ancak yukarıdaki iki koşul karşılandığında mesaj "Tam olarak Sadece Bir Kez" olarak kabul edilebilir ve yukarıdaki iki noktaya ulaşmak için dağıtık sistem ortamında kaçınılmaz olarak büyük bir yük oluşur. Bu nedenle, yüksek performans elde etmek için RocketMQ bu özelliği garanti etmez ve işte deduplication gerektirir; bu da tüketici mesajlarının aynı güçlü olması gerektiği anlamına gelir. RocketMQ çoğaltma garantisi veremese de, normal koşullarda nadiren tekrar gönderme ve tüketim olur; sadece ağ anormallikleri, tüketici başlatma ve durdurma ile mesaj çoğaltma gibi diğer anormal durumlar olur.
Bu sorunun temel nedeni, ağ çağrılarında belirsizlik olmasıdır; yani ne başarı ne de başarısızlık olan üçüncü durum, dolayısıyla mesaj tekrarı sorunu ortaya çıkar.
Broker's Buffer doluysa ne yapmalıyım? Aracının tamponu genellikle aracıdaki bir kuyruğun bellek tamponu boyutunu ifade eder ve bu genellikle sınırlıdır, ya tampon doluysa?
CORBA Bildirim spesifikasyonunda böyle işleniyor:
- RejectNewEvents yeni mesajı reddeder ve RejectNewEvents hata kodunu Üreticiye döndürür.
- Mevcut mesajları belirli bir politikaya göre atın
- AnyOrder - Herhangi bir olay taşma durumunda ellenebilir. Bu özellik için varsayılan ayar budur.
- FifoOrder - İlk alınan etkinlik, ilk atılan olur.
- LifoOrder - Alınan son etkinlik ilk atılan olur.
- PriorityOrder - Olaylar, öncelik sırasına göre atılmalıdır, böylece daha düşük öncelikli olaylar daha yüksek öncelikli olaylardan önce atılacaktır.
- DeadlineOrder - Etkinlikler, önce en kısa son kullanma tarihi sırasıyla atılmalıdır.
RocketMQ'nun bellek tamponu kavramı yoktur ve RocketMQ'nun kuyrukları kalıcı disklerdir ve veri düzenli olarak temizlenir.
Bu sorunun çözümü için, RocketMQ diğer MQ'lardan çok önemli bir farka sahiptir, RocketMQ'nun bellek tamponu sonsuz uzunlukta bir kuyruk içinde soyutlanmıştır, ne kadar veri gelirse girsin kurulabilir, bu sonsuzluk öngörülür, aracı düzenli olarak süresi dolmuş verileri siler, örneğin aracı sadece 3 günlük mesajları kaydeder, bu zaman bu tamponun süresi sonsuz olsa da, 3 gün önceki veriler kuyruğun sonunda silinir.
Geriye dönük tüketim, tüketicinin başarıyla tükettiği mesajı ifade eder ve bu mesajın iş talebi nedeniyle yeniden tüketilmesi gerekir. Örneğin, tüketici sisteminin arızası nedeniyle, 1 saat önceki veriler kurtarıldıktan sonra tekrar tüketilmelidir, ardından broker zaman boyutuna göre tüketim ilerlemesini geri almak için bir mekanizma sağlamalıdır.
RocketMQ, zamana dayalı geriye dönük tüketimi destekler; milisaniyelere doğru bir zaman boyutu vardır ve bu boyut ileri veya geri geri kaydedilebilir.
Mesaj yığma mesaj ara yazılımının ana işlevi asenkron decoupling'dir ve bir diğer önemli işlev ise ön uçun veri sel zirvesini engellemek ve arka uç sisteminin istikrarını sağlamaktır; bu da mesaj aracının belirli bir mesaj yığma yeteneğine sahip olmasını gerektirir ve mesaj yığını aşağıdaki iki durumu entegre eder:
- Mesajlar bellek tamponlarında üst üste yığılır ve bellek tamponunu aştıklarında, CORBA Bildirim spesifikasyonunda tanımlandığı gibi belirli bir bırakma politikasına göre mesajlar bırakılabilir. Mesajların atılmasına tolere edebilen hizmetler için uygundur; bu durumda mesajların birikme kapasitesi esas olarak bellek tamponunun boyutunda olur ve mesaj yığıldıktan sonra performans düşüşü çok büyük olmaz, çünkü hafızadaki veri miktarı dış dünyaya erişim yeteneği üzerinde sınırlı bir etkiye sahiptir.
- Mesajlar, DB, KV depolama, dosya kayıt formu gibi kalıcı depolama sistemlerinde biriktirilir. Mesajlar bellek önbelleğine ulaşılamadığında, diske erişmek kaçınılmazdır; bu da büyük miktarda okuma IO'su üretir ve okuma IO'nun veri verimliliği, mesajlar biriktikten sonra onlara erişim yeteneğini doğrudan belirler.
Mesaj birikimini değerlendirmek için dört ana nokta vardır:
- Kaç mesaj birikebilir, kaç bayt? Yani, mesajın yığın kapasitesi.
- Bir mesaj biriktirildikten sonra, mesajın veri taşıma hızı yığma tarafından etkilenir mi?
- Mesajlar biriktikten sonra tüketicilerin normal tüketimi etkilenecek mi?
- Mesajlar üst üste yığıldıktan sonra, diskte birikmiş mesajlara erişildiğinde veri taşımacılığı nedir?
Dağıtık İşlemler XA, JTA gibi bilinen dağıtık işlem spesifikasyonlarından bazıları. Bunlar arasında, XA spesifikasyonu Oracle, Mysql gibi büyük veritabanı satıcıları tarafından yaygın şekilde desteklenmektedir. Bunlar arasında, XA'nın TM uygulama lideri olan Oracle Tuxedo, finans, telekomünikasyon ve diğer alanlarda yaygın olarak kullanılmaktadır.
Dağıtık işlemler iki aşamalı commit sorunları içerir ve veri depolama açısından KV depolama desteklenmelidir; çünkü commit geri dönüşünün ikinci aşaması mesaj durumunu değiştirmek zorundadır; bu durum anahtara göre mesajı bulma eylemini içermelidir. RocketMQ, ikinci aşamada anahtara göre mesajı bulma sorununu atlar; birinci aşamayı kullanarak hazırlanan mesajı gönderir, mesajın ofsetini alır ve ikinci aşamayı ofset üzerinden mesaja erişip durumu değiştirir; ofset verinin adresidir.
RocketMQ'nun işlem uygulama yöntemi KV depolama üzerinden değil, ofset yöntemiyle yapılır; bunun önemli bir kusuru vardır; yani veri ofset üzerinden değiştirildiğinde sistemde çok fazla kirli sayfa oluşur ve bu da özel dikkat gerektirir.
Zamanlanmış mesajlar Planlı mesajlar, mesajların tüketiciler tarafından broker'a gönderildikten hemen sonra tüketilemeyeceği anlamına gelir ve yalnızca belirli bir zaman noktasında veya belirli bir süre beklendikten sonra tüketilebilir.
Eğer rastgele zaman doğruluğunu desteklemek istiyorsanız, aracı seviyesinde mesaj sıralaması yapmalısınız ve eğer süreklilik varsa, mesaj sıralaması kaçınılmaz olarak büyük performans yükü getirecektir.
RocketMQ zamanlama mesajlarını destekler, ancak rastgele zaman doğruluğunu desteklemez ve 5s, 10s, 1m gibi belirli seviyeleri destekler.
Mesajı Yeniden Deneme Tüketici mesajı tüketemediğinde, mesajın tekrar tüketmesini sağlamak için bir yeniden deneme mekanizması sağlanın. Tüketici tüketim mesajı hataları genellikle aşağıdaki durumlarda değerlendirilebilir:
- Mesajın kendisinin nedeni olan seri diziden çıkarma başarısızlığı nedeniyle, mesaj verileri işlenemez (örneğin telefon faturası şarjı, mevcut mesajın cep telefonu numarası çıkış yapılmış, şarj edilemez) vb. Bu hata genellikle bu mesajın atlanmasını ve diğer mesajların tüketilmesini gerektirir ve bu başarısız mesaj, tüketim hemen tekrar denense bile %99 başarısız olur, bu yüzden zamanlamalı bir yeniden deneme mekanizması sağlamak en iyisidir; yani 10 saniye sonra tekrar deneme.
- Bağımlı aşağı akım uygulama hizmetleri mevcut olmadığı için, örneğin veritabanı bağlantısı mevcut olmadığı için, harici sistem ağı da erişilemez vb. Bu hata karşılaşıldığında, mevcut başarısız mesaj atlansa bile, diğer mesajlar da tüketilir. Bu durumda, uyku 30'ları uygulanıp bir sonraki mesajı tüketmeniz önerilir; bu da aracı kurumun mesajı tekrar deneme baskısını azaltabilir.
RocketMQ Genel BakışıRocketMQ'nun yukarıda bahsedilen mesaj ara yazılımının karşılaştığı sorunları çözüp çözmediğini öğrenelim.
RocketMQ nedir?
Yukarıdaki şekil, mesaj gönderme ve alma aracı yazılımının tipik bir modelidir; RocketMQ da bu şekilde tasarlanmıştır; kısacası, RocketMQ aşağıdaki özelliklere sahiptir:
- Yüksek performans, yüksek güvenilirlik, yüksek gerçek zamanlı ve dağıtık özelliklere sahip bir kuyruk modeli mesajı ara yazılımıdır.
- Üretici, Tüketici ve Kuyruk tüm bölümler dağıtılabilir.
- Üretici sırayla bazı kuyruklara mesaj gönderir, kuyruk koleksiyonu Konu, Tüketici Eğer yayın tüketimi ise bir tüketici örneği bu konuya karşılık gelen tüm kuyrukları tüketir ve küme tüketimi durumunda, birden fazla tüketici örneği bu konuya karşılık gelen kuyruk koleksiyonunu eşit şekilde tüketir.
- Sıkı mesaj sırası garanti edilebilir
- Zengin mesaj çekme modları sağlar
- Verimli yatay abone ölçeklendirme yetenekleri
- Gerçek zamanlı mesaj abonelik mekanizması
- Yüz milyonlarca mesaj biriktirme kapasitesi
- Daha Az bağımlılık
RocketMQ fiziksel açılış yapısı
Yukarıdaki şekilde gösterildiği gibi, RocketMQ'nun dağıtım yapısı aşağıdaki özelliklere sahiptir:
- Name Server, düğümler arasında herhangi bir bilgi senkronizasyonu olmadan kümelerde konuşlandırılabilen neredeyse durumsuz bir düğümdür.
- Broker'ın dağıtımı nispeten karmaşıktır, Broker Usta ve Köle'ye ayrılır, bir Usta birden fazla Köle'ye karşılık gelebilir, ancak Köle yalnızca bir Usta ile eşleşebilir, Usta ile Köle arasındaki uyum aynı BrokerName, farklı BrokerId belirtilerek tanımlanır, BrokerId Usta için 0 ve 0 olmayan Köle anlamına gelir. Masterlar ayrıca birden fazla şekilde de kullanılabilir. Her aracı kurum, İsim Sunucusu kümesindeki tüm düğümlerle uzun bir bağlantı kurar ve konu bilgilerini düzenli aralıklarla tüm Isim Sunucularına kaydeder.
- Üretici, İsim Sunucusu kümesindeki düğümlerden biriyle (rastgele seçilmiş) uzun bir bağlantı kurar, periyodik olarak Isim Sunucusundan konu yönlendirme bilgisi alır, konu hizmetini sağlayan ana ana bağlantı ile uzun bir bağlantı kurar ve düzenli aralıklarla ana ana bilgisayara kalp atışları gönderir. Üretici tamamen durumsuzdur ve kümeler halinde dağıtılabilir.
- Tüketici, İsim Sunucusu kümesindeki düğümlerden biriyle (rastgele seçilmiş) uzun bir bağlantı kurar, düzenli olarak Isim Sunucusu'ndan konu yönlendirme bilgilerini alır ve konu servisini sağlayan Usta ve Köle'ye uzun bir bağlantı kurar ve düzenli aralıklarla Usta ve Köle'ye kalp atışları gönderir. Tüketiciler hem Master hem de Slave'den gelen mesajlara abone olabilir ve abonelik kuralları Broker yapılandırmasına göre belirlenir.
RocketMQ mantıksal açılış yapısı
Yukarıdaki şekilde gösterildiği gibi, RocketMQ'nun mantıksal dağıtım yapısı iki özelliğe sahiptir: Üretici ve Tüketici.
Bir mesajlaşma uygulamasını temsil etmek için kullanılan Üretici Grubu, birden fazla Üretici örneği içerir; bunlar birden fazla makine, bir makinenin birden fazla süreci veya bir sürecin birden fazla Üretici nesnesi olabilir. Bir Üretici Grubu birden fazla Konu mesajı gönderebilir ve Üretici Grubu aşağıdaki şekilde çalışır:
- Bir Üretici Türünü Belirleyin
- Bu mesajlaşma uygulamasında birden fazla Üretici örneği olup olmadığını O&M aracı aracılığıyla sorgulayabilirsiniz
- Dağıtık işlem mesajı gönderilirken, üretici beklenmedik şekilde çökerse, aracı işlem durumunu doğrulamak için üretici grubundaki herhangi bir makineyi aktif olarak geri arar ve işlem durumunu doğrular.
Bir tüketici mesajlaşma uygulamasını temsil etmek için kullanılan bir tüketici grubu, birden fazla makine, birden fazla süreç veya bir sürecin birden fazla tüketici nesnesi olabilecek birden fazla tüketici örneğini içerir. Bir Tüketici Grubundaki birden fazla Tüketici mesajları eşit dağıtılmış şekilde tüketir ve yayın olarak ayarlanırsa, bu Tüketici Grubu altındaki her durum tüm veri miktarını tüketir.
RocketMQ veri depolama yapısı
Yukarıdaki şekilde gösterildiği gibi, RocketMQ verileri indekslerden ayıran bir depolama yöntemi benimsemektedir. Dosya kaynaklarının, SİJ kaynaklarının ve bellek kaynaklarının kaybını etkili bir şekilde azaltır. Alibaba gibi büyük verilerle bile, yüksek eşzamanlılık senaryoları uçtan uca gecikmeyi etkili bir şekilde azaltabilir ve güçlü yatay ölçeklendirme yeteneklerine sahip olabilir.
|
Yayınlandı 28.07.2017 20:26:52
|
|
|
|
Yayınlandı 29.07.2017 08:09:37