MQTT broker vs mesaj kuyruğu, birçok ekibin kafasını karıştıran bir ayrımdır, çünkü ikisi de üreticiler ile tüketiciler arasında duran birer "message broker"dır. Fark teslim semantiğindedir: Bir MQTT broker her mesajı o anda ilgilenen her subscriber'a kopyalar; bir mesaj kuyruğu ise her mesajı, tam olarak bir tüketici onun sorumluluğunu üstlenene kadar tutar. Bu rehber her iki modeli açıklıyor, bunları RabbitMQ ve SQS tarzı kuyruklarla karşılaştırıyor ve bir bulut MQTT broker'ın ne zaman doğru yapı taşı olduğunu gösteriyor.
İki Teslim Modeli
Topic tabanlı publish/subscribe (MQTT). Bir publisher, plant1/line2/press4/temperature gibi bir topic'e mesaj gönderir. Broker mevcut tüm subscription'lara bakar, filtresi eşleşenleri bulur ve her birine bir kopya iletir. Beş servis subscribe olmuşsa beş kopya gönderilir. Hiç kimse subscribe olmamışsa mesaj, topic'in son değeri olarak retained tutulmadıkça ya da kalıcı bir oturumda kuyruğa alınmadıkça düşürülür. Broker'ın işi depolamak değil, yönlendirmektir. Modele daha derinlemesine bakmak için MQTT publish/subscribe modeli yazısına bakın.
Noktadan noktaya kuyruklar (RabbitMQ, SQS ve benzerleri). Bir producer bir kuyruğa mesaj gönderir. Mesaj, bir tüketici onu alana kadar orada kalıcı olarak bekler. Aynı kuyrukta birden fazla tüketici varsa her mesaj yalnızca birine gider; tüketiciler iş için yarışır. Tüketici işlemeden sonra onay verir; onay vermeden çökerse mesaj başka bir tüketici için yeniden görünür hale gelir. Kuyruğun işi, her iş biriminin biri tarafından bir kez yapıldığından emin olmaktır.
Kısacası: MQTT "bunu kimin bilmesi gerekiyor?" sorusunu, kuyruk ise "bu işi kim yapacak?" sorusunu yanıtlar.
MQTT Broker ve Mesaj Kuyruğu Karşılaştırması
| Özellik | MQTT broker | Mesaj kuyruğu (RabbitMQ, SQS tarzı) |
|---|---|---|
| Teslimat | Eşleşen her subscriber'a bir kopya | Her mesaj tek bir tüketiciye |
| Adresleme | Hiyerarşik topic'ler, + ve # wildcard'ları |
Adlandırılmış kuyruklar (RabbitMQ'da ayrıca exchange'ler ve binding'ler) |
| Tüketici yokken oluşturulan mesaj | Retained değilse veya kalıcı bir oturum için tutulmuyorsa düşürülür | Tüketilene veya süresi dolana kadar saklanır |
| Depolama | Topic başına son retained değer, istemci başına oturum kuyrukları | Kalıcı kuyruklar, çoğu zaman uzun saklama süresiyle |
| Onay | İstemci ile broker arasında QoS 1 ve 2 | İşlemeden sonra tüketici onayı, hata durumunda yeniden teslim |
| İş dağıtımı | MQTT 5'te shared subscription'lar | Yerleşik rekabet eden tüketiciler |
| Dead-letter yönetimi | MQTT'nin parçası değil | Yaygın özellik (dead-letter kuyrukları ve exchange'leri) |
| Sıralama | İstemci oturumu başına, topic bazında | Kuyruk bazında, yeniden teslim durumunda bazı istisnalarla |
| Teslim modu | Bağlı istemcilere push | Push (RabbitMQ) veya pull/long poll (SQS) |
| İstemci ayak izi | Çok küçük, mikrodenetleyicilerde çalışır | Sunucu sınıfı SDK'lar |
| Varlık bilgisi ve durum | Keep alive, Last Will, retained message'lar | Uygulanamaz |
| Tipik kullanım | Cihaz telemetrisi, komutlar, canlı durum, dashboard'lar | Arka plan işleri, sipariş işleme, ayrıştırılmış mikroservisler |
Modellerin Kesiştiği Yerler
Çizgi tamamen keskin değildir ve kafa karışıklığının bir kısmı da buradan gelir.
MQTT'nin kuyruk benzeri iki özelliği vardır. Kalıcı oturum, broker'ın tek bir istemci çevrimdışıyken onun için QoS 1 ve 2 mesajlarını kuyruğa almasını sağlar; MQTT 5'te bunu bir session expiry interval ile sınırlarsınız. Shared subscription'lar ($share/group/filter) bir gruptaki birden fazla istemcinin bir topic'in mesajlarını paylaşmasına izin verir; böylece her mesaj grubun yalnızca bir üyesine ulaşır ki bu tam olarak rekabet eden tüketici davranışıdır. Ayrıntılar için MQTT shared subscription'lar ve MQTT kalıcı oturum yazılarını okuyun.
Kuyruk sistemleri de kendi tarafından pub/sub sunar. RabbitMQ'nun fanout ve topic exchange'leri bir mesajı birden fazla kuyruğa kopyalar; bulut servisleri de fan-out için bir bildirim topic'ini birden fazla kuyrukla eşleştirir. Ancak her subscriber'ın yine de önceden tanımlanmış kendi kuyruğuna ihtiyacı vardır.
Dolayısıyla asıl soru hangi özelliklerin var olduğu değil, hangi modelin yerleşik olduğudur. MQTT'nin yerleşik modeli hafif ve dinamik subscription'larla fan-out'tur; kuyrukların yerleşik modeli ise kalıcı iş dağıtımıdır.
Farkı İki Dakikada Görün
Fan-out'u mosquitto istemcileriyle ücretsiz herkese açık MQTT broker üzerinde izleyebilirsiniz. Başkalarının mesajlarını görmemek için benzersiz bir önek kullanın.
PREFIX="connectmq/demo/$(openssl rand -hex 4)"
# Fan-out: bunu her biri farklı client ID'ye sahip iki terminalde çalıştırın
mosquitto_sub -h broker.connectmq.com -V mqttv5 -i fan-$RANDOM \
-t "$PREFIX/orders/new" -v
# İstemci başına hız sınırına takılmayacak kadar yavaş beş mesaj publish edin
for i in 1 2 3 4 5; do
mosquitto_pub -h broker.connectmq.com -V mqttv5 -i pub-$RANDOM -q 1 \
-t "$PREFIX/orders/new" -m "order $i"
sleep 0.5
done
Her iki subscriber da beş siparişin tamamını yazdırır. Kuyruk benzeri davranış için shared subscription içeren bir broker planına, örneğin ConnectMQ'da ücretli bir Serverless broker'a ihtiyacınız vardır. Kendi kimlik bilgilerinizle iki worker başlatın (her worker'ın portaldan alınmış kendi client ID'sine ve buna uygun kimlik bilgilerine ihtiyacı vardır) ve yeniden publish edin:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -V mqttv5 \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-t '$share/workers/orders/new' -v
Shared subscription kullanan iki worker mesajları paylaşır; bu yüzden her biri yalnızca bir kısmını yazdırır. Ardından iki worker'ı da durdurun, yeniden publish edin ve onları tekrar başlatın: Çevrimdışıyken publish edilen siparişler kaybolmuştur. Onları yalnızca kalıcı bir oturum tutabilirdi; o da yalnızca o tek istemci için ve yalnızca session expiry interval süresince. Gerçek bir kuyruğun doldurduğu boşluk budur.
MQTT Broker Ne Zaman Kullanılmalı?
Bir MQTT broker şu durumlarda doğru yapı taşıdır:
- Üreticiler cihazlardır. Sensörler, PLC gateway'leri, araçlar, mobil uygulamalar ve tarayıcılar küçük istemcilere ve hoşgörülü bağlantı yönetimine ihtiyaç duyar.
- Aynı veriye birçok tüketicinin ihtiyacı vardır. Bir ölçüm aynı anda bir dashboard'a, bir historian yazıcısına ve bir alarm servisine gider; dördüncü bir tüketici eklemek üreticide hiçbir değişiklik gerektirmez.
- Güncel durum, geçmişten daha önemlidir. Retained message'lar her yeni subscriber'a bilinen son değeri anında verir.
- Varlık bilgisine ihtiyacınız vardır. Keep alive ve Last Will bir cihazın çevrimdışı olduğunu size bildirir.
- NAT arkasındaki veya hücresel bağlantılardaki belirli cihazlara komut push etmeniz gerekir.
Broker'lar konusunda genel olarak yeniyseniz bir MQTT broker'ın ne yaptığı yazısı temelleri ele alıyor; MQTT eğitimi ise topic'leri, QoS'u ve oturumları adım adım anlatıyor.
Mesaj Kuyruğu Ne Zaman Kullanılmalı?
Bir kuyruk şu durumlarda doğru yapı taşıdır:
- Her mesaj bir iştir ve fatura oluşturmak veya bir görseli yeniden boyutlandırmak gibi, tek bir worker tarafından tam olarak bir kez işlenmelidir.
- İşlerin, tüketicilerin saatler veya günler süren uzun kesintilerinden sağ çıkması gerekir.
- Tekrar tekrar başarısız olan mesajlar için yeniden denemelere ve dead-letter yönetimine ihtiyacınız vardır.
- Üreticiler ve tüketiciler güvenilir ağlardaki backend servisleridir.
İkisini Birlikte Kullanmak
IoT platformlarının çoğu sonunda ikisini birden kullanır. Cihazlar bir MQTT broker'a publish eder. Bir consumer servisi, ölçeklenebilmesi için genellikle bir shared subscription aracılığıyla subscribe olur, akışı işlenmesi gereken olaylara, örneğin "alarm tetiklendi" veya "parti tamamlandı" olaylarına indirger ve bunları RabbitMQ veya SQS'te iş olarak kuyruğa ekler. Canlı telemetri MQTT üzerinden dashboard'lara akmaya devam ederken kalıcı iş akışları kuyruktan çalışır. MQTT vs AMQP makalesi Python ile yazılmış çalışan bir köprü içeriyor.
MQTT tarafını seçerken onu kendiniz mi çalıştıracağınıza yoksa bir bulut MQTT broker mı kullanacağınıza karar verin. ConnectMQ; MQTT 3.1.1 ve 5.0, TLS, retained message'lar, session expiry ve ücretli Serverless planda shared subscription'lar ile çok kiracılı izolasyon ve plan bazlı kotalar sunan yönetilen bir broker'dır. Bir kuyruk değil, bir broker'dır: Yerleşik bir kuyruk köprüsü yoktur; devir teslimi consumer servisiniz yapar ve bu da sınırı açık tutar.
ConnectMQ ile Başlayın
MQTT broker'ı en iyi yaptığı işler için, yani fan-out, canlı durum ve cihaz bağlantısı için kullanın; kalıcı işlere ihtiyaç duyduğunuzda onu bir kuyrukla eşleştirin. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun ve yukarıdaki fan-out ile shared subscription demosunu kendi özel broker'ınızda deneyin.
Sık Sorulan Sorular
MQTT broker bir mesaj kuyruğu mudur?
Klasik anlamda hayır. Bir MQTT broker her mesajın kopyalarını mevcut tüm subscriber'lara yönlendirir; bir kuyruk ise her mesajı bir tüketici işleyene kadar saklar. MQTT'nin kuyruk benzeri özellikleri vardır ama özünde pub/sub'dır.
MQTT bir mesajın yalnızca bir kez işlenmesini garanti edebilir mi?
QoS 2, uçtan uca işlemeyi değil, bir istemci ile broker arasında tam olarak bir kez teslimatı garanti eder. İşlerin yalnızca bir kez işlenmesi için idempotent tüketiciler kullanın ya da işi bir mesaj kuyruğuna devredin.
Kimse subscribe değilken MQTT mesajlarına ne olur?
Atılırlar; mesaj retained ise broker onu topic'in son değeri olarak tutar, ya da çevrimdışı bir subscriber için kalıcı bir oturum varsa mesaj onun için saklanır.
IoT cihazları için RabbitMQ mu yoksa MQTT broker mı kullanmalıyım?
Cihazları, çok sayıda hafif ve aralıklı bağlanan istemci için tasarlanmış bir MQTT broker'a bağlayın. İş akışlarınız gerektiriyorsa backend iş kuyrukları için onun arkasında RabbitMQ kullanın.
