QoS, Session và Retain trong MQTT | Hiểu đúng các cơ chế cốt lõi trong giao thức MQTT

Các bạn thân mến, chúng ta đã cùng nhau trải qua  Phần 1 – MQTT là gì? và Phần 2 – Kiến trúc MQTT (Pub/Sub – Broker – Topic – Payload), BKAII  tin rằng phần nào đó các bạn đã hình dung rõ cách dữ liệu được truyền trong hệ thống MQTT và vai trò của từng thành phần. Tuy nhiên, để vận hành một hệ thống MQTT ổn định trong thực tế – đặc biệt trong môi trường IIoT, dây chuyền sản xuất, nhà máy thông minh – bạn cần hiểu sâu hơn về các cơ chế đảm bảo dữ liệu như QoS, Session và Retain Message. Đây chính là những “chìa khóa” quyết định dữ liệu có bị mất hay không, thiết bị có tự động kết nối lại được hay không, và broker có lưu lại giá trị mới nhất hay không.

Vì vậy, trong Phần 3, chúng ta sẽ cùng phân tích chi tiết ba concept quan trọng này để hiểu đúng – dùng đúng – và tránh các lỗi thường gặp khi triển khai MQTT trong hệ thống công nghiệp.

1. QoS – Mức độ đảm bảo truyền tin

QoS (Quality of Service) là cơ chế cốt lõi giúp MQTT vận hành ổn định ngay cả khi mạng yếu hoặc thiết bị kết nối không liên tục. Mỗi mức QoS không chỉ khác nhau ở “mức độ tin cậy”, mà còn liên quan đến cách MQTT xác nhận, xử lý trùng lặp và đảm bảo tính toàn vẹn của dữ liệu.

• QoS 0 – At most once
  Client gửi gói tin và không chờ phản hồi từ Broker. Gói tin có thể bị mất mà không có bất kỳ cơ chế khôi phục nào. → Phù hợp cho dữ liệu “không quan trọng”: giá trị cảm biến gửi liên tục vài giây/lần, lượng lớn dữ liệu thời gian thực.
• QoS 1 – At least once
  Client yêu cầu Broker xác nhận (PUBACK). Nếu không nhận được phản hồi, Client sẽ gửi lại → dẫn đến nguy cơ trùng lặp dữ liệu. → Thích hợp cho hệ thống cần đảm bảo dữ liệu không bị mất nhưng có thể xử lý trùng lặp ở phía ứng dụng.
• QoS 2 – Exactly once
  Mức QoS cao nhất, sử dụng vòng trao đổi 4 bước (PUBREC → PUBREL → PUBCOMP) để đảm bảo dữ liệu được gửi duy nhất 1 lần, không mất và không trùng lặp. → Dùng cho hệ thống quan trọng: lệnh điều khiển thiết bị, tín hiệu đóng/ngắt, cảnh báo ưu tiên cao.

Trong môi trường IIoT, phần lớn hệ thống sử dụng QoS 1 vì cân bằng được giữa tin cậy và hiệu suất, trong khi QoS 2 thường chỉ áp dụng cho luồng điều khiển để tránh tăng tải cho Broker.

2. Session – Trạng thái kết nối của Client

Session giúp MQTT ghi nhớ trạng thái của Client qua các lần kết nối. Đây là tính năng cực kỳ hữu ích đối với thiết bị chạy bằng pin, mạng không ổn định, hoặc các node edge gateway cần khôi phục nhanh trạng thái hệ thống.

Cơ chế hoạt động:

• Broker lưu lại danh sách các Topic mà Client đang subscribe.
• Lưu lại các tin nhắn QoS 1 và QoS 2 chưa gửi hoặc chưa xác nhận.
• Khi Client kết nối lại, Broker phục hồi phiên làm việc: gửi tiếp các tin tồn đọng.

Hai kiểu Session phổ biến:

• Clean Session = true
  Mỗi lần kết nối đều bắt đầu mới, Broker không giữ lại bất kỳ trạng thái nào. → Phù hợp cho các thiết bị gửi dữ liệu định kỳ không cần “lịch sử”, ví dụ cảm biến đo nhiệt độ, độ ẩm.
• Clean Session = false
  Broker lưu lại Session và các tin tồn đọng. → Rất quan trọng cho hệ thống phải đảm bảo không mất dữ liệu khi thiết bị mất kết nối, ví dụ:
  • Edge Gateway mất điện tạm thời
  • Thiết bị IoT dùng 4G bị rớt sóng
  • Máy móc trong dây chuyền reset trong quá trình bảo trì

Ví dụ thực tế: một cảm biến rung trục động cơ gửi dữ liệu QoS 1. Nếu Clean Session = false, khi nó kết nối trở lại sau 2 phút mất mạng, Broker sẽ gửi lại toàn bộ dữ liệu trễ giúp không mất chuỗi giá trị.

3. Retain Message – Lưu lại giá trị mới nhất

Retained Message là cách để Broker lưu trữ “bản tin cuối cùng” của một Topic. Điều này cực kỳ quan trọng đối với dashboard, SCADA IoT, giám sát thiết bị, hoặc các hệ thống cần trạng thái tức thời ngay khi bật lên.

Retain hoạt động như sau:

• Khi Client publish một bản tin kèm cờ retain=true, Broker lưu lại bản tin này.
• Khi một Client mới subscribe vào Topic, Broker gửi ngay bản tin retain, không cần chờ Client publish tiếp.
• Mỗi Topic chỉ lưu 1 bản tin mới nhất.

Lợi ích trong hệ thống thực tế:

• Hệ thống giám sát real-time không bị trống dữ liệu khi khởi động.
• Dashboard hiển thị được trạng thái mới nhất ngay lập tức (ON/OFF – Running/Stop – Alarm).
• Thiết bị mới vào mạng nắm được bức tranh hoạt động hiện tại.
• Giảm độ trễ cho SCADA/Edge Gateway khi cần khởi động nhanh.

Ví dụ Retain:
Topic: factory1/pump01/status
Payload: {"running": true}
→ Broker lưu lại và tự động gửi cho các client mới subscribe.

Trong các hệ thống công nghiệp, Retain đặc biệt quan trọng để đảm bảo dashboard, HMI IoT hoặc ứng dụng di động luôn có trạng thái mới nhất của thiết bị mà không phải chờ chu kỳ publish tiếp theo.

Qua Phần 3, chúng ta đã hiểu cách mà QoS (0/1/2), Session và Retain Message ảnh hưởng trực tiếp đến độ tin cậy của toàn bộ hệ thống MQTT. Đây chính là những yếu tố quyết định liệu dữ liệu có được truyền đầy đủ, có bị trùng lặp hay mất mát, và thiết bị có kết nối lại đúng trạng thái hay không.

Trong môi trường công nghiệp – nơi dữ liệu cảm biến, trạng thái thiết bị, tín hiệu cảnh báo đều cần được truyền chính xác và ổn định – việc lựa chọn đúng mức QoS, cấu hình session hợp lý và sử dụng retain message đúng chỗ sẽ giúp doanh nghiệp:

• Giảm thiểu gián đoạn khi thiết bị mất kết nối.
• Tối ưu băng thông & tốc độ trong mạng 4G/5G hoặc WiFi yếu.
• Đảm bảo dữ liệu nhất quán giữa nhiều client cùng đăng ký.
• Tăng độ ổn định cho hệ thống giám sát từ xa, SCADA và IIoT.

Có thể nói rằng QoS, Session và Retain chính là “xương sống” đảm bảo MQTT hoạt động tin cậy trong thực tế – và hiểu rõ chúng là bước quan trọng để xây dựng những hệ thống IIoT mạnh mẽ, linh hoạt, sẵn sàng mở rộng.

Ở Phần 4 của series, chúng ta sẽ tiếp tục với nội dung hấp dẫn hơn: Security trong MQTT – bảo mật TLS, Username/Password, ACL và cơ chế xác thực. Đây là yếu tố sống còn khi triển khai MQTT trong môi trường doanh nghiệp và công nghiệp.

Nếu bạn đang triển khai MQTT cho SCADA, Edge Gateway, hoặc nền tảng IoT – hãy tiếp tục theo dõi Series để nắm vững toàn bộ kiến thức từ cơ bản đến nâng cao!