Kiểm thử MQTT: QoS, session state, retained message và broker failover

Đầu tiên phải xác định message nào được phép mất, message nào được phép lặp và thứ tự có cần được bảo toàn theo topic hay theo thiết bị. QoS MQTT mô tả mức bảo đảm chuyển giao giữa các bên tham gia từng hop; nó không tự tạo exactly-once cho toàn bộ nghiệp vụ nếu ứng dụng ghi database rồi retry thiếu idempotency.

MQTT 5.0 còn có session expiry, message expiry, receive maximum, topic alias và reason code. Phạm vi test phải ghi đúng protocol version, client library, broker version và cluster mode. Kết quả MQTT 3.1.1 không được suy sang MQTT 5.0.

Topology gồm nhiều publisher, load balancer nếu có, cụm broker, nhiều subscriber và network emulator. Đặt collector tại client và broker; message mang message_id nghiệp vụ, publisher timestamp và sequence theo device/topic. Packet capture chỉ lấy mẫu vì TLS và tải lớn có thể làm capture thành bottleneck.

Tạo direct baseline với một broker, rồi HA topology có persistent store hoặc replication đúng như production. Đồng bộ clock, ghi DNS/TLS/auth path, load-balancer affinity và session routing. Nếu bridge hoặc cloud gateway tham gia, coi mỗi hop là một boundary cần đo riêng.

Khóa QoS publish và QoS được broker chấp nhận cho subscription (hai hop có thể khác QoS), clean start, session expiry interval, message expiry, retained flag, Retain Handling của MQTT 5.0, topic depth, payload size, keep-alive, inflight window, receive maximum và reconnect backoff. Cũng phải cố định TLS version, authentication, client ID policy và storage durability.

Traffic profile nên có steady telemetry, burst alarm, subscriber chậm, offline subscriber và reconnect đồng loạt. Ghi phân bố payload và topic cardinality thay vì dùng một message đồng nhất; wildcard subscription có thể tạo chi phí rất khác topic cụ thể.

KPI gồm publish acceptance rate, end-to-end delivery rate, duplicate rate, out-of-order rate, latency p50/p95/p99, offline backlog, backlog drain time, session restoration và reconnect success. Ở broker thu CPU, memory, connection count, inflight, queue depth, persistence latency và replication lag.

Pass/fail phải tính từ ledger của message. Ví dụ minh họa “100% alarm QoS 1 đã được chấp nhận, chưa hết message/session expiry, được nhận trong SLO; duplicate được dedupe theo message_id” là mục tiêu nghiệm thu cần thỏa thuận, không phải bảo đảm vô điều kiện hay kết quả đo của NetVali.

• Lớp: Publisher · KPI: accepted/rejected, PUBACK latency · Bằng chứng: client log + reason code · Cạm bẫy: Thành công socket bị coi là publish thành công
• Lớp: Broker · KPI: queue, inflight, store/replication · Bằng chứng: metrics và config snapshot · Cạm bẫy: Chỉ xem CPU trung bình
• Lớp: Subscriber · KPI: delivery, duplicate, ordering · Bằng chứng: message ledger · Cạm bẫy: Không có ID nghiệp vụ
• Lớp: Dịch vụ · KPI: hành động hữu ích hoàn tất · Bằng chứng: app/database log · Cạm bẫy: Đồng nhất nhận message với xử lý thành công

MQTT 5.0 mục 4.4 chỉ cho gửi lại PUBLISH QoS > 0 chưa xác nhận và PUBREL khi reconnect với Clean Start=0 và session còn tồn tại, dùng Packet Identifier cũ; không tự retry MQTT theo timer trên kết nối đang mở. TCP retransmission là cơ chế khác.

Không trộn retained message với queued message của persistent session. Retained là giá trị broker lưu cho topic để gửi tới subscription mới; queued message phụ thuộc session và QoS.

• Kịch bản: QoS 0, mạng ổn định/loss · Kỳ vọng cần kiểm chứng: Không hứa retry; đo loss thực tế
• Kịch bản: QoS 1, chưa nhận PUBACK rồi reconnect tiếp tục session · Kỳ vọng cần kiểm chứng: Gửi lại có thể tạo duplicate; ứng dụng phải idempotent
• Kịch bản: QoS 2, ngắt giữa handshake · Kỳ vọng cần kiểm chứng: Hoàn tất state machine, không nhân đôi ở MQTT layer
• Kịch bản: Subscriber offline, session còn hạn · Kỳ vọng cần kiểm chứng: Subscription/state và queued message theo cấu hình
• Kịch bản: Session hết hạn · Kỳ vọng cần kiểm chứng: State cũ bị loại đúng thời điểm
• Kịch bản: Retained publish/clear · Kỳ vọng cần kiểm chứng: Kiểm bản tin theo Retain Handling; sau clear không còn retained cho subscription mới
• Kịch bản: Broker failover · Kỳ vọng cần kiểm chứng: Đo reconnect, session, backlog và message outcome

Ledger nên có các mốc published, broker-acknowledged nếu QoS có ACK tương ứng, delivered và application-committed; QoS 0 không có PUBACK nên không được tạo mốc xác nhận giả. Nếu chỉ có tổng counter, message mất và duplicate có thể triệt tiêu nhau.

• Bước 1: Lưu broker/client version, cluster mode, config và clock error.
• Bước 2: Chạy một publisher–subscriber để kiểm ledger, sequence và timestamp.
• Bước 3: Quét QoS 0/1/2 với cùng payload, rate và duration.
• Bước 4: Dùng test harness có nhận biết MQTT để giữ/chặn ACK hoặc cắt kết nối tại các bước handshake; reconnect tiếp tục session rồi kiểm gửi lại và duplicate. Mất packet IP đơn thuần thường được TCP khôi phục, không tương đương mất ACK ở lớp MQTT.
• Bước 5: Ngắt subscriber dưới, ngang và trên session expiry; đo backlog và khôi phục.
• Bước 6: Publish retained message, subscribe mới theo từng Retain Handling, cập nhật rồi clear bằng PUBLISH RETAIN=1 với payload 0 byte; xác nhận subscription mới không còn nhận retained cũ.
• Bước 7: Tạo subscriber chậm; quan sát receive maximum, queue và expiry.
• Bước 8: Fail broker active, store hoặc link replication; đo outcome từng message quanh trigger.
• Bước 9: Tạo reconnect storm có và không jitter/backoff.
• Bước 10: Lặp ba lần, đối chiếu client ledger, broker log, metrics và pcap mẫu.

Chèn latency, jitter, packet loss, reordering, bandwidth limit, DNS failure, TLS/auth dependency failure và partition giữa broker nodes. Trigger phải có timestamp ngoài băng. Với cluster, tách process crash, host loss, storage stall và network partition vì chúng tạo quyết định leadership/session khác nhau.

Tăng connection count và message rate theo bậc, nhưng giữ phân bố topic/payload. Đo tail latency và queue age, không chỉ aggregate throughput. Reconnect storm cần client ID thật, TLS handshake và subscription restore; một benchmark mở TCP thuần không đại diện tải dịch vụ.

QoS 2 có overhead cao hơn nhưng không bảo đảm exactly-once ở database hay thiết bị chấp hành ngoài broker. Thứ tự cũng chỉ nên kết luận trong phạm vi publisher/topic/session đã thử; nhiều publisher và fan-out có thể thay đổi quan sát. Failover thành công ở một node không chứng minh cluster chịu network partition.

Kết quả phải giới hạn theo client library, broker version, storage, cluster topology, TLS/auth, traffic profile và impairment. Vendor benchmark thiếu topic cardinality, payload, persistence và subscriber behavior không đủ làm ngưỡng acceptance.

• Phân loại message theo loss/duplicate/ordering tolerance.
• Chọn QoS và session policy theo nghiệp vụ, không theo thói quen.
• Bắt buộc message ID và idempotency cho hành động quan trọng.
• Cấu hình reconnect backoff có jitter và giới hạn inflight.
• Giám sát queue age, expiry, duplicate và tail latency.
• Canary broker/client upgrade; lưu rollback và compatibility matrix.
• Tái kiểm thử khi đổi load balancer, persistence hoặc auth backend.

• QoS 0/1/2: at-most-once, at-least-once và exactly-once ở lớp MQTT tương ứng.
• Session expiry: thời gian broker giữ session state sau disconnect.
• Retained message: giá trị broker lưu theo topic, phân phối tùy Retain Handling; độc lập session và có thể hết message expiry.
• Inflight message: message đang trong quy trình xác nhận.
• Duplicate: message được giao lại; cần ID nghiệp vụ để nhận biết.
• Backlog drain time: thời gian xử lý hết hàng đợi sau phục hồi.