【数据存储】队列积压：消费跟不上时的扩容策略

实战应用：用在哪里

BOSS 击杀高峰每秒产生两百条事件，消费端每秒只能处理一百五十条，队列水位一路涨到八千条，排行榜延迟拖了 600 秒。积压治理三板斧：水位 30 秒一查、超过 5000 条自动扩容双消费者、消化回落到 3000 条以内自动降回单消费，扩缩容全自动。积压治理的经验是消费速率要留五成余量，峰值来临时队列只缓冲不堆积。

水位监控与扩容判定

定时器每 30 秒读一次队列长度，超过阈值就置位扩容标记并给值班发邮件，扩容标记驱动消费端开第二个消费者。

setontimerex(201, 30)
function ontimer201()
    local len = queueLen()
    if len > 5000 then
        setsysvarex("Q_SCALE", 2, 1)
        sendmail("#值班老张", 934, "队列积压告警", "积压 " .. len .. " 条，已扩容双消费者", "")
    end
end

双消费者与自动降容

扩容后两个消费者交错取事件处理，水位回落到 3000 条以内自动关闭二号消费者，降容动作比扩容多一层确认防止水位抖动。

setontimerex(202, 30)
function ontimer202()
    local len = queueLen()
    local scale = tonumber(getsysvar("Q_SCALE") or "1")
    if len < 3000 and scale >= 2 then
        setsysvarex("Q_SCALE", 1, 1)
        sendcentermsg("队列水位回落，恢复单消费者运行")
    end
end

验证与监控

压测灌入每秒两百条持续 600 秒，核对扩容触发、双消费追平水位、回落降容三个阶段；降容后的水位不再反弹；告警邮件单次积压只发一条。水位曲线与生产速率曲线叠加展示，积压原因一眼可辨是生产暴增还是消费变慢。监控队列水位的分钟曲线与扩容次数，一周扩容超过三次说明消费能力需要常态化提升。

踩坑记录

扩容判定没有滞回区间，水位在阈值附近抖动导致一小时升降容十二次，消费端反复启停反而更慢，加上回落确认后才稳定。双消费者没有做事件分片，两个消费者取到同一事件的竞态出现过重复消费，取事件改成按消费者编号分片。告警邮件在持续积压期间每 30 秒一封，值班邮箱被灌爆，告警状态化后同一轮积压只发首次与恢复两条。积压处理期间新功能上线要避开，发布引发的消费抖动会与积压叠加放大。