Question

redis源码解读：单线程的redis是如何实现高速缓存的？

Answer 1

redis可能是最近几年最火的缓存数据库方案了，在各个高并发领域都有应用。

这篇文章，我们将从源代码的角度来分析一下，为何如此一个高性能，高应用的缓存，会是单线程的方案，当然一个方案的高性能，高并发是多方面的综合因素，其它的因素我们将在后续解读。后续分析主要以LINUX操作系统为基础，这也是redis应用最广的平台。

单线程最大的受限是什么？就是CPU，现在服务器一般已经是多CPU，而单线程只能使用到其中的一个核。

redis作为一个网络内存缓存数据库，在实现高性能时，主要有4个点。

1.网络高并发，高流量的数据处理。

一个异步，高效，且对CPU要求不高的网络模型，这个模型主要是由OS来提供的，目前在LINUX最主流使用的是EPOLL，这个网上介绍很多，主要是基于事件驱动的一个异步模型。

2.程序内部的合理构架，调用逻辑，内存管理。

redis在采用纯C实现时，整体调用逻辑很短，但在内存方面，适当的合并了一些对象和对齐，比如sds等，在底层使用了内存池，在不同情况下使用的不太一样。

但整体处理上没有NGINX的内池设计巧妙，当然二者不太一样，NGINX是基于请求释放的逻辑来设计的，因此针对请求，可以一次申请大块，分量使用，再最后统一释放。

3.数据复制的代价，不管是读取数据或是写入数据，一般都是需要有数据复制的过程。

数据复制其实就是一次内存copy，真正的代价是在于存在大VALUE，当value值长度超过16KB时，性能会开始下降。因为单线程的原因，如果存在一个超大VALUE，比如20MB，则会因为这个请求卡住整个线程，导致后续的请求进不来，虽然后面的请求是能快速处理的小请求。

4.redis中数据结构中算法的代价，有些结构在大数据量时，代价是很高的。

很多时间，大家忽略了算法的运算代码，因为像memcached等这类是完全的KV缓存，不存在什么算法，除了一个KEY的查找定位HASH算法。

而redis不一样，提供了不少高阶的数据对象，这些对象具有上层的一些算法能力，而这些能力是需要比如GEO模块。