Kiểm thử MQTT ở quy mô lớn: session, QoS và reconnect storm

MQTT tách vai trò publisher, subscriber và broker, nhưng tải thực tế còn phụ thuộc số TCP/TLS connection, số subscription trên mỗi client, độ rộng topic tree, kích thước payload, keepalive, clean start, session expiry và QoS. Hai bài cùng 100.000 message/s có thể tạo áp lực hoàn toàn khác lên CPU, memory, storage và network.

Steady state cũng che khuất rủi ro khởi động lại hàng loạt. Sau mất điện hoặc mất WAN, thiết bị có thể reconnect gần như đồng thời, thực hiện TLS handshake, authenticate, restore session rồi subscribe lại. Nếu client retry không có jitter, chính cơ chế phục hồi tạo thành tải lớn hơn traffic bình thường.

Topology tối thiểu gồm client emulator, broker hoặc cluster cần đo, subscriber sink độc lập, lớp network impairment tùy chọn và hệ thống telemetry. Tách management plane khỏi data plane để thu metric không cạnh tranh với traffic MQTT. Đồng bộ thời gian giữa generator, broker và sink để tính latency end-to-end.

Với cluster, ghi rõ load balancer, cơ chế session affinity, replication và đường đi publish-to-subscribe. Chạy calibration không qua broker hoặc với broker tham chiếu để xác nhận generator và sink chưa chạm CPU, ephemeral port, NIC hay file descriptor trước SUT.

Traffic profile nên xuất phát từ phân bố thiết bị, không dùng một client mẫu nhân đều. Tạo ít nhất ba nhóm: cảm biến publish định kỳ; thiết bị command/response hai chiều; gateway giữ nhiều subscription. Mỗi nhóm có tỷ lệ riêng về connection lifetime, message interval, payload và retry.

Topic phải phản ánh độ sâu và cardinality dự kiến. Một topic chung tối ưu routing khác hoàn toàn hàng triệu topic riêng. Payload nên có sequence number, timestamp và client ID để sink phát hiện missing, duplicate, out-of-order. Dữ liệu nén hoặc nhị phân phải được giữ đúng phân bố kích thước thay vì chỉ dùng chuỗi ngắn.

• Thành phần profile: Client đồng thời · Baseline cần ghi: Số online ổn định · Biến stress: Ramp, churn, reconnect burst
• Thành phần profile: Topic · Baseline cần ghi: Độ sâu, wildcard, cardinality · Biến stress: Fan-out lớn, topic mới liên tục
• Thành phần profile: Payload · Baseline cần ghi: P50/P95 kích thước · Biến stress: Burst payload lớn
• Thành phần profile: Publish rate · Baseline cần ghi: Theo nhóm thiết bị · Biến stress: Step, spike, soak
• Thành phần profile: TLS/auth · Baseline cần ghi: Version, cipher, reuse · Biến stress: Full handshake đồng thời

QoS 0 không xác nhận giao nhận; QoS 1 có thể tạo duplicate; QoS 2 thêm handshake và trạng thái. Vì vậy phải báo cáo từng QoS riêng và định nghĩa success tại subscriber sink. Không coi PUBACK tại publisher là bằng chứng subscriber cuối đã nhận.

Clean Start, Session Expiry Interval, retained message, Will Message và offline queue tác động trực tiếp lên memory/storage. Nếu thử persistence, ghi rõ backend, replication factor, flush policy và giới hạn queue. Với TLS, cố định version, cipher suite, certificate chain và tỷ lệ resumption; nếu không, chi phí mật mã có thể lẫn với giới hạn routing bản tin.

KPI chính gồm successful connections/s, active connections, subscribe success, publish accepted, end-to-end delivery ratio, duplicate ratio, out-of-order ratio và latency percentile. Với reconnect, thêm thời gian từ khi mạng phục hồi đến khi 95% client online và backlog được xử lý hết.

Telemetry broker cần CPU theo core, memory, file descriptor, socket state, queue depth, storage latency, replication lag và event loop delay nếu có. Bằng chứng tối thiểu gồm cấu hình phiên bản, traffic profile, time-series tải/KPI, log lỗi có timestamp và mẫu packet capture giới hạn.

Pass/fail phải gắn SLO, ví dụ tỷ lệ giao nhận tối thiểu theo QoS và thời gian phục hồi tối đa. Không đặt “broker không crash” làm tiêu chí duy nhất; hệ thống vẫn có thể sống nhưng mất bản tin hoặc latency vượt ngưỡng vận hành.

• Bài đo: Connection scale · Biến chính: Concurrent client · KPI pass/fail gợi ý: Tỷ lệ connect, p95 connect time · Dấu hiệu sai phép đo: Generator cạn port
• Bài đo: Message throughput · Biến chính: Publish rate · KPI pass/fail gợi ý: Delivery, p95/p99 latency · Dấu hiệu sai phép đo: Sink quá tải
• Bài đo: Fan-out · Biến chính: Subscriber/topic · KPI pass/fail gợi ý: Delivery và broker queue · Dấu hiệu sai phép đo: Mạng đích bão hòa
• Bài đo: Session persistence · Biến chính: Offline duration · KPI pass/fail gợi ý: Backlog integrity, recovery · Dấu hiệu sai phép đo: Storage chưa bền
• Bài đo: Reconnect storm · Biến chính: Client/s, jitter · KPI pass/fail gợi ý: Recovery time, error ratio · Dấu hiệu sai phép đo: Retry vô hạn
• Bài đo: Soak · Biến chính: Thời gian · KPI pass/fail gợi ý: Không leak, latency ổn định · Dấu hiệu sai phép đo: Log/storage đầy

Checklist trước chạy: khóa cấu hình DNS/TLS/auth; đồng bộ thời gian; đặt seed ngẫu nhiên; giới hạn retry; xác nhận kill switch; dọn retained/offline state giữa các run; lưu broker version và cluster topology.

• 1. Xác nhận baseline ở 30–40% tải mục tiêu, kiểm tra sequence không thiếu ngoài semantics cho phép.
• 2. Ramp client theo nhiều bậc; lưu ngưỡng generator và broker còn headroom.
• 3. Ngắt đường truyền có kiểm soát, không tắt broker; giữ đủ lâu để client kích hoạt retry.
• 4. Khôi phục mạng với các profile retry: không jitter, jitter nhỏ và exponential backoff đúng thiết kế.
• 5. Theo dõi connect/auth/subscribe rate, backlog, delivery và thời gian phục hồi.
• 6. Lặp lại khi một broker node restart hoặc load balancer chuyển node.
• 7. Dừng ngay nếu error, queue, storage latency hoặc resource vượt guardrail.

Nếu connect latency tăng trước message latency, nút thắt có thể ở TLS/auth hoặc accept queue. Nếu publish accepted nhưng sink thiếu dữ liệu, cần kiểm tra queue, routing và subscriber capacity. Nếu chỉ một node nóng, xem lại hashing, session affinity và phân bố topic thay vì kết luận toàn cluster thiếu tài nguyên.

Kết quả chỉ có giá trị cho phiên bản broker, cấu hình persistence, workload và topology đã đo. Không suy diễn QoS 0 sang QoS 2, plaintext sang TLS hoặc broker đơn lẻ sang cluster. Test lab cũng không tự chứng minh độ bền khi storage thật, WAN thật và thiết bị firmware đa dạng chưa được đại diện.

• QoS: Mức đảm bảo giao nhận của MQTT; không đồng nghĩa mọi ứng dụng nhận đúng một lần end-to-end.
• Session Expiry: Thời gian broker giữ trạng thái session sau khi client ngắt.
• Retained Message: Bản tin cuối được broker giữ cho subscriber mới.
• Reconnect storm: Nhiều client kết nối lại trong thời gian ngắn sau sự cố chung.
• Fan-out: Một bản tin được phân phối tới nhiều subscriber.
• Backpressure: Cơ chế làm chậm phía phát khi pipeline phía sau không theo kịp.