遇到钉钉机器人消息堆积，最稳妥的办法是在发送端做异步队列和速率限制，而不是盲目增加发送线程。

核心原因与风险

钉钉机器人接口有明确的调用频率限制。自定义机器人 webhook 通常限制为每秒最多发送 20 条消息。当业务高峰期的消息产生速度超过这个阈值，且发送程序没有做排队等待，就会导致请求在本地堆积，或者被钉钉服务端直接拒绝。

技术风险提醒：简单的 sleep 无法在多线程或多实例下精确控制全局 QPS。如果部署了多个服务实例，每个实例都按 20 QPS 发送，总流量会瞬间超标触发封禁。生产环境建议使用令牌桶算法或分布式锁。

生产环境解决方案

1. 确认限流情况
检查你的应用日志，搜索 HTTP 状态码 429 或包含 "too many requests" 的返回内容。如果大量出现，说明已经触发了服务端限流。

# 示例：检查当前发送日志中是否有 HTTP 429 错误
grep "429" send.log | wc -l

2. 引入本地队列与消费者
不要在业务主线程直接调用发送接口。使用 Redis List、RabbitMQ 或 Kafka 将消息先存下来，由独立的消费者进程按速度取出发送。

3. 实现精准速率限制（替代简单 sleep）
在消费者逻辑中加入令牌桶算法。单实例场景可使用 Guava RateLimiter，多实例场景建议使用 Redis + Lua 脚本。

方案 A：Java 单实例限流（Guava）

import com.google.common.util.concurrent.RateLimiter;

// 初始化为 20 QPS
RateLimiter limiter = RateLimiter.create(20.0);

public void sendMsg(Message msg) {
    // 获取许可，会自动阻塞等待直到有配额
    limiter.acquire(); 
    httpClient.post(dingWebhook, msg);
}

方案 B：分布式限流（Redis Lua）
适用于多服务实例共享限流额度的场景，确保全局不超过 20 QPS。

local key = "ding_rate_limit:" .. os.date("%Y%m%d%H%M%S")
local limit = 20
local current = redis.call("INCR", key)
if current == 1 then
    redis.call("EXPIRE", key, 1)
end
if current > limit then
    return 0
end
return 1

4. 异常重试机制
遇到限流错误不要立即无限重试，必须采用指数退避策略。以下是重试代码示例：

int maxRetries = 3;
for (int i = 0; i < maxRetries; i++) {
    try {
        if (sendSuccess()) break;
    } catch (RateLimitException e) {
        if (i == maxRetries - 1) throw e;
        // 指数退避：1s, 2s, 4s...
        long waitTime = 1000 * (long) Math.pow(2, i);
        Thread.sleep(waitTime);
    }
}

多 Webhook 分流策略

如果单 webhook 无法满足业务需求，可以在钉钉机器人管理页面创建多个机器人，获取多个 webhook 地址，在发送端做哈希分流。

具体哈希算法：使用消息特征（如用户 ID 或订单 ID）进行取模，确保同一主体的消息始终发送到同一个机器人，避免顺序混乱。

List webhooks = Arrays.asList("url1", "url2", "url3");
// 基于消息 key 进行一致性哈希
int index = Math.abs(messageKey.hashCode()) % webhooks.size();
String targetUrl = webhooks.get(index);

怎么验证是否生效

主要观察两个指标：一是本地消息队列的长度是否不再持续上涨，二是发送日志中的错误率是否降至接近零。

# 监控队列长度（以 Redis 为例）
redis-cli LLEN your_message_queue

如果队列长度随时间波动但总体可控，且没有大量 429 报错，说明控速生效。同时建议监控 HTTP 响应时间，若耗时突然增加，可能是触发了软限流。

常见坑

1. 重试风暴
遇到限流错误不要立即无限重试，这会加剧堆积。必须采用指数退避策略，比如第一次等 1 秒，第二次等 2 秒。

2. 忽略内容长度
除了频率，钉钉对消息内容长度也有限制。过长的消息会导致发送失败，这部分失败的消息如果不停重试也会占用队列资源。建议在入队前校验内容长度。

3. 单点故障
如果只用一个 webhook，一旦该机器人被禁用或地址泄露，整个通知链路会中断。建议关键业务做好多机器人备份，并配置告警监控。

参考来源

• 钉钉开放平台 - 自定义机器人接入文档 (https://open.dingtalk.com/document/robots/custom-robot-access)
• 钉钉开放平台 - 频率限制说明