Üretimde MQTT: topic tasarımı, QoS, retain ve Last Will

MQTT neyi garanti eder, neyi etmez?

MQTT, bir broker aracılığıyla yayıncı ile aboneleri birbirinden ayırır ve mesajın teslim güvencesini QoS ile tanımlar. Bunun dışında hiçbir şeyi tanımlamaz: topic adlarının nasıl kurulacağını, payload’ın biçimini, değerin birimini, mesajın ne kadar süre saklanacağını ya da bir tüketicinin geç gelen mesajı nasıl yorumlayacağını. Bunlar projenizin veri sözleşmesidir.

Broker da bir tasarım unsurudur: kesintisi tüm akışı durdurabilir. Yedeklilik, bağlantı sınırları, çevrimdışı istemciler için kuyruklama ve izleme seçtiğiniz broker ürününe bağlıdır ve ayrıca değerlendirilmelidir.

Topic tasarımı

Topic adı hiyerarşik bir yoldur ve büyük/küçük harfe duyarlıdır. Üretimde işe yarayan birkaç ilke:

• Geneli özele doğru ilerleyin. Örneğin tesis/alan/hat/ekipman/ölçüm. Böylece “bu hattın her şeyi” veya “tüm tesislerin sıcaklıkları” gibi abonelikleri joker karakterle yazabilirsiniz.
• Başa “/” koymayın. Baştaki eğik çizgi boş bir ilk seviye oluşturur ve genellikle istenmeyen bir sonuçtur.
• Küçük harf, rakam ve tire kullanın; boşluktan kaçının. Büyük/küçük harf farkı iki ayrı topic demektir ve hatalara yol açar.
• Veriyi topic’e koymayın. Topic kimliği ve yeri tanımlar; değer payload’da taşınır. Anlık değer gibi sürekli değişen parçalar topic ağacını şişirir.
• Yayında joker karakter kullanmayın. “+” ve “#” yalnızca abonelik filtrelerinde geçerlidir.
• “$” ile başlayan topic’leri kullanmayın. Bunlar broker’a ayrılmıştır (örneğin $SYS) ve kök seviyedeki “#” ile eşleşmez.

MQTT topic oluşturucu bu ilkelere göre örnek topic’ler ve abonelik filtreleri üretir; uzun vadeli adlandırma yaklaşımı için Unified Namespace yazısına bakın.

QoS seçimi

QoS her atlama için ayrı geçerlidir: yayıncıdan broker’a ve broker’dan aboneye. Aboneye uygulanan seviye, yayınlanan mesajın seviyesi ile aboneliğin istediği seviyenin düşüğüdür. Dolayısıyla yayıncı QoS 2 kullansa da QoS 0 ile abone olan bir istemci mesajı QoS 0 ile alır.

• QoS 0 (en fazla bir kez): Sık güncellenen ve bir sonraki örneğin zaten yerini alacağı telemetri için uygundur. Kayıp kabul edilebilir olmalıdır.
• QoS 1 (en az bir kez): Kaybın kabul edilmediği olaylar için yaygın seçimdir. Mesaj bir kereden fazla gelebilir; bu nedenle tüketicinin mükerrer mesajı güvenle işlemesi gerekir (idempotency).
• QoS 2 (tam bir kez): Dört adımlı bir el sıkışma gerektirir ve daha yavaştır. Mükerrerin tüketici tarafında yönetilemediği az sayıda durumda düşünülür.

QoS tek başına kesinti sırasındaki veriyi korumaz: bağlantı kopmuşsa ve istemci tarafında kuyruklama yoksa mesaj hiç yayınlanamaz. Kesinti tamponu için Store & Forward rehberine bakın.

Retain ve Last Will

Retain bayrağıyla yayınlanan mesaj broker tarafından o topic için saklanır ve yeni abone olan istemciye hemen iletilir. Bu, “son bilinen durum” topic’leri (ekipman durumu, mod, yapılandırma) için uygundur; olay akışları için uygun değildir, çünkü yeni bir abone yalnızca en son olayı alır. Retain edilmiş bir mesajı silmek için aynı topic’e retain bayrağıyla boş bir payload yayınlanır.

Retain edilmiş değerin ne kadar eski olduğunu broker söylemez; bu yüzden payload’da kaynak zaman damgası bulunmalıdır.

Last Will, bir istemci bağlanırken tanımlanan ve istemci beklenmedik biçimde koptuğunda (örneğin keep-alive süresi dolduğunda) broker’ın yayınladığı mesajdır. Yaygın kalıp şudur: istemci bağlanınca retain ile “online”, Last Will olarak da retain ile “offline” yayınlar. Böylece bir tüketici, verinin kaynağının canlı olup olmadığını aynı topic ağacından okuyabilir. Temiz bir kapanışta Last Will yayınlanmaz; bu yüzden istemcinin kapanırken “offline” mesajını kendisinin yayınlaması gerekir.

Oturum, kimlik ve yeniden bağlantı

Her istemcinin benzersiz bir istemci kimliği (Client ID) olmalıdır: aynı kimlikle ikinci bir bağlantı gelirse broker mevcut bağlantıyı keser. İki akışın yanlışlıkla aynı kimliği kullanması, sürekli kopma ve yeniden bağlanma döngüsüne yol açar.

Kalıcı oturumda (MQTT 3.1.1’de cleanSession=false; MQTT 5.0’da clean start ve oturum süresi ile) broker, istemci çevrimdışıyken QoS 1 ve 2 mesajlarını kuyruğa alabilir. Kuyruk sınırları broker’a bağlıdır; sınırsız saklama varsaymayın. Keep-alive süresini kısa seçmek kopmayı hızlı fark etmenizi sağlar ama ağ yükünü artırır; broker, keep-alive süresinin yaklaşık bir buçuk katı boyunca istemciden paket almazsa bağlantıyı koptu sayar.

İstemci tarafında yeniden bağlantıyı artan bekleme süresiyle (backoff) deneyin; aksi halde broker geri geldiğinde tüm istemciler aynı anda bağlanmaya çalışır.

Payload ve güvenlik

Payload için pratik bir başlangıç tek bir JSON nesnesidir: değer, birim, kaynak zaman damgası (UTC, ISO 8601), kalite ve şema sürümü. Sparkplug B gibi bir belirtim kullanıyorsanız topic ve payload yapısını belirtim tanımlar.

Güvenlik tarafında şifresiz MQTT için geleneksel port 1883, TLS ile şifreli bağlantı için 8883’tür. Kimlik doğrulama (kullanıcı adı ve parola veya istemci sertifikası) ve topic bazlı yetkilendirme (hangi istemci hangi topic ağacına yayın veya abonelik yapabilir) broker’da yapılandırılır. Her yayıncıyı yalnızca kendi alt ağacına yazabilecek şekilde sınırlamak, hatalı bir istemcinin başka verileri bozmasını engeller. Ağ bölgeleri ve sertifika yönetimi için güvenli veri akışları yazısına bakın.