面试官问 Redis 为什么能扛高并发，你会结合项目里的延迟和瓶颈怎么回答？
我的判断
Redis 快主要因为数据在内存、命令路径短、事件循环避免大量锁竞争，并通过高效数据结构和批量网络降低成本。
结合项目指标，我会说我们看到的是亚毫秒到几毫秒的服务端耗时，但端到端还包含网络、连接池和序列化。Redis 的大部分命令在内存完成，单主线程顺序执行命令，避免多线程共享数据结构的锁；底层编码会根据元素规模在紧凑结构和哈希/跳表之间切换。
“单线程”也不是全部。网络 IO、持久化、释放大对象等在新版本有后台或辅助线程；真正串行的是核心命令执行，因此一个 O(n) 大 key 命令、Lua 长脚本或网络大包足以阻塞后续请求。
项目里优化 Redis 延迟时，我会先减少往返，用 pipeline 或批量命令；避免 KEYS、大范围集合操作；控制 value 大小；监控 slowlog、命令延迟、网络和客户端连接。
所以 Redis 能扛高并发有前提：命令足够短、数据模型合理、热点可控。把复杂计算搬进 Lua 并不会因为“在内存里”就自动快。