Redis 6.0 ACL权限检查本身对吞吐影响极小，瓶颈源于不当配置：多键模式glob遍历、KEYS*等O(N)命令滥用、ACL LOG高频同步写入及动态改权未持久化导致冷启动延迟。
Redis 6.0 的 ACL 权限检查本身对命令执行吞吐量影响极小，但不当配置可能引入可观测的性能衰减——关键不在 ACL 机制本身，而在权限匹配逻辑和滥用模式。
ACL 命令权限检查发生在哪一环
每次命令解析完成后、实际执行前，Redis 会做三步校验：user->flags & USER_FLAG_DISABLED（是否启用）、密码比对、命令/键/频道权限判定。其中命令权限是查一张预构建的位图（user->commands），O(1) 时间；键权限（~pattern）走 glob 匹配，最坏 O(n) 但实际因 key 名长度有限，开销可控。
这意味着：只要不频繁触发复杂 glob 模式或大量键权限判断，ACL 不会成为瓶颈。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 默认用户
default若未显式配置权限，实际继承-@all（全拒），但多数部署会设为+@all或allkeys allcommands，此时权限检查退化为空操作 - 使用
+@read这类命令类别比逐条写+get +hget +smembers更高效，因为内部仍用位图聚合 - 避免在高并发写场景中给每个用户配
~*+ 大量+@write组合——这不是 ACL 慢，而是放任了本可规避的危险操作（如FLUSHALL）被高频调用
哪些 ACL 配置会拖慢吞吐
真正拉低 QPS 的不是 ACL 框架，而是以下具体行为：
- 给用户配了多个
~键模式（如~user:* ~order:* ~cache:*），每次命令都要遍历所有 pattern 做 glob 匹配；模式越多、key 名越长，耗时越明显 - 在热点命令路径中误用
KEYS *类扫描命令：即使有+keys和~*，该命令本身是 O(N) 全库遍历，ACL 只是“放行”，不加速它 - ACL 日志开启且高频拒绝（
ACL LOG积压）：日志写入是同步阻塞的，若大量权限错误集中发生，会卡住主线程 - 用
ACL SETUSER动态改权限后未ACL SAVE，又反复重启——看似无关，实则每次启动要重载整个 ACL 表，影响冷启动时间（虽不影响运行时吞吐）
如何验证 ACL 是否真成了性能瓶颈
别猜，直接看指标：
- 对比开启 ACL 前后
redis-cli --stat中的instantaneous_ops_per_sec，若下降 >5%，再排查其他因素（网络、客户端连接数、慢查询） - 用
redis-cli --latency -y 100测基础延迟，ACL 不应导致 p99 延迟突增；若突增，大概率是某条命令被反复拒绝并记日志 - 执行
ACL LOG查最近拒绝记录，若返回上百条，说明权限配置和客户端行为严重错配，得先修正逻辑而非优化 ACL - 注意
used_memory_peak_human是否异常升高——ACL 用户表本身内存占用极小，但错误配置导致的连接堆积或命令重试可能间接吃光内存
ACL 本身不是性能开关，它是安全策略的载体。吞吐掉下去，往往是因为你把「不该放行的命令」放行了，或者把「本该收敛的 key 范围」写得太宽，让 Redis 在执行层面承担了本该由业务层过滤的负担。
