企业微信机器人高并发发送消息避免限流，最推荐的设计方向是引入消息队列配合速率限制器，适用于业务发送频率超过官方 API 阈值的场景，主要风险边界是消息实时性会因队列堆积而产生延迟。
先说结论：通过消息队列削峰填谷，并在消费端实施令牌桶限流，是解决企业微信机器人 API 频率限制的标准方案。
- 先定位：确认业务日志中是否频繁出现频率限制错误码（如 45009）。
- 先做：在发送服务与企业微信 API 之间接入消息队列，消费端增加速率控制逻辑。
- 再验证：观察高并发场景下错误码是否消失，且消息最终送达率是否符合预期。
快速处理思路
不适合直接使用单条命令解决，需调整架构链路。业务服务不再同步调用企业微信接口，而是将消息写入消息队列（如 Kafka、RabbitMQ 或 Redis List）。独立的消息消费服务从队列读取消息，内置速率限制器（如令牌桶算法），按照企业微信官方允许的频率发送请求。若发送失败触发限流，消费服务执行指数退避重试，并将消息暂存回队列或死信队列。
为什么会这样
企业微信机器人 API 设有严格的频率限制，超过阈值会直接返回错误。当并发请求量瞬间超过官方规定的频率上限，接口会返回频率限制错误码，导致消息发送失败。公开资料中没有看到可靠的量化数据说明具体 QPS 阈值随账号权重的变化，但触发限流是确定性行为。同步发送模式下，前端业务线程会因等待 API 响应或处理错误而阻塞，进一步降低系统吞吐量。
分步处理
第一步：接入消息队列
在业务代码中，将原本直接调用 HTTP 发送消息的逻辑，改为生产消息到队列。配置片段示例（伪代码）：queue.push({content: msg, retry: 0})。检查点：确认消息写入队列的成功率接近 100%，写入耗时在毫秒级。
第二步：消费端实施限流
消费服务启动时初始化速率限制器，设定最大发送速率。逻辑示例：每次发送前获取令牌，若无令牌则等待或暂缓消费。风险边界：限流阈值需参考企业微信开发者文档最新公告，设置过低会导致队列堆积，设置过高仍会触发限流。
第三步：配置重试策略
捕获 API 返回的错误码，若为频率限制错误，执行指数退避等待（如 1s, 2s, 4s...）。若重试次数超过上限，将消息转入死信队列人工处理。回滚提醒：重试逻辑需包含最大重试次数限制，避免无限重试导致资源耗尽。
怎么验证是否生效
查看应用日志，搜索企业微信 API 返回的错误码。若限流生效，日志中应不再出现频率限制错误码（如 45009）。监控消息队列长度，高并发期间队列长度应平稳上升后下降，而非无限堆积。检查业务侧消息送达状态，确认最终送达率无明显下降。
常见坑
消息丢失风险：消费者宕机可能导致内存中消息丢失，需开启队列持久化或手动 ACK 机制。
消息顺序错乱：并发消费可能导致消息顺序与业务发生顺序不一致，若业务强依赖顺序，需使用单分区队列或序列号校验。
重试风暴：限流解除瞬间大量重试请求同时发出，可能再次触发限流，需在重试逻辑中加入随机抖动时间。
常见问题
遇到 45009 错误码代表什么？
代表频率限制，说明单位时间内发送请求次数超过官方允许上限。
Redis 和 Kafka 选哪个做队列？
消息量较小且追求低延迟选 Redis List，消息量大且需高可靠持久化选 Kafka。
限流阈值应该设为多少？
具体频率阈值需参考官方文档最新公告，建议初期设置为保守值，根据错误码监控动态调整。
参考来源
- 企业微信开发者文档 - 群组机器人接口说明
- 企业微信开发者文档 - 全局错误码说明