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 利用率的甜点；超过这个数，配置同步、故障定位、连接池管理的开销会反超收益。