使用redis限流

接上回。
宝塔waf挂了后继续排查。通过对比宝塔的日志以及mysql日志，结论是，后端负荷过高引起宝塔waf回源超时，因为宝塔在回源时使用了较短的生存探测超时时间，在大负荷后端响应慢的情况下，所有后端节点全部被宝塔剔除，于是，从响应缓慢变成了502彻底挂了。
解决办法，第一点，当然是把宝塔去掉了，生产环境不敢再用这种免费的玩具了。
第二点，增强mysql的处理能力。以前没注意到云服务商其实提供了mysql的弹性伸缩产品，以前的mysql固定2c，用这个产品可以最高拉到32c，按小时计费而已。下次活动前拉满了。不做广告，不说具体谁了。
第三点，也是最关键的，限流。再优化再高的qps能力，也不过是让外挂们抢得更快并发更高而已。系统处理能力提高1倍，他们可以轻松的提高10倍抢单能力。所以，崩溃是永恒的，不管怎么优化。限流就唯一的办法了。
这几天，每天都是与ai肉搏。毕竟是成熟的算法，想来ai写得会比自己写更好。从固定窗口到滑动窗口到令牌桶，让几个ai每个都写一次，然后它们同行评测一次然后再服务器实测。
参与的有 chatgpt，元宝(deekseek)，grok, claude。比较意外，它们都写得并不是太好，交叉评议就更搞笑，都是说对方是垃圾到处是bug，自己是100%可靠，然后一实测它的改进版，很可能根本就逻辑错误实现不了需求。因为牵涉到工作的细节，我就不截图等了，我只说结论，这次的测试，grok>元宝>chatgpt>claude。claude平时一直都不错，这次不知道为什么，它写不出来一个可以正常运行的版本，只能排最后。因为测试结果是可以量化的，所以，这个比较也算是量化的结果。是不是有点意外。。。
测试是类似这样的结果，就看谁的数字最接近理论允许的数值。

测试时长: 10 秒
并发数: 300
预期: 10秒内150次请求返回200，其余返回429 (2秒30次)
------------------------------------
等待5秒边界...
开始时间: Tue Mar 18 10:10:25 PM CST 2025
------------------------------------
测试结果统计:
总请求数: 1500
允许的请求 (HTTP 200): 150
限流的请求 (HTTP 429): 1350
每秒平均请求数: 150
每秒平均成功数: 15

老规矩，发代码，有需要的人可以看看。虽然不是我的代码，不过是我在ai写的几十个代码里选出来的，也算是辛苦了。真的是大家说ai那样的，写代码5秒钟，debug代码5小时。
redis lua:

                -- from blog.lostshit.com
        -- 移除时间窗口外的记录
        redis.call('ZREMRANGEBYSCORE', KEYS[1], '-inf', ARGV[1])

        -- 获取当前窗口内请求数
        local current = redis.call('ZCOUNT', KEYS[1], ARGV[1], '+inf')
        if current >= tonumber(ARGV[4]) then
            return 0
        end

        -- 添加新请求记录
        redis.call('ZADD', KEYS[1], ARGV[2], ARGV[5])

        -- 更新过期时间（毫秒精度）
        if redis.call('TTL', KEYS[1]) < (ARGV[3] - ARGV[2])/1000 then
            redis.call('PEXPIREAT', KEYS[1], ARGV[3])
        end

        return 1

不解释了。懂的自然懂，不懂的也不需要懂。