Redis为什么要设计成单线程？

我们知道Redis6.0之前是单线程设计，即使6.0重磅推出的多线程，那也仅仅是IO多线程，主工作线程实际上任然是单线程操作（执行命令任然是单线程顺序执行），那么为什么Redis在设计之初无论是IO线程还是工作线程都选择了单线程模式，并且任然能保证非常高效的吞吐量？

我们先来看一段来自官网的说明！

直接翻译过来，大概看看。。。

从官网的说明可以看出，一直以来CPU都不是用户使用Redis的瓶颈，也就是说多线程并不能给Redis带来太多的收益，但是为了充分发挥出多核CPU的优势，Redis慢慢的还是趋向于多线程化的，所以直到6.0推出了多线程版本。

多线程带来了什么问题？

虽然多线程并不能带来太多的收益，但是相比单线程总是有一定优势的，那么为什么设计之初没有采用呢？这其中的原因除了收益不高以外，当然还有多线程带来复杂的设计原因，如果采用了多线程那么就要考虑线程安全的问题，那么必然又会涉及到各种锁带来的性能上的消耗，包含注意线程切换、死锁等问题。

所以简单的理解，相比单线程而言，多线程大大提升了设计的复杂性，收益与成本不成正比。

Redis单线程为什么还能那么快？

Redis6.0之前虽然是单线程的，但吞吐量依旧很高，那是因为Redis采用了I/O多路复用的网络模型，我们知道使用Redis会有大量的读写请求，如果使用单线程按顺序一个个处理效率肯定不高，而多路复用刚好能够解决这样的问题。

由于Redis优秀的设计使得很多常用命令的时间复杂度都是O(1)，比如get、set操作，稍微耗时一点的命令，其时间复杂度一般也就O(N)或O(log(N))，这就决定了几乎不会占用太多CPU。

Redis是基于纯内存操作的，Redis服务器最高可以支持约10W的QPS，这基本上能够满足绝大多数用户的使用需求了。

简单的介绍了一下什么是多路复用

采用多路复用模型实际上就不是一个线程对应一个请求了，而是将多个请求注册到多路复用器上，利用多路复用器来监听注册的事件是否发生，如果发生再让线程去处理，这样就可以做到一个线程同时处理多个请求。