Phần 2 – Kiến trúc MQTT: Pub/Sub, Broker, Topic, Payload & Hoạt động chi tiết

Xin chào các bạn, tiếp nối phần 1 về khái niệm tổng quan giao thức MQTT, hôm nay BKAII và các bạn sẽ tiếp tục thảo luận sang phần 2 nhé. Trong phần 2 của Series MQTT, chúng ta đi sâu vào kiến trúc hoạt động của MQTT – giao thức truyền dữ liệu nhẹ và phổ biến trong giám sát từ xa, IIoT, SCADA và các hệ thống công nghiệp hiện đại. Một khi hiểu rõ cơ chế Publish/Subscribe, Broker, Topic, Session, Retain và Will Message, bạn sẽ nắm được lý do vì sao MQTT hoạt động cực hiệu quả trong môi trường mạng yếu hoặc dùng 4G/5G.

1. Mô hình Publish/Subscribe (Pub/Sub)

MQTT sử dụng mô hình Pub/Sub thay vì Client/Server như Modbus hay HTTP. Trong mô hình này:

• Publisher: thiết bị gửi dữ liệu (cảm biến, PLC, gateway…)
• Subscriber: thiết bị nhận dữ liệu (SCADA, app, dashboard…)
• Broker: máy chủ trung gian chịu trách nhiệm nhận – phân phối gói tin

Điểm mạnh của mô hình Pub/Sub là tách biệt hoàn toàn giữa nơi gửi và nơi nhận. Publisher không cần biết ai đang nhận dữ liệu, giúp hệ thống linh hoạt và dễ mở rộng.

2. Broker MQTT – Trái tim của hệ thống

Broker chịu trách nhiệm:

• Xác thực kết nối từ client
• Quản lý danh sách Topic
• Xử lý Publish và phân phối dữ liệu đến Subscriber
• Quản lý Session, Retain và Will Message

Một số Broker phổ biến: Mosquitto, EMQX, HiveMQ, MQTTX Broker. Trong công nghiệp, Broker thường đặt tại trung tâm dữ liệu hoặc cloud để đảm bảo tính sẵn sàng cao.

3. Topic – “Địa chỉ” của dữ liệu

Topic trong MQTT đóng vai trò giống như “địa chỉ” của dữ liệu. Đây là một chuỗi ký tự được phân tách bằng dấu “/”, giúp phân loại và tổ chức thông tin theo cấu trúc tầng bậc.

Ví dụ một Topic hoàn chỉnh:

factory1/pump01/temperature

Ý nghĩa của Topic trên:

• factory1 – Nhà máy số 1
• pump01 – Bơm số 1 trong nhà máy
• temperature – Dữ liệu về nhiệt độ

Topic giúp dữ liệu được phân luồng rõ ràng, dễ quản lý và mở rộng hệ thống. MQTT không giới hạn số tầng của Topic, miễn là không dùng ký tự đặc biệt ngoài bảng ASCII chuẩn.

Wildcard trong Topic

MQTT hỗ trợ hai loại wildcard để Subscriber có thể đăng ký nhận nhiều Topic cùng lúc:

• + : đại diện cho một cấp trong Topic.
  Ví dụ:
  

  factory1/+/temperature

  → Nhận dữ liệu nhiệt độ của tất cả các thiết bị trong nhà máy 1.
• # : đại diện cho nhiều cấp (từ vị trí trở về sau).
  Ví dụ:
  

  factory1/#

  → Nhận toàn bộ dữ liệu của nhà máy 1 (mọi thiết bị, mọi loại dữ liệu).

Lưu ý quan trọng: Wildcard chỉ được dùng trong quá trình Subscribe, không dùng khi Publish.

4. Payload – Nội dung dữ liệu

Payload là phần dữ liệu thực tế mà thiết bị gửi đi trong bản tin MQTT. Nếu Topic đóng vai trò “địa chỉ”, thì Payload chính là “nội dung” bên trong gói tin. MQTT không quy định format cố định cho Payload, vì vậy nó rất linh hoạt và phù hợp với nhiều loại ứng dụng IoT khác nhau.

Các định dạng Payload phổ biến

• JSON – Format phổ biến nhất trong các hệ thống IoT nhờ tính dễ đọc, dễ phân tích.
  Ví dụ:

  {"temperature": 28.5, "humidity": 70}
          

• Chuỗi ký tự (String) – Dạng text thuần, thích hợp với các ứng dụng đơn giản.
  Ví dụ:

  28.5
          

• Hex/Binary – Dùng trong các thiết bị công nghiệp hoặc các giao thức nhúng cần tốc độ và dung lượng thấp.
  Ví dụ:

  0x1A 0xFF 0x0B
          

Vì sao Payload linh hoạt?

Nhờ không áp đặt cấu trúc dữ liệu, MQTT có thể phục vụ nhiều đối tượng khác nhau:

• Cảm biến nhỏ: chỉ gửi một số hoặc một chuỗi ký tự đơn giản.
• Hệ thống IIoT phức tạp: gửi JSON chứa nhiều trường dữ liệu, trạng thái, cảnh báo.
• Thiết bị nhúng: gửi dữ liệu dạng Hex/Binary để giảm băng thông.

Nhờ tính linh hoạt này, MQTT trở thành giao thức lý tưởng cho IoT – từ ứng dụng căn hộ thông minh đến nhà máy công nghiệp lớn.

5. Session, Retain và Will Message

✔ Session

Session lưu trạng thái kết nối của client. Nếu bật “clean session = false”, client có thể nhận lại dữ liệu đã bỏ lỡ.

✔ Retain Message

Retain là chức năng lưu lại giá trị cuối cùng tại Topic. Khi Subscriber mới kết nối, nó nhận được giá trị ngay lập tức.

✔ Will Message

Will Message hoạt động như một thông báo “thiết bị chết”. Nếu client mất kết nối đột ngột, Broker sẽ gửi Will Message đến các Subscriber để cảnh báo lỗi.

6. Tóm tắt kiến trúc MQTT

• Mô hình Pub/Sub → linh hoạt, dễ mở rộng
• Broker → quản lý toàn bộ giao tiếp
• Topic → địa chỉ dữ liệu
• Payload → nội dung dữ liệu
• Session, Retain, Will → nâng cao độ tin cậy

Nhờ kết cấu thông minh này, MQTT trở thành giao thức lý tưởng cho giám sát từ xa, SCADA, IIoT và các mạng truyền thông công nghiệp hiện đại.

📞 Hotline: 0936.111.936 | 📧 Email: Địa chỉ email này đang được bảo vệ từ spam bots, bạn cần kích hoạt Javascript để xem nó. Bạn cần kích hoạt Javascript để xem nó.