MQTT vs AMQP: Farklar, Kullanım Alanları ve Performans

MQTT vs AMQP sorusu, bağlı cihazlar geliştiren bir ekip aynı zamanda RabbitMQ gibi bir message broker üzerinde backend servisleri de çalıştırdığında mutlaka gündeme gelir. Her iki protokol de broker tabanlıdır, ikisi de TCP üzerinde çalışır ve ikisi de teslim onayları sunar; yine de çok farklı işler için tasarlanmışlardır. Bu rehber broker modellerini, yönlendirmeyi, garantileri ve istemci ayak izini karşılaştırıyor ve her birinin mimarinizde nereye ait olduğuna dair pratik bir kuralla bitiyor.

Her Protokol Nereden Geliyor?

MQTT, güvenilmez ve düşük bant genişliğine sahip bağlantılar üzerinden uzak ekipmanlardan telemetri toplamak için tasarlandı. Öncelikleri küçük bir istemci, küçük bir paket formatı ve basit bir modeldir: istemciler hiyerarşik topic'lere publish eder ve wildcard'larla subscribe olur. MQTT bir OASIS standardıdır ve 3.1.1 ile 5.0 sürümleri yaygın olarak kullanılır.

AMQP (Advanced Message Queuing Protocol), önceliğin iş sistemleri arasında güvenilir ve birlikte çalışabilir mesajlaşma olduğu finans sektöründen doğdu. Birbirinden oldukça farklı iki soy hattı vardır. AMQP 0-9-1, çoğu geliştiricinin RabbitMQ'dan bildiği exchange, binding ve kuyruk modelidir. AMQP 1.0 ise OASIS ve ISO standardıdır; Azure Service Bus gibi servislerin kullandığı ve Apache ActiveMQ Artemis gibi broker'ların desteklediği daha genel bir eşler arası aktarım protokolüdür. Biri "AMQP" dediğinde hangisini kastettiğini sormaya değer.

Bir Bakışta MQTT vs AMQP

Özellik	MQTT	AMQP 0-9-1 (RabbitMQ tarzı)	AMQP 1.0
Temel model	Publish/subscribe ile topic'ler	Exchange'ler binding'ler aracılığıyla kuyruklara yönlendirir	Düğümler arası link'ler; broker semantiği uygulamaya göre tanımlanır
Yönlendirme	Hiyerarşik topic'ler, `+` ve `#` wildcard'ları	Direct, topic, fanout, headers exchange'leri	Adresler ve filtreler, broker'a özgü
Kuyruklar	Açık kuyruk yok (istemci başına oturum kuyrukları)	Açık, adlandırılmış, kalıcı kuyruklar	Broker tarafından tanımlanan düğümler
Teslim garantileri	QoS 0, 1, 2	Ack'ler, publisher confirm'ler, transaction'lar	Settlement modları, at-most-once ve at-least-once
İş dağıtımı	Shared subscription'lar (MQTT 5)	Bir kuyrukta rekabet eden tüketiciler	Bir düğümde rekabet eden alıcılar
Akış kontrolü	Receive maximum (MQTT 5)	Prefetch (basic.qos)	Kredi tabanlı link akış kontrolü
Header boyutu	Çok küçük, en az 2 baytlık sabit header	Daha büyük frame'ler ve özellikler	Daha büyük, zengin tipli kodlama
İstemci ayak izi	Mikrodenetleyicilere sığar	Sunucularda ve gateway'lerde rahat çalışır	Sunucularda ve gateway'lerde rahat çalışır
Tipik kullanım yeri	Cihazlar, gateway'ler, tarayıcılar, mobil uygulamalar	Backend mikroservisleri, görev kuyrukları	Kurumsal entegrasyon, bulut mesajlaşma servisleri

Broker Modeli ve Yönlendirme

Bir MQTT broker yalnızca topic'e göre yönlendirme yapar. Bir publisher plant1/line2/press4/temperature adresine gönderir ve subscription filtresi eşleşen her istemci bir kopya alır. Ayrı bir yönlendirme yapılandırması yoktur; topic hiyerarşisi yönlendirme tablosunun kendisidir. Bu da MQTT'yi benimsemeyi ve anlamayı kolaylaştırır; özellikle topic'ler ISA-95 ya da Unified Namespace gibi bir yapıyı izlediğinde. MQTT publish/subscribe modeli makalesi bu ayrıştırmayı daha ayrıntılı açıklıyor.

AMQP 0-9-1, mesajların nereye gönderildiğini (exchange) nerede saklandığından (kuyruklar) ayırır. Binding'ler ikisini kurallarla birbirine bağlar. Topic exchange biraz MQTT wildcard'ları gibi davranır, fanout exchange bağlı her kuyruğa kopyalar ve direct exchange tam bir anahtara göre yönlendirir. Bu esneklik, bir sipariş olayını her biri kendi saklama politikasına ve tüketicilerine sahip faturalama, sevkiyat ve analitik kuyruklarına dağıtmak gibi backend iş akışlarında çok güçlüdür. Bedeli ise öğrenilecek daha fazla kavram ve yönetilecek daha fazla yapılandırmadır.

Teslim Garantileri

MQTT üç QoS seviyesi sunar: en fazla bir kez (QoS 0), en az bir kez (QoS 1) ve istemci ile broker arasında tam olarak bir kez (QoS 2). Kalıcı oturumlar, broker'ın geçici olarak çevrimdışı olan bir subscriber için QoS 1 ve 2 mesajlarını tutmasını sağlar. Hatırlamak için MQTT QoS seviyeleri yazısına bakın.

AMQP size tüketici onayları, yeniden kuyruğa alma seçenekli negatif onaylar, publisher confirm'ler ve 0-9-1'de transaction'lar sunar. Mesajlar, bir tüketici açıkça ack verene kadar kalıcı bir kuyrukta bekler; bu da "bu faturayı oluştur" gibi tam olarak bir worker tarafından işlenmesi ve başarısız olursa yeniden denenmesi gereken işler için tam olarak istediğiniz şeydir.

Pratikte ikisi de güvenilir teslimat yapabilir. Fark vurgudadır: MQTT çok sayıda subscriber'a giden durum ve olay akışları için, AMQP ise rekabet eden tüketicilerin işlediği kalıcı iş öğeleri için optimize edilmiştir.

Performans ve Ayak İzi

Soyut olarak hiçbir protokol "daha hızlı" değildir. Throughput, hattaki formattan çok broker uygulamasına, kalıcılık ayarlarına, mesaj boyutuna ve onay moduna bağlıdır.

Protokollerin açıkça ayrıştığı nokta ayak izidir. Bir MQTT istemci kütüphanesi ESP32 veya benzeri bir mikrodenetleyiciye rahatça sığar ve mesaj başına paket ek yükü çok küçüktür; bu da hücresel ve uydu bağlantılarında önemlidir. AMQP istemcileri daha ağırdır, frame'ler daha fazla metadata taşır ve bağlantı kurulumu daha fazla müzakere içerir. Bir sunucuda bu fark önemsizdir; pille çalışan bir sensörde ise belirleyicidir.

MQTT ayrıca çoğu boşta duran çok sayıda bağlantıyı iyi yönetir; bu da bir IoT filosunun olağan görünümüdür. AMQP broker'ları ise genellikle servislerden gelen daha az sayıda ama daha yoğun bağlantı için ayarlanır.

Tipik Mimariler

MQTT vs AMQP sorusuna gerçek dünyadaki en yaygın yanıt "ikisi de, farklı katmanlarda" şeklindedir:

Cihazlar, gateway'ler ve dashboard'lar bir MQTT broker'a bağlanır.
Bir backend servisi ilgili MQTT topic'lerine subscribe olur, örneğin plant1/+/+/telemetry.
Bu servis veriyi doğrular ve zenginleştirir, ardından faturalama, destek kaydı ya da ERP güncellemeleri gibi sonraki işlemler için iş öğelerini bir AMQP kuyruğuna publish eder.

Aşağıda MQTT'ye subscribe olan ve pika ile bir RabbitMQ kuyruğuna publish eden minimal bir Python köprüsü var. Kendi sürecinde çalıştığı için gruplama, filtreleme ve hata yönetimini siz kontrol edersiniz.

import json
import uuid

import paho.mqtt.client as mqtt
import pika

PREFIX = "connectmq/demo/replace-me"

amqp = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
channel = amqp.channel()
channel.queue_declare(queue="telemetry", durable=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("MQTT connected:", reason_code)
    client.subscribe(f"{PREFIX}/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    try:
        body = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("skipping invalid payload on", msg.topic)
        return
    body["topic"] = msg.topic
    channel.basic_publish(
        exchange="",
        routing_key="telemetry",
        body=json.dumps(body),
        properties=pika.BasicProperties(delivery_mode=2),  # kalıcı
    )

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"amqp-bridge-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Production ortamında özel broker'ınıza 8883 portu üzerinden TLS ile client.tls_set() ve client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD") kullanarak bağlanın ve bu kimlik bilgileriyle birlikte verilen client ID'yi kullanın. pika'nın blocking bağlantısı thread-safe olmadığından, tüm AMQP çağrılarını gösterildiği gibi MQTT ağ döngüsü thread'i içinde tutun ya da mesajları özel bir AMQP thread'inin tükettiği bir kuyruğa devredin.

Ne Zaman MQTT Seçilmeli?

İstemciler mikrodenetleyiciler, gateway'ler, mobil uygulamalar ya da tarayıcılardır.
Bağlantılar güvenilmez, kotalı ya da yüksek gecikmelidir.
Aynı telemetri veya durum akışına birçok tüketicinin ihtiyacı vardır.
Çevrimiçi/çevrimdışı tespitine (keep alive ve Last Will) ve bilinen son değerlere (retained message'lar) ihtiyacınız vardır.
Saha mühendislerinin ve entegratörlerin yalnızca topic adlarından anlayabileceği basit bir model istersiniz.

Ne Zaman AMQP Seçilmeli?

Mesajlar, tek bir tüketicinin işlemesi ve onaylaması gereken iş birimleridir.
Gelişmiş yönlendirme kurallarına, dead-letter kuyruklarına ve kuyruk bazlı politikalara ihtiyacınız vardır.
Tüm üreticiler ve tüketiciler bir veri merkezindeki ya da buluttaki backend servisleridir.
Zaten AMQP 1.0 konuşan kurumsal sistemleri entegre ediyorsunuzdur.

Yönetilen Bir MQTT Broker Neden Çoğu Zaman Daha Basit Bir Çözümdür?

Cihazlara bakan tarafta genellikle operasyonel sadelik kazanır. Tamamen yönetilen bir MQTT servisi; yama, sertifika yenileme, bağlantı sayısını ölçekleme ve çok kiracılı izolasyon işlerini ortadan kaldırır ve ekibinizin topic tasarımına ve tüketicilere odaklanmasını sağlar. ConnectMQ; MQTT 3.1.1 ve 5.0'ı, Let's Encrypt sertifikalı TLS'i, ücretli Serverless planda shared subscription'ları ve flood korumalı plan bazlı kotaları destekler. Bir AMQP köprüsü içermez; bu nedenle köprüyü yukarıda gösterildiği gibi kendi servisiniz olarak çalıştırırsınız. Barındırma seçeneklerini daha geniş açıdan karşılaştırmak için bulut MQTT broker rehberini okuyun; topic'ler ve oturumlarla ilgili bilgilerinizi tazelemek için MQTT eğitimine göz atın. Kuyrukları ve broker'ları kavramsal olarak tartıyorsanız MQTT broker vs mesaj kuyruğu yazısı daha derine iniyor.

ConnectMQ ile Başlayın

Cihazlarınızı MQTT üzerinden ConnectMQ'ya bağlayın, AMQP'yi ise en iyi olduğu backend iş akışları için saklayın. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun, otomatik oluşturulan kimlik bilgilerini alın ve cihazlarınızı ve köprü servisinizi dakikalar içinde ona yönlendirin.

Sık Sorulan Sorular

IoT için MQTT, AMQP'den daha mı iyi?

Cihazlar için genellikle evet: MQTT istemcileri daha küçüktür, paketler daha hafiftir ve model aralıklı çok sayıda bağlantıyı iyi yönetir. AMQP ise backend iş kuyrukları için daha uygundur.

RabbitMQ MQTT konuşabilir mi?

RabbitMQ, MQTT topic'lerini kendi exchange modeline eşleyen bir MQTT eklentisi sunar. Özel bir MQTT broker ise genellikle daha kapsamlı MQTT özellik desteği ve büyük cihaz filoları için daha basit operasyon sağlar.

MQTT'de AMQP'deki gibi kuyruklar var mı?

Açıkça yok. Broker kalıcı oturumlar için istemci başına bir oturum kuyruğu tutar ve MQTT 5 shared subscription'ları birden fazla tüketicinin bir topic'in mesajlarını paylaşmasını sağlar; bu da kuyruk benzeri birçok kullanım senaryosunu karşılar.

MQTT ve AMQP'yi birlikte kullanabilir miyim?

Evet, bu yaygın bir yaklaşımdır. Cihazlar MQTT üzerinden publish eder; bir köprü servisi subscribe olur ve seçilen mesajları backend işleme için AMQP kuyruklarına iletir.

MQTT vs AMQP: Farklar, Kullanım Senaryoları ve Performans