Mqtt精髓系列之系统健壮性

翻译：https://www.hivemq.com/blog/are-your-mqtt-applications-resilient-enough/
　　Mqtt协议已经提供了一些特性来保证系统的健壮性，但是这还不够，有些特性仍需要应用来实现，如下图所示：

Automatic Reconnect（断连重试）

1. 如果连接出现异常，客户端应该按照一定重试策略尝试重新连接；
2. 如果客户端由于没有权限，导致连接被断开，则不应该进行重试；

Offline Buffering（离线缓冲）

　　客户端应该具备离线缓冲的能力，以便连接异常时，能够缓存一定量的消息，避免让上层业务的感知。

We have seen, that the MQTT broker queues messages for a persistent session client when using QoS 1 and 2 messages if the client was offline. This happens solely on the broker side. In case the MQTT connection of your application is not present, it may be desirable to have offline buffering capabilities implemented on the client side so the application can send out all messages that were queued while the connection was not present. This is especially important if your clients application architecture abstracts the MQTT transport layer away from the business logic layer. MQTT message offline buffering makes your application more resilient, since the connection loss is not intrusive to your application layer.

Throttling（限流）

　　当客户端每秒接受的消息量超过自己的处理能力时，客户端应该具备自动限流的能力，比如停止从Socket中读取数据，或者直接丢弃数据等，避免客户端出现宕机的情况；

Most MQTT client applications are not designed for handling huge amounts of MQTT messages per second. It’s important to know your client’s load limitations and then throttle the message ingestion rate to a limit that doesn’t overwhelm your client. Such an implementation typically stops to read from the socket as soon as a specific bytes per second or messages per second rate threshold is exceeded. So even if the broker tries to send lots of messages, TCP backpressure mechanisms take effect and your client won’t be overwhelmed. If this is not possible with your client library, you should think about implementing load shedding, which means you throw away messages that you can’t handle. This is not optimal but certainly better than constantly crashing your client.

Input Validation（输入校验）

1. Topic校验：接受消息的Topic是否是订阅的Topic;
2. 消息体校验：消息内容的格式是否符合预期等；