关于mqtt的问题

• mqtt是顺应物流网的兴趣诞生的一个协议,出发点是"互联",意思是"必须联网"状态下S端才能接收到P端信息,如果S端没有在线,不管怎么配置,S端顶多能收到最后一条离线消息,之前的全部都会丢失,mqtt自身并不像activemq那样支持持久化,而是所有东西都存在内存中,所以要求你的使用场景,需要在"互联"的基础下

• clearSession如果是false,代表不会再服务端清除topic的信息,根据信息量的大小,某段时间后肯定会爆内存,所以这个需要用逻辑去规避,具体看业务

• retain默认是false,如果设置为true会推送离线状态下的最后一条消息,之前的离线消息是没有的?..应该是的

• 类似的场景,可能是天气预报/银行的扣款后的余额通知/升级包推送等等,总之是,最后一条信息才是关键(最后一条天气预报是最新的,最后一条余额是最新的,最后一条升级包推送是最新的),之前离线消息即使丢失也没有多大关系的这种场景.

• 遗言will的用法,让你知道在哪个地方mqtt断开了,你可以采取对应的措施,毛措施?火化?

• mqttConnectOptions.setMaxInflight(10),这个默认是10,太小了点吧…直接设置成1000不会打我吧…

• **因为mqtt是非常轻量化的一个协议,还是具有一些优势.**特别是用在硬件终端上面,处理消息非常快,本来现在的硬件厂商就喜欢偷工减料虚标处理器性能…mqtt本身占用内存非常小…

• 如果真的需要持久化每一条信息,最好别用这个mqtt,但如果非要用的话是否可以在p端推送的时候让服务器保存一条msg到mysql/redis,然后在S端callback的时候响应某个标志给服务器消费了,没消费到的定时推…这种笨方法貌似也行啊…(说到底我还是喜欢rabbitMq和activeMq啊…),activemq也支持mqtt协议额…,如果给activemq配置持久化,使用jmsTemplate去发送接收消息,就不会有这么多问题,但是肯定不轻了

• 附上一张S/P/qos/session/retain关系图