预警通知限流与并发控制：合理规划发送节奏

告警洪峰要让重要告警先发

一次核心交换机故障可能瞬间触发上百条告警：每台服务器的CPU、磁盘、监控探针都同时报警，监控页面红成一片。如果不加控制地向预警通知API并发发送，短时间大量请求可能被限流，真正重要的P0告警反而排在后面发不出去。合理的限流与并发控制，是让重要告警先发、次要告警延后的关键。互亿无线预警通知API支持24小时发送，但调用方需要自行规划发送节奏，把通道资源留给高优先级事件。

本文说明告警发送队列的设计、并发数控制和优先级调度做法。

本地发送队列与并发数

在自己的告警服务中维护一个发送队列，用线程池或协程控制并发数，避免同时打出过多请求：

import queue, threading

send_queue = queue.Queue(maxsize=1000)

def worker():
    while True:
        item = send_queue.get()
        try:
            do_send(item)
        finally:
            send_queue.task_done()

for _ in range(5):
    threading.Thread(target=worker, daemon=True).start()

工作线程数量即并发数，建议从较小值起步，根据接口响应情况逐步调整。队列满时，低优先级告警可直接丢弃或合并，避免内存堆积。

按告警优先级调度

并非所有告警都要立刻发送，可按等级划分发送节奏：

限流的工程做法

除了并发数，还要控制单位时间发送量。常见做法有：

1. 令牌桶限速：每秒放出固定数量的发送令牌，平滑洪峰，避免瞬时打爆通道。
2. 告警合并：同一对象短时间多条同类告警合并为一条汇总通知。
3. 静默窗口：故障恢复前对同一告警只通知一次，避免重复轰炸值班人员。
4. 夜间降级：非紧急P3告警在夜间汇总到次日处理，减少打扰。

限流与告警分级配合的实例

假设一个电商大促期间，订单接口偶发超时触发告警。如果不做限流，几秒内可能发出上百条短信。合理的做法是：P0级别的"支付通道完全不可用"直接插队发送，走三合一；P1级别的"部分订单超时"进入队列匀速发送；P3级别的"单台机器响应慢"合并到每5分钟汇总一次。值班人员在大促期间只收到关键的几条，而不是被海量告警淹没。互亿无线支持24小时发送，套餐无有效期，洪峰过后余量仍可继续使用。

并发数如何取值

并发数不是越大越好。建议从3到5个并发起步，观察接口响应时间和成功比例，再逐步上调。如果发现响应变慢或出现限流提示，就适当调低。同时在本地记录每个并发槽位的发送耗时，找出瓶颈是网络还是接口处理。

夜间与节假日策略

夜间和节假日的告警处理意愿低，建议把非紧急P3告警自动降级，合并到工作时间再通知，避免打扰休息。但P0、P1不受此限，仍然多通道即时发送。这样既守住了关键故障的响应速度，又减少了不必要的夜间打扰。

限流阈值的观察

上线后观察一周，记录每分钟发送量与成功比例。如果洪峰时经常堆积，就调高并发或提前扩容套餐；如果整体发送量很小，则不必过度设计，简单队列即可。

小结

限流与并发控制的目标不是慢，而是让重要告警先到。配合去重、合并和分级，通道资源会用在刀刃上。

实际运行中，建议每周回顾一次发送量曲线，看哪些时段出现堆积，再据此调整并发与合并窗口，让节奏更贴合自己业务的告警规律。

长短信按多条计费，批量告警时要关注费用，套餐无有效期可按需抵扣。互亿无线按成功计费，未成功发送不计费，配合本地限流可在成本与时效间取得平衡。合理规划发送节奏后，重要告警能及时触达，次要告警不会挤占通道。注册免费试用，领取测试条数后即可压测自己的发送队列与限流策略。