NanoMQ 中 QoS 1/2 消息持久化与会话管理机制解析

核心机制概述

NanoMQ 通过 SQLite 数据库实现了消息的持久化存储，主要作用于两类场景：

1. 桥接场景下：所有处于传输中（inflight）窗口的消息都会持久化，确保连接中断时不丢失
2. 本地代理场景下：仅 QoS 1/2 级别的消息会持久化存储，并在收到接收方 ACK 后自动删除

持久会话实现方案

要实现客户端离线期间不丢失消息（包括服务端重启场景），需同时满足两个条件：

1. 在 nanomq.conf 中启用 SQLite 持久化
2. 客户端连接时设置 clean_start = false 标志

性能影响警示

值得注意的是，启用持久化会显著影响系统性能。这是因为：

• 所有 QoS 1/2 消息需要实时写入磁盘
• 系统需要维护消息状态机
• ACK 确认机制带来额外的 I/O 操作

最佳实践建议

1. 生产环境部署时，建议根据业务需求评估是否真正需要持久化
2. 对延迟敏感的场景，可考虑仅对关键业务消息使用 QoS 1/2
3. 定期监控 SQLite 数据库大小，避免存储空间耗尽
4. 测试环境应模拟网络中断场景，验证消息恢复机制

实现原理深度解析

NanoMQ 的持久化架构采用 WAL(Write-Ahead Logging)模式：

• 消息先写入 SQLite 事务日志
• 通过定期检查点(checkpoint)将日志合并到主数据库
• 客户端重连时通过会话ID恢复消息流

这种设计在保证数据可靠性的同时，通过批量操作降低了磁盘I/O压力。