Redis主线程跨NUMA节点调度会显著放大内存访问延迟：本地访问约100ns，远端访问超250ns，导致P99延迟抖动；网卡中断与Redis不在同一节点时，数据路径绕远并挤占互连带宽；THP在Redis场景下引发毫秒级延迟尖刺，关闭后P99标准差降60%以上。
Redis主线程频繁跨NUMA节点调度会放大内存访问延迟
Redis是单线程事件循环模型，主线程处理命令、网络IO和定时任务。在默认调度下，Linux内核可能把Redis进程从Socket 0迁移到Socket 1运行，而它之前缓存的热点数据（如键值对元信息、客户端连接结构体）仍留在Socket 0的本地内存中。此时Redis读取这些数据就会触发远端内存访问——延迟从约100ns跳到250ns以上，P99延迟直接抖动。这不是Redis代码问题，而是硬件拓扑与OS调度策略错配导致的。
网卡中断和Redis不在同一NUMA节点时，网络数据路径绕远
当网卡（比如eth0）物理上连在Socket 0，但其中断被分配到Socket 1的CPU上处理时，内核会把接收到的数据包写入Socket 1的内存缓冲区。Redis主线程若运行在Socket 0，每次epoll_wait返回后调用read()，都要跨总线去Socket 1拿数据。这个过程不仅延迟高，还挤占QPI/UPI互连带宽，影响其他服务。
- 查网卡所属NUMA节点：
cat /sys/class/net/eth0/device/numa_node - 查当前中断分布：
cat /proc/interrupts | grep eth0 - 强制绑定中断到目标节点核心：
echo "0-7" > /proc/irq/<irq_number>/smp_affinity_list</irq_number>（需先停掉irqbalance）
THP（Transparent Huge Page）在Redis场景下会引发周期性延迟尖刺
THP试图自动合并4KB页为2MB大页以减少TLB miss，但Redis大量随机小对象分配+频繁fork子进程（RDB/AOF rewrite），会导致内核在copy-on-write时阻塞主线程长达毫秒级。实测关闭THP后，P99延迟标准差下降60%以上。
- 临时关闭：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 永久关闭（openEuler等发行版需防tuned覆盖）：
echo 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' >> /etc/rc.local，并检查GRUB_CMDLINE_LINUX中是否含transparent_hugepage=never
server_cpulist比taskset更可靠，但必须配合I/O线程隔离
taskset -c 0,2,4,6 redis-server只作用于启动瞬间；一旦Redis因OOM或信号重启，亲和性就丢失。Redis 6.0+的server_cpulist参数写进redis.conf才是持久化方案。但要注意：如果启用了io-threads（Redis 7.0+），这些线程默认会抢占主线程绑定的核，必须显式配置io-threads-cpulist错开物理核。
- 正确配置示例：
server_cpulist 0,2,4,6io-threads 4io-threads-cpulist 1,3,5,7 - 修改后必须执行
redis-cli shutdown再redis-server redis.conf重载，CONFIG REWRITE不生效 - 别忘了客户端压测工具也要绑核：
taskset -c 1,3,5,7 redis-benchmark -t set,get -n 1000000
