Redis 6.0 多线程仅用于网络 I/O（read/解析/write），命令执行仍由单主线程串行处理，无调度权与抢占能力，无法实现业务级优先级隔离；必须通过部署多个独立 Redis 实例（如端口 6379/6380）配合 RQ 队列绑定实现物理资源隔离。
Redis 6.0 本身不提供“线程级业务优先级隔离”——它的多线程仅用于网络 I/O，命令执行仍由单主线程串行处理。想让关键业务（如订单）绝对优先于普通任务（如日志统计），不能靠调大 io-threads 或改 io-threads-do-reads，必须用进程级隔离：即部署多个独立 Redis 实例。
为什么不能靠 Redis 6.0 多线程实现业务优先级
Redis 的多线程只做三件事：read、RESP 解析、write，所有命令（SET、GET、ZADD）仍在主线程排队执行。哪怕开了 6 个 I/O 线程，一个慢查询（比如 KEYS * 或大 HGETALL）照样阻塞所有请求。关键业务和低优任务共享同一个命令队列，没有调度权、没有抢占能力。
- 多线程 ≠ 多工作线程：Redis 没有“为订单队列分配专用 CPU 核心”的机制
-
io-threads调得再高，也无法避免slowlog中的长耗时命令拖垮整体响应 - ACL 可控权限，但不可控执行顺序；它防越权，不防阻塞
真正有效的隔离：单机多实例 + RQ 队列绑定
把关键业务和普通任务彻底拆到不同 Redis 进程，是唯一能保证资源独占、故障不扩散、性能可预测的做法。RQ（Redis Queue）天然支持这种模式，只需为不同队列传入不同 connection 对象。
- 启动两个 Redis 实例，端口分离：
6379（关键业务）、6380（后台任务） - 配置文件必须差异化：
port、pidfile、logfile、dbfilename、dir全部独立 - RQ 创建队列时显式指定连接：
Queue('high', connection=redis.Redis(port=6379)) - 避免混用默认连接：不传
connection参数会 fallback 到全局REDIS_URL，极易出错
配置文件修改最容易踩的坑
复制 redis.conf 后只改 port 是最常见错误。以下参数漏改一个，轻则启动失败，重则数据覆盖或日志写乱：
-
pidfile /var/run/redis6379.pid—— 不改会导致 systemctl 无法管理新实例 -
logfile /var/log/redis/redis6379.log—— 多实例共用日志文件会互相覆盖 -
dbfilename dump6379.rdb—— 否则多个实例可能同时写入同一dump.rdb，数据损坏 -
dir /var/lib/redis6379—— AOF 文件、临时 RDB 都依赖此路径，必须隔离 -
bind 127.0.0.1和protected-mode yes建议保留，防止暴露公网
验证隔离是否生效的关键检查点
别只看 ss -natp | grep redis 是否监听了多个端口。真正要确认的是运行时资源是否物理隔离：
- 分别对两个实例执行
INFO memory，检查used_memory是否独立增长 - 在
6379上执行CONFIG SET maxmemory 100mb，然后6380上执行CONFIG GET maxmemory，确认返回值不变 - 用
redis-cli -p 6379 MONITOR和redis-cli -p 6380 MONITOR同时抓包，确认命令流完全不交叉 - RQ worker 启动时指定
--url redis://localhost:6379，观察其只消费6379上的high队列
线程数配置、ACL 权限、I/O 优化，都是在单实例内“修修补补”；而多实例部署是直接换掉地基。一旦关键业务开始上量，这个选择就不再是“要不要做”，而是“什么时候做”。
