redis单线程能扛住10万+ qps，核心在于：纯内存操作（纳秒级响应）、单线程避免锁与上下文切换、io多路复用（epoll）单线程管理数万连接。
面试中讲Redis高并发原理，关键不是堆术语，而是用场景带出逻辑——让面试官听懂“为什么单线程反而扛得住十万QPS”。下面这几个点，按真实业务节奏组织语言，自然流畅、有画面感、不背书。
用电商秒杀开场，点出瓶颈在哪
比如聊到秒杀场景：“用户抢iPhone，瞬间涌进50万请求。如果全打到MySQL，磁盘IO直接堵死，可能连1万QPS都撑不住。这时候Redis就成第一道闸口——它不处理复杂事务，只干一件事：快速判断库存key是否存在、原子性decr。这个动作在内存里完成，耗时约100纳秒，比磁盘快10万倍。”
把单线程讲成“专注的流水线工人”
别只说“避免锁和上下文切换”。可以这样说：“Redis就像一个不换岗的资深质检员，所有请求排成一条队列，他按顺序一个个验货（执行命令）。不抢资源、不等别人、不来回切换——所以没有锁冲突，也不用保存/恢复线程状态。虽然只有一双手，但手边全是内存里的数据，拿起来就干，效率反而拉满。”
用I/O多路复用解释“怎么管上万连接”
补充一句很落地的话：“他不是靠人海战术（每连接开一线程），而是靠一个智能呼叫屏（epoll）。几千个用户同时连上来，屏幕只闪一次，告诉他‘A、C、F三个连接有新命令了’，他就立刻去处理这三个——其余时间不空转、不阻塞。所以一个线程轻松管理几万socket连接。”
顺手带出扩容思路，体现架构意识
结尾自然延伸：“当然，单机总有极限。我们实际做秒杀时，会用主从读写分离：写库存走master（几万QPS够用），读商品详情、用户缓存全部打到多个slave，这样读QPS能轻松破10万。再往上，就上Redis Cluster分片，把key按槽分散到不同节点——这才是支撑千万级流量的真实底座。”
