Workerman onMessage频率限制实现方法

在Workerman多进程环境下，直接使用PHP变量或文件进行onMessage频率限制完全失效，根本原因在于进程内存隔离导致计数无法共享；真正可靠且生产可用的方案是借助Redis的INCR+EXPIRE原子操作实现IP或用户维度的秒级/分钟级限流，同时必须复用pconnect持久连接、预初始化Redis实例，并做好超时容错与标识安全提取（如WebSocket中在onConnect解析token、JSON消息中严格校验结构），才能兼顾高性能、高准确率与系统稳定性——这不仅是技术选型问题，更是避免被恶意刷量击穿服务的关键防线。

Workerman 的 onMessage 里直接加计数器为什么不行

因为 Workerman 是多进程模型，每个 worker 进程有独立内存空间。你在 onMessage 里用 PHP 变量（比如 $count++）计数，只在当前进程生效，其他进程完全感知不到——用户换一个连接就重置，限流形同虚设。

常见错误现象：var_dump($this->count) 看起来在涨，但压测时限制完全失效；或者重启 worker 后计数清零，但你以为“应该持久”。

• 不要用类属性或全局变量存计数，进程隔离会让它变成“每人一把算盘”
• 不要依赖 file_put_contents + file_get_contents 做简单文件计数——高并发下会丢数据、锁冲突、IO 拖垮性能
• 真正可用的方案只有两类：外部共享存储（Redis 最常用），或内核级原子操作（如 pcntl_fork 配合共享内存，但太重，不推荐）

用 Redis 实现每 IP 每秒最多 5 次请求（onMessage 中实操）

这是最稳妥、上线项目实际用的方案。核心是用 Redis 的 INCR + EXPIRE 组合，保证原子性和自动过期。

使用场景：防止恶意刷登录、重复提交、爬虫高频探测；注意别用在毫秒级强实时限流（Redis 网络 RTT 会引入误差），但对“秒级”“分钟级”足够准。

• 键名建议格式："rate:ip:{$_SERVER['REMOTE_ADDR']}:{date('YmdHi')}"（按分钟切片，避免 key 过多）或更简单的 "rate:ip:{$_SERVER['REMOTE_ADDR']}:1s"（配合 EXPIRE 1）
• 必须用 pipeline 或 Lua 脚本保证 INCR 和 EXPIRE 原子执行，否则可能计数成功但没设过期，key 泄漏
• 示例逻辑（需提前 new 好 $redis 实例）：

public function onMessage($connection, $data)
{
    $ip = $_SERVER['REMOTE_ADDR'];
    $key = "rate:ip:{$ip}:1s";
    $redis = $this->redis; // 已初始化的 Redis 连接

    // 原子递增并设置过期（Lua 更可靠，此处为简化示意）
    $count = $redis->incr($key);
    $redis->expire($key, 1);

    if ($count > 5) {
        $connection->close('Too many requests');
        return;
    }

    // 正常处理...
}

Redis 连接不能在 onMessage 里每次 new（性能/连接数坑）

Workerman 每秒可能处理成百上千消息，如果每次 onMessage 都 new Redis() 或 connect()，会快速打爆 Redis 连接数，同时 TCP 握手开销让延迟飙升。

参数差异：Redis::class 默认是短连，Predis\Client 可配长连但需手动管理；Workerman 官方推荐用 phpredis 扩展 + 连接池（但原生不带池，得自己封装）。

• 正确做法：在 Worker 构造或 onWorkerStart 里初始化 Redis 实例，并复用（$this->redis = new Redis(); $this->redis->pconnect(...)）
• 务必用 pconnect（持久连接），避免反复建连；如果 Redis 在远端，记得调大 connect_timeout 和 read_timeout
• 如果 Redis 故障，onMessage 里不能卡死——加超时和 try/catch，失败时默认放行（宁可漏限，不可挂服务）

除了 IP，还能按用户 ID 或 Token 限流（onMessage 中提取依据）

很多场景要的是“每个登录用户每分钟最多 10 次”，不是按 IP。关键在于：你得从 $data 里安全提取标识，且不能假设格式固定。

容易踩的坑：直接 json_decode($data) 不校验结构，遇到非法 JSON 就 fatal error；或从 header 取 token 却忽略 WebSocket upgrade 后的 header 不可用问题。

• WebSocket 场景下，token 通常在握手阶段通过 Upgrade 请求头传入，需在 onConnect 里解析并存到 $connection->token，onMessage 中直接读
• 如果是普通 JSON 消息，先 if (is_string($data) && $json = json_decode($data, true)) { $uid = $json['uid'] ?? null; }，永远做非空和类型检查
• 键名改用："rate:uid:{$uid}:60s"，过期时间设为 60 秒，INCR 后立刻 EXPIRE

复杂点在于：同一个用户可能开多个连接，你得确保所有连接都写同一个 key；而 IP 限流天然聚合，用户限流得靠业务标识的稳定提取——这步做错，后面全白搭。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~