Redis 6.0+的多线程仅用于网络IO（socket读写和协议解析），命令执行始终由单线程完成，确保原子性、无锁竞争和Lua脚本一致性；性能优势源于epoll事件驱动、精简数据结构及零冗余设计。
Redis主线程不处理网络IO，6.0+才启用多线程读写
很多人误以为“Redis 6.0 多线程 = 命令执行变多线程”，其实不是。Redis 的 command execution（命令解析、键查找、数据结构操作、返回组装）**始终由单个主线程完成**。6.0 引入的多线程只负责：socket read、socket write 和协议解析（如 RESP 解包），做完就扔给主线程处理。
这意味着：GET、SET、HGETALL 等所有命令的逻辑仍是串行执行；并发安全无需加锁；Lua 脚本原子性依然成立。如果你在压测中发现 latency spikes，大概率不是线程模型问题，而是某条慢命令阻塞了主线程。
- 配置开关在
redis.conf中：io-threads 4（默认 1，即关闭多线程 IO） - 必须同时开启：
io-threads-do-reads yes，否则只用于 write - 线程数建议 ≤ CPU 核心数，且为偶数（epoll 分发更均衡）
- 注意：AOF fsync、RDB fork、key 过期扫描等仍由后台线程或子进程处理，与主线程解耦
为什么单线程反而避免了性能内耗
不是“单线程天生快”，而是 Redis 把“上下文切换”和“锁竞争”这两块高成本开销直接砍掉了。比如 Java 应用里 50 个线程争抢一个 ConcurrentHashMap 的 segment 锁，大量线程在 park/unpark 上空转——而 Redis 主线程永远只有一个，没有 synchronized、没有 ReentrantLock、没有 CAS 自旋，自然没这些损耗。
但代价也很明确：任何阻塞操作都会拖垮整个实例。所以你绝不能在 Redis 里执行：KEYS *、长时间运行的 Lua 脚本、或自定义阻塞命令（除非用 MODULE 显式注册异步回调）。
立即学习“Java免费学习笔记（深入）”；
- 典型陷阱：
SCAN不阻塞，但KEYS会遍历全部 dict，O(N) 时间且不可中断 - 过期 key 清理采用惰性 + 定期双策略，避免主线程卡在
activeExpireCycle - 大 value（如 >1MB 的 string 或超长 list）会导致内存拷贝延迟，影响后续请求响应
真正让并发扛住的关键：epoll + 非阻塞 I/O + 事件驱动
Redis 不是靠“线程多”来撑连接数，而是靠 epoll_wait() 一次监听成千上万个 socket，并把就绪事件（readable/writable）放进队列，由主线程顺序 dispatch。这比 Java 的 Selector 更轻量，因为没有 NIO Buffer 管理、没有 SelectionKey 注册/取消开销，连 event loop 都是自己写的极简版。
你可以把它理解成：一个线程 + 一个 while 循环 + 一张就绪 socket 表。网络层完全不阻塞，磁盘层交给子进程（fork）或线程池（AOF rewrite），主线程只干三件事：parse → execute → reply。
- Linux 下默认使用
epoll，macOS 用kqueue，Windows 已弃用（官方不支持） -
tcp-backlog配置要匹配系统net.core.somaxconn，否则新连接被内核丢弃 - 客户端长连接复用至关重要；频繁建连会压垮
accept()和文件描述符分配
别被“内存快”带偏——底层数据结构才是隐形加速器
说“Redis 快是因为内存数据库”，只答对了 30%。真正让 O(1) 查找落地的是它的混合数据结构设计：比如 dict（哈希表）用双哈希表渐进式 rehash，避免扩容时卡顿；ziplist 在小 list/set/zset 中紧凑存储，省去指针跳转；quicklist 是 ziplist 的双向链表封装，兼顾内存和随机访问效率。
举个反例：如果所有 string 都用 C 原生 char*，每次 APPEND 都要 realloc + memcpy，性能早崩了。Redis 改用 sdshdr 结构，预分配 free 空间，APPEND 大多是 O(1) 内存操作。
-
redis-cli --bigkeys可快速定位 value 过大的 key，它们往往破坏局部性 - Hash 类型优先用
HSET批量写，避免多次小 packet 网络往返 - Sorted Set 的
ZRANGE要小心 offset + count 组合，底层是跳表遍历，非 O(1)
