Redis默认单线程设计，仅用一个CPU核，多核需通过部署多个实例分摊压力；Redis 7.0的--server-workers仅加速网络I/O，不提升命令执行并发。
Redis 默认只用一个 CPU 核，多核白买了
Redis 服务端是单线程事件循环（aeEventLoop），所有客户端命令、网络读写、定时任务都在一个线程里串行执行。哪怕你机器有 64 核，redis-server 进程的 CPU 使用率也很难超过 100%（即单核满载）。这不是 bug，是设计使然——避免锁竞争、简化内存模型、保证命令原子性。
所以“优化多核效率”的本质不是让 Redis 自己并发，而是通过合理部署结构，把压力分摊到多个独立的 redis-server 实例上，让每个实例跑在一个核（或一组核）上，真正吃满多核资源。
用 redis-server --server-workers 启动多工作线程？别试了
Redis 7.0 引入了实验性多线程 I/O（--server-workers），但它只负责网络读写和协议解析，**不处理命令执行**。实际压测中，对吞吐提升有限（通常 Assertion failed: !listEmpty(server.clients_pending_write) 等不稳定错误，生产环境不建议启用。
更关键的是：它无法解决命令执行瓶颈（比如大 HGETALL、LRANGE、KEYS *），这些仍卡在主线程。与其折腾这个开关，不如直接做实例拆分。
- 确认你的 Redis 版本：
redis-server --version，7.0+ 才有--server-workers - 若真要试，必须配
io-threads-do-reads yes+io-threads 4（线程数 ≤ CPU 核数一半） - 监控
instantaneous_ops_per_sec和used_cpu_sys，发现波动剧烈就关掉
真正有效的做法：用 redis-cli --cluster 或 redis-shake 做分片
Redis 官方推荐的多核利用路径是「水平分片」：启动多个独立的 redis-server 实例（每个绑定不同端口、配置不同 bind 和 port），再用客户端或代理层按 key 做哈希路由。这样每个实例独占 CPU 资源，互不干扰。
常见落地方式：
-
redis-cli --cluster create：适合新集群，自动分配 slot，但要求所有实例版本一致、无数据 -
redis-shake（阿里开源）：在线迁移旧单实例数据到分片集群，支持断点续传，sync模式比dump/load更稳 - 应用层直连分片：用
redis-py的ClusterRedis或lettuce的RedisClusterClient，key 自动 CRC16 % 16384 路由
注意：分片后 MULTI/EXEC、WATCH、跨 key 的 KEYS 或 SCAN 全失效，必须改代码适配。
绑核 + 内存页锁定，防止 OS 调度抖动
即使开了多个实例，Linux 默认会把它们调度到任意 CPU 上，频繁迁移导致 cache miss、TLB 刷新，反而降低吞吐。尤其在高 QPS 场景下，redis-server 进程的 cpu_migrations 指标突增就是信号。
实操建议：
- 用
taskset -c 0-3 redis-server /path/to/redis.conf把第一个实例固定到 CPU 0~3 - 第二个实例用
taskset -c 4-7 redis-server /path/to/redis2.conf，以此类推 - 在
redis.conf中开vm.overcommit_memory = 1+transparent_hugepage=never（后者需 sysctl 或 grub 参数） - 加
maxmemory-policy noeviction避免淘汰触发的随机内存扫描（影响 cache locality）
绑核不是玄学，是让 L1/L2 cache 真正被复用。测试时对比 perf stat -e cycles,instructions,cache-misses 就能看见差异。
分片数量不是越多越好，16~32 个实例通常是平衡运维成本和 CPU 利用率的甜点；超过这个数，配置同步、故障定位、连接池管理的开销会反超收益。
