MQTT'de Mesaj Kuyruğu Yoktur: Modern IoT'ye Güç Veren 2 Baytlık Protokolün İç Yüzü

1999 yılında Andy Stanford-Clark ve Arlen Nipper adlı iki mühendis, Amerika'nın güneybatısındaki ıssız çöllerde yüzlerce mil boyunca uzanan ham petrol boru hatlarını izlemek gibi zorlu bir mühendislik problemiyle karşılaştı. Mevcut tek iletişim kanalı, kilobayt başına ücretlendirilen kırılgan ve düşük bant genişliğine sahip uydu bağlantılarıydı. Uzaktaki pille çalışan sensörler, küçücük 8-bit mikrodenetleyicilere ve çok kısıtlı bellek tamponlarına (buffer) sahipti. Eğer HTTP kullansalardı, yalnızca tekrarlayan düz metin başlıkları bile her gün binlerce dolarlık uydu bant genişliği harcayacak ve cihaz pillerini bir hafta içinde tüketecekti.

Bu krizi çözmek için yalın bir ikili (binary) kablo protokolü tasarladılar ve ona MQTT (Message Queuing Telemetry Transport) adını verdiler. Günümüze geldiğimizde MQTT, gezegen genelinde yüz milyonlarca bağlı cihaza güç vermektedir:

• Bulut filolarına gerçek zamanlı batarya ve GPS telemetrisi aktaran her elektrikli araç.
• Home Assistant ve Zigbee ağları üzerinden çalışan her akıllı ampul ve sensör.
• Endüstriyel robotik ve üretim SCADA montaj hatları.
• Düşük segment cep telefonlarında pil tasarrufu sağlamak amacıyla mobil anlık bildirimlerini MQTT'ye taşıyan Facebook Messenger gibi mobil mesajlaşma devleri.

Ancak küresel yaygınlığına rağmen, MQTT ile ilk kez karşılaşan hemen hemen her yazılım mühendisi büyük ve temel bir yanılgıya düşer: MQTT'de aslında mesaj kuyrukları yoktur. Adındaki "MQ" harflerine rağmen MQTT, mesajları RabbitMQ gibi FIFO (İlk Giren İlk Çıkar) kuyruklarında tamponlamaz veya Apache Kafka gibi dağıtık bölüm (partition) günlüklerinde saklamaz. Bir abone (subscriber) kalıcı bir oturum olmadan çevrimdışı olursa, gelen mesajlar anında yok olur.

Peki MQTT gerçekte nedir? 2 bayt kadar küçük sabit bir başlıkla canlı telemetri paketi iletebilen, ultra kompakt, ikili çerçeveli (binary-framed) bir Publish/Subscribe (Yayınla/Abone Ol) olay yönlendiricisidir. Yazılım geliştiriciler için buradaki en önemli pratik çıkarım, kuyruk yapılarını taklit etmek için QoS 2 seviyesini suistimal etmekten kaçınmak ve protokolü doğasına uygun şekilde gerçek zamanlı veri akışı için kullanmaktır.

Büyük Yanılgı: MQTT'de Neden Kuyruk Yoktur?#

Yazılım mühendisleri "Mesaj Kuyruklama" kavramını duyduklarında doğal olarak RabbitMQ, ActiveMQ veya Amazon SQS gibi araçları hayal ederler:

• Bir yayıncı (publisher), adlandırılmış bir kuyruğa bir görev iter.
• Kuyruk, mesajı kalıcı bellekte tutar.
• Bir tüketici (consumer) dakikalar sonra çevrimiçi olur, görevi kuyruktan çeker, işler ve alındığını onaylar.

MQTT ise tamamen farklı bir paradigma üzerinde çalışır: Mekan, Zaman ve Senkronizasyon Ayrıştırması (Decoupling). Sensör veriyi factory/temp başlığına yayınlar, MQTT Broker bunu anında çevrimiçi abonelere iter; eğer çevrimiçi abone sayısı sıfırsa mesaj hemen düşürülür (silinir).

Mekansal Ayrıştırma (The Spatial Decoupling)#

MQTT'de yayıncılar ve aboneler birbirlerini asla tanımazlar. factory/temp adresine okuma verileri yayınlayan bir sıcaklık sensörünün hangi servislerin var olduğundan, kaç kontrol panelinin açık olduğundan veya hangi IP adreslerinde yaşadıklarından haberi yoktur. Paketini MQTT Broker (EMQX, Mosquitto veya HiveMQ gibi) adı verilen bir aracıya gönderir ve hemen uyku moduna geri döner. Bu mimari, mikroservis ve IoT projelerinde bileşenlerin birbirine bağımlı olmadan ölçeklenmesini sağlar.

Eksik Kuyruk (The Missing Queue)#

İşte bir kuyruk olmamasının nedeni: MQTT'de mesajlar kuyruklara değil, konulara (topics) teslim edilir. Bir broker PUBLISH paketi aldığında, bellek içi abonelik listesini inceler ve yalnızca o an dinleyen istemcilere iletim yapar. Geliştiriciler sistem tasarlarken MQTT'yi bir veri deposu değil, hafif ve anlık bir iletişim omurgası olarak konumlandırmalıdır.