禁用公网绑定和密码认证对性能影响极小，生产环境必须显式绑定内网ip并启用强密码；acl应扁平化、精确匹配key pattern，读多写少用acl，写密集优先rename-command；内网绑定、强密码、禁用危险命令三者结合可抵御绝大多数威胁。
禁用公网绑定 + 密码认证不影响性能，但必须做
Redis 默认 bind 0.0.0.0 和 protected-mode yes 是安全兜底，但生产环境不能依赖它。真实风险来自误配或暴露在公网——一旦被扫描到，FLUSHALL 或 CONFIG SET 可能几秒清空全部数据。
正确做法是：显式绑定内网 IP（如 bind 172.16.0.10），同时启用密码（requirepass your_strong_password）。这两项加起来对 QPS 几乎无影响（压测中 p99 延迟波动
- 不要用弱密码（如
123456、redis），避免暴力破解后执行 Lua 脚本或写入恶意 key - 密码长度建议 ≥12 位，含大小写字母+数字+符号；避免硬编码在客户端配置里，改用环境变量注入
- 如果用 TLS（Redis 6.0+），需额外开销（CPU 约 +8~12%，延迟 +0.2~0.5ms），仅在跨公网传输时启用，内网不必要
rename-command 禁用危险命令比加锁更轻量
很多团队想靠 ACL 或连接池限权来控制高危操作，但 Redis 5.0+ 的 ACL 在高频命令路径上有微小开销（尤其 ACL CHECK 每次命令都触发），而直接禁用更干净。
在 redis.conf 中用 rename-command 移除实际不用的命令，比如：
rename-command FLUSHALL "" rename-command CONFIG "" rename-command DEBUG "" rename-command EVAL ""
注意：EVAL 禁用后，所有 Lua 脚本失效；若业务依赖 Lua，改用 ACL 细粒度授权（如只允许读 key、禁止 redis.call("FLUSHDB")）。
-
rename-command是启动时加载的静态规则，不参与运行时判断，零延迟 - 别重命名成空字符串以外的值（如
rename-command FLUSHALL flushall_safe），否则攻击者仍可调用新名字 - 禁用
CONFIG后，无法动态调CONFIG GET/SET，运维需改用 conf 文件 + 重启生效
TLS 加密只在跨公网场景下启用
内网通信走明文 TCP 是 Redis 高性能的基础设计。强行给所有连接套 TLS，会显著拖慢吞吐——实测 1KB value 下，QPS 下降约 18%，p99 延迟从 0.3ms 升至 0.8ms（Intel Xeon Gold 6248R，万兆网卡）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真正需要加密的只有两类链路：
- 客户端直连 Redis（如公网爬虫服务调用）
- 跨机房主从同步（尤其金融、政务类跨地域部署）
其他情况（K8s Pod 内、同 VPC 内网、宿主机直连）一律用明文。Redis 本身不校验证书链，tls-ca-cert-file 配错会导致连接失败，且错误信息模糊（常见 Connection reset by peer，实际是证书验证失败）。
ACL 权限模型在混合读写场景下要慎用
ACL（Redis 6.0+）支持按用户设权限，看起来很理想，但在高并发写场景下有隐藏成本：每个命令执行前，Redis 会查 ACL 规则树，当 ACL 条目 > 50 条时，平均延迟上升明显（实测 +0.1~0.3ms/请求）。
推荐策略：
- 只对非默认用户（
default用户保持无权限限制）启用 ACL，例如运维账号admin、应用账号app_rw - ACL 规则尽量扁平（避免嵌套
on > +@read > ~cache:*这类多层匹配），用精确 key pattern（如~user:123:*）替代通配符~* - 读多写少服务（如缓存层）可用
ACL SETUSER app_ro on > +get > +hget > ~cache:*；写密集服务（如计数器）优先用rename-command控制入口，而非 ACL 拦截
安全和速度不是非此即彼的选择——关键在于把防护点卡在攻击面最窄、开销最小的位置。内网绑定、强密码、禁用危险命令这三件事做完，就挡住了绝大多数真实威胁；其余优化，得看你的网络拓扑和业务读写特征再动刀。
