请注意，本文编写于 999 天前，最后修改于 999 天前，其中某些信息可能已经过时。
本篇重点
三个问题：
“Redis真的只有单线程吗？”
“为什么用单线程？”
“单线程为什么这么快？”
- “Redis真的只有单线程吗？”
- 否，“单线程”指的是Redis的网络IO和键值对读写 是由一个线程完成的^[[1]](https://www.cnblogs.com/GuoYuying/p/15058178.html#fn1)^
- Redis的其他功能由额外线程完成：持久化、异步删除、集群数据同步等
网络IO和键值对读写即Socket编程中的如下步骤
- 网络IO：bind/listen、accept、parse、send/recv
- KV读写：GET/PUT...
- “Redis为什么用单线程？”
- 多线程的开销：共享资源的并发访问控制，互斥锁等待，导致并转串
- “单线程Redis为什么那么快？”
- 大部分操作在内存完成（硬件速度）
- 高效数据结构（哈希表、跳表等）
- IO多路复用机制 ：使其在网络IO中能并发 处理大量客户端请求 ，实现高吞吐率
- 多路复用机制
网络操作的基本IO模型、潜在阻塞点（Redis采用单线程IO，若被阻塞将无法进行多路复用）
- 基本IO模型：
- 阻塞点：
accept()、recv()、send() - Socket网络模型本身支持非阻塞模式
| 调用方法 | 返回套接字类型 | 非阻塞模式 | 效果 |
|---|---|---|---|
| socket() | 主动套接字 | ||
| listen() | 监听套接字 | 可设置 | accept()非阻塞 |
| accept() | 已连接套接字 | 可设置 | send()/recv()非阻塞 |
- 基于多路复用的高性能IO模型
- Linux多路复用机制——一个线程处理多个IO流，如
select/epoll - 基于多路复用的Redis高性能IO模型
在请求到达时，如何通知到Redis线程？
基于事件的回调机制 （select/epoll提供）
事件被放入事件队列 ，Redis单线程对该事件队列进行处理。
QA
“Redis基本IO模型”中的潜在性能瓶颈？
