CC防护中请求排队与优先级确保核心业务

CC攻击的可怕之处不在于流量有多大，而在于它用极小的代价就能耗尽服务器的连接资源。一台普通攻击机发起的CC攻击，每秒可以产生数千个HTTP请求，这些请求看似正常，却能让后端数据库反复执行昂贵查询，最终导致正常用户无法建立连接。真正有效的防御不是简单的拦截，而是在应用层建立一套请求排队与优先级调度机制，让核心业务请求在任何情况下都能被优先处理。

请求排队本质上是在服务器前端建立一个有秩序的处理队列，将突发的大量请求从“并发竞争”模式转变为“有序等待”模式。当请求量超过系统处理能力时，多余的请求不会立即丢弃，也不会全部涌入后端造成雪崩，而是进入队列等待。这个机制配合优先级策略，就能确保即使队列排满，高优先级的核心业务请求也能插队到前列，获得处理资源。

请求排队机制通常部署在反向代理层或网关层，利用共享内存或高性能内存数据库来维护队列状态。以Nginx为例，可以通过limit_req模块配合Lua脚本实现智能排队。当请求到达时，系统首先判断当前后端连接池的可用数量，如果可用连接数低于阈值，新请求进入队列而非直接转发。队列采用令牌桶或漏桶算法控制出队速率，保证后端压力始终可控。

具体实现时，队列的数据结构选择至关重要。简单的FIFO队列虽然公平，但无法体现业务优先级。更合理的做法是采用多级队列，每个优先级对应一个独立队列，调度器按照权重轮询从各级队列中取出请求。高优先级队列的权重设置得更大，确保其请求能更快被处理。这种设计在电商秒杀场景中特别有效，下单支付的请求优先级远高于浏览商品详情的请求。

优先级不是简单的一个数字，而是一套多维度的评估体系。最基础的维度是用户身份，已登录用户高于匿名用户，VIP会员高于普通用户。更深入的维度包括请求路径，涉及交易、支付的API接口优先级最高，静态资源请求优先级最低。还可以结合用户行为特征，短时间内有加购、收藏等意图行为的用户，其后续请求应获得更高优先级。

在实际部署中，优先级标记通常在网关层完成。网关解析请求后，根据预设规则为请求打上优先级标签，这个标签随请求一起进入排队系统。一个典型的规则配置可能是：/api/order/路径下的请求标记为P0最高优先级，/api/product/路径标记为P1中等优先级，/static/下的静态资源标记为P3最低优先级。同时结合Cookie或Token中的用户等级信息，对同一路径下的请求再做优先级微调。

队列不是无限大的，过大的队列会导致请求超时，用户体验反而更差。队列容量需要根据业务容忍度和服务器内存资源来设定。一般建议队列最大等待时间不超过5秒，超过这个时间的请求应该直接返回降级响应，而不是让用户无限等待。降级响应可以是静态的“系统繁忙”页面，也可以是根据请求类型返回的缓存数据。

这里有一个关键设计：当队列接近满载时，不能简单地拒绝所有新请求，而应该根据优先级做选择性接收。高优先级请求即使在队列高位时仍然可以入队，挤掉队尾的低优先级请求。这种“优先级抢占”机制保证了核心业务在极端情况下的可用性。实现时可以用Redis的Sorted Set来维护队列，优先级分数高的请求自动排在前面，队列满时直接移除分数最低的元素。

以下是一段简化但可运行的Nginx+Lua实现，展示了请求排队与优先级调度的核心逻辑：

-- 在nginx.conf的http块中配置共享内存
-- lua_shared_dict queue_dict 100m;
-- lua_shared_dict conn_pool 10m;

local redis = require "resty.redis"
local cjson = require "cjson"

-- 获取当前后端连接数
local function get_current_connections()
    local red = redis:new()
    red:set_timeout(1000)
    local ok, err = red:connect("127.0.0.1", 6379)
    if not ok then
        return 999 -- 连接失败时保守处理
    end
    local conn_count, err = red:get("backend:active_connections")
    red:set_keepalive(10000, 100)
    return tonumber(conn_count) or 0
end

-- 计算请求优先级
local function calculate_priority()
    local uri = ngx.var.uri
    local priority = 3 -- 默认最低优先级
    
    -- 路径优先级映射
    if string.match(uri, "^/api/order") or string.match(uri, "^/api/pay") then
        priority = 0
    elseif string.match(uri, "^/api/user") then
        priority = 1
    elseif string.match(uri, "^/api/product") then
        priority = 2
    end
    
    -- 用户等级加成
    local user_level = ngx.var.cookie_user_level or "0"
    user_level = tonumber(user_level)
    if user_level and user_level > 0 then
        priority = math.max(0, priority - user_level)
    end
    
    return priority
end

-- 请求入队
local function enqueue_request(priority, max_wait_time)
    local queue_key = "request:queue"
    local red = redis:new()
    red:set_timeout(1000)
    local ok, err = red:connect("127.0.0.1", 6379)
    if not ok then
        return false
    end
    
    local request_id = ngx.var.request_id or ngx.now() .. ngx.var.remote_addr
    local score = priority * 1000000 + ngx.now() -- 优先级越高分数越小，同优先级按时间排序
    local request_data = cjson.encode({
        id = request_id,
        uri = ngx.var.uri,
        method = ngx.var.request_method,
        headers = ngx.req.get_headers(),
        timestamp = ngx.now()
    })
    
    red:zadd(queue_key, score, request_data)
    
    -- 检查队列长度，超过阈值移除最低优先级请求
    local queue_len = red:zcard(queue_key)
    if queue_len > 1000 then
        red:zremrangebyrank(queue_key, -1, -1) -- 移除分数最大的（优先级最低的）
    end
    
    red:set_keepalive(10000, 100)
    return true
end

-- 主处理逻辑
local max_connections = 500
local current_conn = get_current_connections()

if current_conn >= max_connections then
    local priority = calculate_priority()
    local enqueued = enqueue_request(priority, 5)
    
    if enqueued and priority <= 1 then
        -- 高优先级请求排队等待
        ngx.sleep(0.5) -- 短暂等待后重试
        -- 实际应用中这里应该轮询检查队列位置
        ngx.status = 202
        ngx.say(cjson.encode({code = 202, message = "请求已排队，请稍后重试"}))
        return ngx.exit(202)
    else
        -- 低优先级请求直接降级
        ngx.status = 503
        ngx.say(cjson.encode({code = 503, message = "系统繁忙，请稍后再试"}))
        return ngx.exit(503)
    end
end

-- 正常处理请求
ngx.var.backend_connection_increment = 1

这段代码展示了排队机制的核心骨架。在实际生产环境中，还需要补充队列消费逻辑、超时处理、分布式锁等模块。队列消费通常由独立的定时任务完成，按照优先级顺序从Redis Sorted Set中取出请求，转发到后端服务，同时更新连接计数。

单机排队在分布式架构中会失效，因为攻击流量可能从多个入口涌入。分布式排队需要引入中心化的队列服务，Redis Cluster或etcd都可以胜任。关键是要保证连接计数的全局一致性，避免多个网关节点同时认为后端有空闲连接而超发请求。可以采用Redis的原子操作INCR/DECR来维护全局连接计数器，配合Lua脚本实现检查与入队的原子性操作。

另一个常见问题是队列的脑裂。当Redis主节点故障发生切换时，队列数据可能丢失。解决方法是采用双写机制，队列数据同时写入Redis和本地共享内存。Redis恢复后，从本地共享内存回放未处理的请求。同时，队列的设计要容忍少量请求丢失，因为排队中的请求本身就处于未确认状态，客户端应当具备重试能力。

静态的优先级规则在复杂攻击面前不够灵活。攻击者可能伪装成高优先级请求路径来绕过限制。因此需要引入动态优先级调整机制，结合实时行为分析来修正请求的优先级。例如，某个IP短时间内请求频率异常，即使它访问的是高优先级路径，也应该被降级处理。反之，检测到用户正在进行支付操作时，可以临时提升其后续请求的优先级。

自适应阈值同样重要。固定的最大连接数在服务器性能波动时可能不是最优值。可以通过监控后端的响应时间和CPU负载，动态调整入队阈值。当后端响应时间增加时，主动降低入队速率，给后端喘息空间。这种反馈控制机制类似于TCP的拥塞控制，通过持续监测和调整，找到系统吞吐量的最优平衡点。

排队机制部署后，必须建立完善的监控体系来评估效果。核心指标包括：队列深度随时间的变化曲线、各优先级请求的平均等待时间、降级请求的比例、后端连接池利用率。当队列深度持续增长时，说明后端处理能力不足，需要扩容或优化。当高优先级请求的平均等待时间超过阈值时，说明优先级策略可能需要调整权重。

实际效果可以通过压测来验证。模拟正常用户和高频攻击混合的流量，观察核心业务的可用性。一个设计良好的排队系统，在遭受5倍于正常流量的CC攻击时，核心业务的响应时间增幅不应超过50%，成功率应保持在99%以上。而非核心的浏览类请求可以接受部分降级，但完全不可用的比例也应控制在10%以内。

请求排队不是孤立的安全机制，需要与WAF、IP黑名单、验证码等传统防御手段配合。最外层由WAF过滤明显的恶意请求，IP黑名单拦截已知攻击源，验证码挑战可疑会话。经过这些前置过滤后，剩余的请求进入排队系统，按优先级调度。这种分层防御体系将不同粒度的防护手段组合起来，形成纵深防御。

排队系统还可以与业务限流策略联动。例如，秒杀活动期间，对商品详情页的请求实施宽松限流，对下单请求实施严格限流但给予最高排队优先级。这样既能控制后端压力，又能保证真正有购买意愿的用户完成交易。这种业务感知的防护策略，比单纯的IP限流或连接数限制更加精准有效。

请求排队与优先级调度这套机制，本质上是在承认资源有限的前提下，通过精细化的资源分配来保障核心业务的连续性。它不是要挡住所有攻击流量，而是要确保在任何情况下，最重要的业务请求都能得到响应。这种思路比追求绝对防御更加务实，也更能适应复杂的真实网络环境。