以解决问题方式逐步学习探索
- mqtt使用场景
- mqtt可能缺点
- mqtt学习疑问探索
- mqtt主题发布过的历史消息，全新连接的client能消费到吗？
- mqtt的client掉线如何重连，重连后订阅的topic配置还在不？
- mqtt的client掉线重连后，如何保证掉线期间的消息能被消费到？
- mqtt客户端订阅的消息能保证按序消费吗？
- mqtt客户端能订阅自己发布的主题消息吗？
- mqtt设置QoS=2还有必要在业务端判重吗？
- mqtt客户端最大支持连接数？
- mqtt服务器控制台？
mqtt使用场景
MQTT（Message Queuing Telemetry Transport）是一种轻量级的消息传输协议，特别适用于资源受限的设备（内存小）和网络环境较差（低带宽、降低网络流量成本）的场景。适用于物联网（IoT）设备之间的通信，常用于发布/订阅模式的消息传输。
mqtt可能缺点
不适合大数据量传输、缺乏复杂的事务处理、消息顺序不保证、依赖中间代理
mqtt学习疑问探索
mqtt主题发布过的历史消息，全新连接的client能消费到吗？
不能，只能消费新发布的消息
mqtt的client掉线如何重连，重连后订阅的topic配置还在不？
可以配置成自动连接或手动连接。
连接后，订阅的topic配置不存在了，确实需要重新订阅之前的主题
mqtt的client掉线重连后，如何保证掉线期间的消息能被消费到？
可以设置会话不被清空，会话清空的话，就消费不到掉线期间产生的消息了。
参考方法setCleanSession(true or false)
mqtt客户端订阅的消息能保证按序消费吗？
得考虑是否支持QoS2配置、能否按序生产、能否按序消费
mqtt客户端能订阅自己发布的主题消息吗？
可以
mqtt设置QoS=2还有必要在业务端判重吗？
保守、严谨来说，业务侧还是很有必要进行判重。
主要是因为消息消费后，在最后的确认机制未成功反馈结果时（极端情况下手动确认时，网络异常、系统故障等），消息还是可能被重复进行消费
mqtt客户端最大支持连接数？
具体看服务器配置、压测等情况…
mqtt服务器控制台？
看具体使用的mqtt协议中间件
