# TPS 达到限制告警处理指南

TPS 达到限制告警表示 EMQX Cloud 部署在过去 30 分钟内处理的 MQTT 上行与下行消息数量，超过了当前部署规格所允许的 TPS 上限。

该情况通常意味着当前消息吞吐量已达到部署规格上限。对于超过 TPS 限制的消息，系统可能会进行丢弃，从而对业务产生影响。常见问题包括业务高峰期消息突增、客户端异常导致发布速率过快，或订阅规模扩大引发的消息分发量激增。

## 消息在短时间内突增

### 问题描述

在业务高峰期或批量任务触发时，客户端可能在短时间内集中发布大量消息，导致消息 TPS 短时超过部署规格上限，从而触发告警。

在部署**概览** 页面中，如果观察到消息上下行 TPS 高于部署规格限制，并且在**监控** -> **指标** -> **时间轴** -> **消息流入流出** 中出现明显的异常峰值，则通常符合此类情况。

### 常见原因

- 业务高峰期集中发布消息。  
- 批量任务或定时任务在短时间内触发。  

### 处理方法

- 提前根据业务规模评估消息量峰值。  
- 在高峰期到来前对部署进行扩容，以满足更高的吞吐需求。  

## 客户端发布速率过快

### 问题描述

部分客户端未进行发布速率控制，在极短时间内持续高速发布消息，可能导致单个客户端占用过多 TPS 资源，从而引发整体 TPS 达到限制告警。

在部署**概览**页面中，如果消息上下行 TPS 高于部署规格限制，可进一步查看部署（（日志**，检查是否存在客户端发布速率超过限制而被丢弃的相关日志。

结合日志中获取的 `clientid` 信息，在**监控** -> **客户端**页面中查看对应客户端的消息指标。如果发现单个客户端的消息发布量远超预期，则通常符合此类情况。

### 常见原因

- 客户端逻辑异常，导致同一条消息被重复发送。  
- 客户端未实现发布速率限制机制。  

### 处理方法

- 检查客户端逻辑，避免同一条消息被重复发送。  
- 在客户端侧加入发布速率限制机制，防止过快的消息发布对系统造成冲击。  
- 提交工单联系 EMQX Cloud 技术支持人员，可在后台调整监听器上单个客户端的发布速率限制。  

## 订阅客户端数量或订阅范围增加

### 问题描述

当订阅客户端数量明显增加，或客户端订阅了更多主题（尤其是使用 `#` 或 `+` 等通配符的主题）时，消息分发范围会显著扩大。此时，每条上行消息将被转发给更多的订阅者，从而显著增加下行消息数量，并可能导致平均 TPS 达到或超过部署规格上限。

在**监控** -> **指标**页面中，如果观察到消息流出明显高于消息流入，且整体 TPS 超出部署规格限制，可进一步结合**订阅数**与**客户端连接数**的变化趋势进行判断。

### 常见原因

- 新增大量订阅客户端。  
- 客户端订阅了更宽泛的主题范围。  
- 滥用通配符订阅导致消息分发范围过大。  

### 处理方法

- 检查近期是否新增了客户端或订阅主题。  
- 优化主题设计，避免不必要的通配符订阅。  
- 对订阅量大或消息分发密集的业务进行分流，或考虑升级至更高规格的部署以承载负载。  

## 排查步骤

1. 登录 EMQX Cloud 控制台。

2. 打开**监控** -> **告警** -> **告警列表**，确认是否存在 TPS 达到限制告警，并查看其触发时间段与影响范围。若过去 30 分钟内的平均 TPS 超过部署规格允许的最大 TPS，则会触发该告警。

   ![tps_limit_alerts](./_assets/tps_limit_alerts.png)

3. 打开**监控** -> **客户端** 页面，查看单个客户端的消息指标。如果发现某个客户端接收或发送的 PUBLISH 报文数量明显高于预期，则可能属于**客户端发布速率过快**场景。
   
   ![tps_limit_client](./_assets/tps_limit_client.png)

## 监控与统计

在 EMQX Cloud 控制台的**指标** -> **时间轴** -> **消息流入流出**中，可以查看基于时间轴的整体消息数量趋势。通过某一时间节点的总消息数除以 60 秒，可以计算该时间点的每分钟平均 TPS 值。

如需获取一段时间范围内更详细的部署消息 TPS 数据，也可以提交工单联系 EMQX Cloud 技术支持人员协助获取。

![tps_limit_monitor](./_assets/tps_limit_monitor.png)

## 告警影响说明

- TPS 达到限制告警触发后，部署不会停止服务，也不会因此产生额外计费。  
- 当 TPS 持续超过部署规格上限时，超过限制的消息可能会被丢弃，从而对业务产生实际影响。  
- 若业务长期需要更高的消息吞吐能力，建议提前规划并提升部署规格，以确保系统稳定运行。