这是后端岗位的必问题，阿里、字节、美团、腾讯等大厂几乎每场面试都会出现。面试官想确认你是真的理解性能来源——内存 vs 磁盘、CPU密集 vs IO密集、epoll这些内核层的IO原语，而不是只会背"Redis快是因为它是内存数据库"。
先纠正问题：Redis快和单线程本身关系不大，瓶颈从来不在CPU而在网络IO和内存访问。
讲清楚四个核心原因：纯内存操作（约100纳秒级）、高效数据结构（skiplist、ziplist、quicklist）、IO多路复用（Linux的epoll、BSD的kqueue）、单线程避免锁竞争和上下文切换。
说明命令处理模型：单个事件循环从epoll里拿到就绪的FD，顺序执行命令，发回响应——所以命令天然串行，无需加锁。
补充Redis 6的改动：主线程的命令执行还是单线程，但网络IO（socket读写、协议解析）改成了worker线程池处理，为的是应对高并发连接数。命令执行本身仍然是串行的。
诚实讲出局限：遇到CPU密集命令（KEYS *、大LRANGE、长Lua脚本）或大key（bigkey）时，单线程会被一条慢命令卡死所有请求。
Redis快其实跟单线程关系不大，真正的原因有四点。第一是纯内存操作——读写都在内存里完成，一次操作大约100纳秒，而磁盘IO要毫秒级，差了四个数量级。第二是数据结构选择非常精细——小hash用ziplist实现，连续内存对CPU缓存友好；大了自动转成hashtable；有序集合用跳表保证O(log n)的范围查询；列表用quicklist平衡内存和性能。第三是IO多路复用，一个线程通过epoll监听成千上万个客户端socket，只在有事件就绪时才被唤醒，避免了一个连接一个线程的重模型和上下文切换开销。第四才是单线程——因为命令是串行执行的，所以天然原子，不需要加锁，不存在CAS自旋，也不会有CPU核之间的缓存行来回跳。代价就是——一条慢命令会卡住所有客户端。比如KEYS *在百万级的库上扫描、HGETALL一个10MB的大hash、或者跑个长Lua脚本，整个Redis就会抖。这也是为什么生产环境都禁用KEYS改用SCAN。Redis 6做了多线程IO改造，专门针对网络层——读写socket、解析RESP协议可以由worker线程池并行处理，但命令执行仍然在主线程里串行，以保留原子性承诺。所以准确的说法是：Redis是"单线程命令执行 + 多线程IO"的混合模型。
不要只说"Redis快是因为内存"然后就停住，面试官期待听到epoll、单线程原子性、编码优化这些层次。
要能具体点出哪些是坑命令：KEYS、FLUSHALL、大LRANGE、大HGETALL、SMEMBERS大集合。
Redis 6的多线程改动必须会讲，答错会被扣"没有跟上新版本"的印象分。
真实面试中忘词别慌，即答侠可以帮你快速提示epoll、ziplist、bigkey这些关键概念。
只在连接数多、网络IO是瓶颈时有效——这正是Redis 6解决的场景。如果是CPU密集命令，多线程反而会引入锁开销，大概率拖慢性能。
不适合。复杂的Lua脚本、大数据聚合应该放到应用层做。一条慢命令就能让整个实例假死。
单机跑多个Redis实例，每个绑定一个核；上Redis Cluster做分片；或者用读副本分流读请求。