为什么单线程Redis性能也很出色

高性能的服务器，不一定是多线程实现的，也就是说多线程不一定比单线程效率高，这得分具体的情况。以redis为例，核心处理请求的线程只有一个，所以我们常常理解其仅仅只有一个线程，但准确来说其实并不是单线程的，比如日志的备份需要单独的fork一个进程或者线程去做备份等，那么redis何来单线程还能达到如此10万+的qps呢？其实这取决于具体的实现，redis采用了基于高性能Reactor的IO多路复用的模式+内存数据结构+单线程处理网络请求这几块，决定了其性能高的原因。

我们知道操作系统的主要资源有CPU，内存，磁盘，带宽，而对存储介质访问速度肯定是CPU缓存>内存>磁盘。

redis 核心就是 如果我的数据全都在内存里，我单线程的去操作 就是效率最高的，为什么呢，因为多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。redis 用 单个进程或者线程 绑定一块CPU，从而最大化提升该进程访问特定CPU缓存的速度，然后针对这块Cache内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处理这个事。在内存的情况下，这个方案就是最佳方案  —— 阿里 沈询


那么什么时候事务需要用到多线程呢？这个问题的本质取决于下层所使用的存储，如果是内存操作，则可以动态地申请和销毁内存块；而磁盘的IOPS很低，但吞吐量很高。如果一个场景涉及多次读写操作，单线程可以很高的效率对于内存进行读写操作；但是，由于磁盘的IOPS仅为内存的几千分之一，如果依旧用操作内存的方式操作磁盘，那系统的整体性能将会很低，这意味着必须将大量的读写操作聚合成一个Batch后再提交时才能达到较好的性能。而将大量请求攒到一起的方式一是异步，也就是请求本身和线程不绑定，线程可以不Block（本质来说还是一种多线程的方式），处理完一个线程后再处理其他线程。这种做法的核心是将大量不同的请求提交到一个Buffer中，再由该Buffer统一读取或者写入磁盘，从而提高效率。在慢速设备中，多线程或异步非常常见，在设计系统时，面对磁盘、网络、SSD等慢速设备必须考虑使用多线程。

方法就是用异步：将请求和处理的线程不绑定，请求的线程将请求放在一个buff里，然后等buff快满了，处理的线程再去处理这个buff。然后由这个buff 统一的去写入磁盘，或者读磁盘，这样效率就是最高。 java里的NIO, 大名鼎鼎的netty 就是这么干的，对于慢速存储设备磁盘，网络，SSD，这种处理方式异步+多线程+写缓冲区buffer就是最佳的。

其实原理的东西就这么些，本身都是操作系统相关的东西，并不复杂

为何单线程绑定一个cpu效率最高，CPU 是一个重要的影响因素，由于是单线程模型，Redis 更喜欢大缓存快速 CPU（主频高）， 而不是多核，在多核 CPU 服务器上面，Redis 的性能还依赖 NUMA 配置和 处理器绑定位置。 最明显的影响是 redis-benchmark 会随机使用 CPU 内核。为了获得精准的结果，需要使用固定处理器工具（在 Linux 上可以使用 taskset）。 最有效的办法是将客户端和服务端分离到两个不同的 CPU 来高校使用三级缓存。


（1）redis作为单进程模型的程序，为了充分利用多核CPU，常常在一台server上会启动多个实例。而为了减少切换的开销，有必要为每个实例指定其所运行的CPU。

（2） Linux 上  taskset 可以将某个进程绑定到一个特定的CPU。你比操作系统更了解自己的程序，为了避免调度器愚蠢的调度你的程序，或是为了在多线程程序中避免缓存失效造成的开销。


总结一下，redis单线程性能出色的必要条件：


（1）以内存为主要存储结构，这是快的前提

（2）高性能的基于epoll的IO多路复用模式

（3）单进程/单线程直接绑定CPU，避免OS无用调度和上下文切换