流控机制是什么
配额和流控是MQTT产品重要的服务保障机制。其主要目的是在租户集群配额或用户自定义单个会话配额耗尽时，对客户端的请求进行限制，防止服务因过载而出现资源耗尽、性能陡降甚至崩溃等影响服务可用性的情况。在 MQTT 服务中，流控通常作用于客户端的连接、消息发布、消息订阅等行为。比如当服务端检测到某个客户端的发布流量超过单个会话配额，或者租户集群整体超过实例配额时，就会触发流控机制。
本文档将详细说明消息队列 MQTT 版中如何根据消息 QoS 等级、客户端协议版本来实施差异化、精细化的流控策略。通过流控机制能够确保系统在压力场景中能够最大限度地保证服务可用性，同时为不同版本的客户端提供反馈机制。
实现原理
为保护客户业务连续性，消息队列 MQTT 版对生产端上行流量实施了基于QoS等级和客户端协议版本的精细流控。核心策略是：优先保障高等级消息，快速限制低等级消息，并通过差异化反馈机制优雅通知客户端，实现可用性与可靠性的平衡。
QoS 0消息
流控原则
当客户端发布 QoS 0 消息速率超过配额时，服务端会直接丢弃超额的 QoS 0 消息发布。
说明：
QoS 0 的本质是“至多一次”交付，它本身不提供任何可靠性保证，消息可能因网络问题等原因丢弃。客户端在协议层面不应期望其被可靠投递。业务侧如对 QoS 0 有低丢失容忍度，应结合监控与重发策略等手段为此类风险做出准备。
QoS 1消息和 QoS 2消息
对于 QoS 1（AT-LEAST-ONCE）和 QoS 2（EXACTLY-ONCE）消息，我们的处理策略更为谨慎，并且会根据发送消息客户端的协议版本进行区分，以提升服务质量。
MQTT v3.1 和 v3.1.1 客户端
流控原则
利用 TCP 协议的反压机制进行流控。 MQTT Server 在单个 MQTT 会话或者租户集群超出配额时，将暂停读取该TCP连接的入站数据，直到获得配额后再次读取TCP Recv-Q中数据；客户端Publish报文在流控时，将缓冲在客户端应用层Buffer 或 TCP Send-Q中。
操作流程
1. 服务端从 MQTT 会话中读取一个 Publish报文。
2. 尝试获取该会话或者租户集群处理配额；如果配额已经耗尽，暂停从 TCP Recv-Q读取数据，设置定时任务，待下一个配额分配窗口获取配额；
3. 当获取到足够配额处理已读取到 MQTT 会话的报文后，再次开启 TCP Recv-Q读取流程。
警告：
1. TCP 反压流控期间，无法及时读取到客户端发送的 Keep-Alive 报文，如果租户实例严重超过配额，可能导致客户端因 keep-alive 超时断连；
2. 流控期间，尽量保证处理窗口内高 QoS 优先获取配额处理、丢弃 QoS 0 Publish 报文，但无法保证绝对优先；
3. 流控期间，存在等待获取配合配，处理发布报文请求会有额外延迟。
MQTT v5.0 客户端
流控原则
服务端会向客户端发送PUBACK/PUBREC报文，并在报文中使用协议定义的 Reason Code 0x97 明确通知Quota Exceeded, 应用开发者需处理对应异常、errno, 比如根据业务要求稍后进行重试。
原因码 | 名称 | 报文 | 说明 |
0x97 (151) | Quota Exceeded（配额超限） | PUBACK, PUBREC | 用于指示配额已超限。服务端根据集群规格限制发布者的发送配额，当发布者超出配额时，服务器会在确认数据包（例如 PUBACK、PUBREC）中使用此原因代码来提醒发布者。 |
说明：
对于下行流量流控机制，即 MQTT 服务端对客户端订阅的消息主动推送配额机制。为保证已发布消息处理的及时性和客户使用体验，我们提供有限的“Burst”服务: 服务端允许在瞬时小幅超过配额的情况下继续完成本批次推送。
