Redis真的是单线程吗？
4.0版本前
如果是单线程，那么server对于各个client的请求基于epoll模型将client连接accept以及对请求数据进行解析+处理请求，这一整个过程由于是内存级的，可以通畅进行。
但，对于数据从内存落到磁盘当中呢？磁盘IO的速度相较于内存而言实在太慢，如果交由主线程定时触发持久化保存的操作，那么server就会过一阵卡一下，给client的体验很不好。但实际上用起来却不会因为这个问题导致没有这个client是不是阻塞，这是为什么？
因为既使在早期的Redis4.0版本前，Redis也有两个后台线程close_file负责异步关闭大文件fd，以及AOF_fsync负责AOF的异步刷盘。(注：这里的异步指的是相对于主线程而言，对于这两个后台线程，仍然是同步的)
4.0版本后，6.0版本前
而在4.0版本后，6.0版本前，由于惰性删除和定期删除机制，导致如果是主线程去释放一大块的哈希表内存，则会导致主线程在这一段较长的时间内无法去处理client新来的请求，因此引入了lazy_free线程，其负责异步惰性释放大块的内存空间。(注：这里的异步指的也是相对于主线程而言，对于lazy_free后台线程，仍然是同步的)
6.0版本
而在6.0版本后，由于互联网发展使得流量越来越大，因此为了提高效率，是用的是单reactor+线程池模型，主线程仍然是负责通过epoll对client进行accept，只是对于这些conn发来的请求，主线程将其交给全局共享数组，而后IO线程对全局共享数组进行协议的解析并将解析后的内容写回全局共享数组，主线程从数组中获取请求内容并处理进而生成响应而后将响应写回共享数组，IO线程将响应进行向客户端的发送。
但需要注意的是：无论哪个版本，Redis从来都是单线程进行真正意义上的对请求进行处理。(避开对锁的竞争带来的消耗)
总结
由此我们可以看到，事物的发展从来不是一直不变的，为了迎合业务的需求，技术需要不断进行迭代升级以适配业务场景的需要，毕竟，一切都是为了业务。