MQTT, yayıncıların mesaj gönderdiği ve abonelerin ilgili topic’leri dinlediği bir mesajlaşma protokolüdür. Endüstriyel projede collector ile uygulama arasındaki veri aktarımına uygun olabilir. Fiziksel sensörü nasıl okuyacağınızı, değerin birimini veya alarmın anlamını kendiliğinden belirlemez; bunlar uygulamanın veri sözleşmesine aittir.
Broker ve topic yapısı
Broker mesaj akışını abonelere yönlendirir. Bir publisher’ın bütün alıcıları doğrudan bilmesi gerekmez. Bunun karşılığında broker erişimi, yetkiler, bağlantı durumu ve kapasite önemli işletim sorumlulukları hâline gelir. Her cihazın bütün topic’lere yazabilmesi güvenli bir varsayım değildir.
Topic adlandırması ekipman hiyerarşisini açıkça yansıtmalıdır. Örnek olarak site-a/line-2/machine-7/state kullanılabilir; bu temsilî bir isimdir, gerçek tesis adresi değildir. Ekipman adı değiştiğinde geçmiş kaydın kimliği bozulmamalıdır. Görünen ad ile kararlı cihaz kimliğini ayırmak bu nedenle yararlıdır.
Payload içinde ölçüm, birim, kaynak zamanı, kalite ve şema sürümü bulunabilir. Topic’e kişisel bilgi, parola veya erişim anahtarı koymayın. Mesaj boyutu ve hangi alanın isteğe bağlı olduğu dokümante edilmelidir; farklı yazılımlar aynı kaydı aynı biçimde yorumlamalıdır.
QoS neyi garanti eder?
OASIS MQTT 5.0 standardı üç QoS seviyesi tanımlar. QoS davranışı protokolün ilgili iletişim ayağıyla ilgilidir; veritabanına tek kayıt yazılması veya fiziksel işlemin yalnızca bir kez yapılması otomatik olarak sağlanmaz.
| Seviye | Protokol davranışı | Uygulama sorusu |
|---|---|---|
| QoS 0 | En fazla bir kez iletim | Kayıp örnek kabul edilebilir mi? |
| QoS 1 | En az bir kez iletim | Tekrar kayıtlar nasıl ayıklanacak? |
| QoS 2 | Protokol ayağında tam bir kez | Sonraki servislerde tekrar önleniyor mu? |
Abone bir mesajı işledikten sonra veritabanı bağlantısı kesilebilir. Yeniden denemede aynı olay tekrar işlenebilir. Kararlı olay kimliği, benzersizlik kuralı ve işlem sınırı bu yüzden MQTT seçiminin ötesinde tasarlanır. QoS 2’yi bütün iş sürecine ait sınırsız exactly-once garantisi diye anlatmak doğru değildir.
Retained mesaj güncel ölçüm demek değildir
Retained mesaj, yeni abonenin ilgili topic için saklanan son mesajı almasına yardımcı olur. Bu değer uzun süredir güncellenmemiş olabilir. Ekran, kaynağın zaman damgasını ve güncellik koşulunu kontrol etmelidir. Sırf bağlantı açıldı ve mesaj geldi diye cihaz sağlıklı kabul edilmez.
Last Will bağlantı kaybıyla ilişkili bir işaret üretebilir, ancak bütün arıza nedenlerini açıklamaz. Collector’ın bağlı olması onun bütün sensörleri doğru okuduğunu göstermez. Cihaz erişimi, collector sağlığı ve uygulama bağlantısı ayrı durumlar olarak görünmelidir.
Örnek: kesintili bağlantıda sıcaklık akışı
Bu açıklayıcı senaryoda collector sıcaklık kayıtlarını yerelde zaman damgasıyla biriktirir. Bağlantı geldiğinde kayıtlar olay kimlikleri korunarak gönderilir. Sunucu tekrarları ayıklar, geç gelen ölçümleri geçmişe yerleştirir ve güncel ekranı eski paketlerle geriye düşürmez.
Kuyruk sınırsız değildir. Azami kesinti süresi, doluluk alarmı ve disk bozulması davranışı belirlenir. Yeniden bağlantıda bütün cihazların aynı anda yoğun trafik üretmesi de sınanır. Kontrollü geri çekilme ve gecikmeli tekrar, ağın toparlanmasını kolaylaştırır.
Keşifte sorulacaklar
- Broker nerede çalışacak ve kim işletecek?
- Cihaz kimlikleri ve topic yetkileri nasıl yönetilecek?
- Mesajın geçerli sayılması için hangi alanlar gerekli?
- Çevrimdışı kayıt, yeniden gönderim ve tekrar ayıklama nasıl test edilecek?
- Sertifika veya erişim bilgisi yenilenince cihaz nasıl toparlanacak?
MQTT seçimi, doğru veri modelinin ve işletim planının yerini tutmaz. Önce küçük bir akışta normal çalışma, bağlantı kopması ve tekrar mesaj senaryoları doğrulanmalıdır.
Uygulama düzeyinde tekrar örneği
Bir toplayıcının observation-1042 kimliğiyle sıcaklık gözlemi yayımladığını düşünün. Alıcı uygulama kaydı saklıyor, fakat işleme onayı toplayıcıya ulaşmıyor. Yeniden gönderimde aynı gözlem kimliği ve ilk kaynak zamanı kullanılmalıdır. Böylece alıcı mevcut kaydı tanıyabilir. Her denemede yeni kimlik oluşturulursa iki teslimin aynı gözleme ait olduğuna ilişkin kanıt kaybolur ve geçmişte ikinci bir örnek oluşabilir.
Başka bir tüketici bu kayıttan alarm üretebilir. Onun işleme durumu ayrıca ele alınmalıdır: tekrar ölçümü önlemek, tekrar bildirimi kendiliğinden önlemez. Girdi olayı, alarm geçişi ve bildirim işi arasındaki ilişki saklanır. Mesaj sağlayıcısı zaman aşımına uğrarsa sonuç belirsiz olabilir; kesin biçimde hiçbir şey gönderilmedi demek doğru değildir. Bu, uygulama tasarımına ilişkin bir örnektir ve MQTT protokolünün ek bir teslim garantisi olarak yorumlanmamalıdır.
Reddedilen mesajların davranışını da kararlaştırın. Bilinmeyen şema sürümü, yanlış birim veya geçersiz ekipman kimliği teşhis edilebilir olmalıdır. Kalıcı biçimde bozuk bir mesajı sınırsız tekrar göndermek kullanılabilir veri üretmeden kaynak tüketir. Sınırlı bir reddetme süreci ve etkilenen kaynağı gösteren işletim görünümü kurun. Hata ayıklamayı kolaylaştırmak için erişim anahtarlarını veya bütün mesaj gövdelerini kontrolsüz loglara yazmayın.
Yetkileri ve toparlanmayı birlikte sınayın
Bir cihaz kimliğinin yayımlayabileceği ve abone olabileceği topic kapsamını test edin. Bu kapsamın dışında erişim deneyerek reddedildiğini doğrulayın. Değiştirilen kimlik bilgisini ve hizmetten çıkarılan cihazı sıradan yeniden bağlantıdan ayrı sınayın. Başarılı bağlantı, yetki sınırının doğru kurulduğunu tek başına göstermez. Cihazların hepsinin ortak ve sınırsız bir hesap kullanması, tek bir sorunun bütün sahaları etkilemesine yol açabilir.
Toparlanma çalışmasında kaynak okuması sürerken üst ağ bağlantısını kesin, ardından eski ve yeni gözlemlerle yeniden bağlanın. İlk zaman damgalarını, kayıt kimliklerini ve ekranda gösterilen veri yaşını kontrol edin. Yerel saklama alanı dolduğunda hangi kayıtların tutulduğunu ayrıca inceleyin. Broker daha sonra erişilebilir olsa bile doluluk nedeniyle gerçekleşmiş kayıp görünür kalmalıdır. Sonraki başarılı mesaj, önceki bütün gözlemlerin eksiksiz kurtarıldığını kanıtlamaz.
Kullanılan MQTT sürümünü, istemci ve broker’ın desteklediği oturum davranışını ve uygulamanın kabul yanıtını gerçek yapılandırmayla birlikte belgeleyin. Sürüm yükseltme veya istemci değişikliğinde bu sözleşmenin korunduğunu yeniden doğrulayın. Özellikle retained değerin yaşını ve bağlantı göstergesinin hangi katmanı temsil ettiğini ekran üzerinde kontrol edin. Protokol ayarlarının doğru olması, kullanıcıya verilen güncellik bilgisinin de doğru olduğu anlamına gelmez.
Entegrasyon görüşmesine örnek payload, tasarlanan topic hiyerarşisi ve kesinti sonrası beklenen davranışı getirin. Bu belgeler güvenilirliğin sınırlarını değerlendirmeyi mümkün kılar. Tek bir QoS seçeneğinin bütün veri kaydı, alarm ve fiziksel işlem sorunlarını çözdüğünü varsaymak yerine, her teslim sınırında hangi kanıtın üretildiğini açıkça göstermek daha sağlam bir yaklaşımdır.