因为对surgemq的研究发现qos>0没有重发功能，然后去看了MQTT协议文档，在qos>0的情况下，服务端确实也需要实现重发，而且还必须保证顺序。
虽然tcp一般情况下保证不丢包，但是服务端在超时时间内没有收到客户端的publish ack时也需要重发publish消息。
4.4 消息分发重试 Message delivery retry
客户端设置清理会话（CleanSession）标志为0重连时，客户端和服务端必须使用原始的报文标识符重发任何未确认的PUBLISH报文（如果QoS>0）和PUBREL报文 [MQTT-4.4.0-1]。这是唯一要求客户端或服务端重发消息的情况。
非规范评注
控制报文的重发曾经需要克服某些陈旧TCP网络上的数据丢失问题。部署在那些环境中的MQTT 3.1.1实现可能仍然需要关注这个问题。4.6 消息排序 Message ordering
实现本章定义的协议流程时，客户端必须遵循下列规则：
重发任何之前的PUBLISH报文时，必须按原始PUBLISH报文的发送顺序重发（适用于QoS 1和QoS 2消息）[MQTT-4.6.0-1]。
必须按照对应的PUBLISH报文的顺序发送PUBACK报文（QoS 1消息）[MQTT-4.6.0-2]。
必须按照对应的PUBLISH报文的顺序发送PUBREC报文（QoS 2消息）[MQTT-4.6.0-3]。
必须按照对应的PUBREC报文的顺序发送PUBREL报文（QoS 2消息）[MQTT-4.6.0-4]。
服务端必须默认认为每个主题都是有序的。它可以提供一个管理功能或其它机制，以允许将一个或多个主题当作是无序的 [MQTT-4.6.0-5]。
服务端处理发送给有序主题的消息时，必须按照上面的规则将消息分发给每个订阅者。此外，它必须按照从客户端收到的顺序发送PUBLISH报文给消费者（对相同的主题和QoS）[MQTT-4.6.0-6]。
非规范评注
上面列出的规则确保，使用QoS 1发布和订阅的消息流，订阅者按照消息发布时的顺序收到每条消息的最终副本，但是消息可能会重复，这可能导致在它的后继消息之后收到某个已经收到消息的重发版本。例如，发布者按顺序1,2,3,4发送消息，订阅者收到的顺序可能是1,2,3,2,3,4。
如果客户端和服务端能保证任何时刻最多有一条消息在 传输中（in-flight）（在某条消息被确认前不发送后面的那条消息），那么，不会有QoS 1的消息会在它的任何后续消息之后收到。 例如，订阅者收到的顺序可能是1,2,3,3,4，而不是1,2,3,2,3,4。将传输窗口（in-flight window）设为1意味着，在同一个主题上，即使发布者发送了一系列不同QoS等级的消息，它们的顺序也被保留。
这篇文章关于重发和消息排序写的不错： MQTT协议笔记之消息流