为何单线程的redis那么快

这是我参与8月更文挑战的第4天，活动详情查看：8月更文挑战

redis单机QPS

./redis-benchmark -t set,lpush -n 100000 -q
SET: 82101.80 requests per second
LPUSH: 82440.23 requests per second
复制代码

在本身的电脑上测试SET和LPUSH10万次，能够发现每秒SET和LPUSH大概在8w多，接近官方说的单机10w qps的写。

为何这么快

内存型数据库

redis彻底是基于内存的，绝大部分请求是纯粹的内存操做，因此很是快速。

简单的数据结构

redis目前支持5种数据类型（string、list、hash、set、zset），数据结构相对简单，操做起来也相对快速。

sds数据结构

对于string来讲，redis采用SDS方式来组织数据：

这种数据的核心思想就是空间换时间

1. 空间预分配：当空间扩展时，不只分配所需空间，还会分配额外的空间

• 分配后sds长度小于1M，那么也分配一样大小的额外空间，假设一个key修改后 len=13，那么也分配free=13，最后buf=13+13+1=27
• 若是分配后len大于等于1M，那么额外固定分配1M，假设修改后len=30M，分配free=1M，最后buf=30M+1M+1byte

2. 惰性空间释放

• 假设有个len=13，free=13的字符串，这时候若是字符变短了len=10，那么额外的3个byte的空间也不会回收，先放在free里面，这时候free=16

经过这种分配方式，某些场景下能够减小内存申请的次数，从而达到必定的快速

跳跃表

redis的有序集合，采用的跳跃表的数据结构，经过层来加快访问其余节点

每一个节点会随机一个层高，好比o1节点能够经过L4层直接跳到o3,跨度是2，redis的有序集合就是经过这种方式来加快节点之间的访问的。

单线程

redis采用单线程模型，单线程的好处在于避免了多线程对数据竞争的问题，加锁的问题，上下文切换的问题。
据官方解释，redis的瓶颈不在cpu，而在内存或者网络的带宽，综合考虑而后就采用了单线程。这里说的单线程是指处理网络请求时只是用一个线程，redis自己在持久化的时候仍是会用到额外的线程的。

redis4.0的多线程

redis4.0开始也支持了多线程，固然只是针对部分命令采用的是多线程，例如：UNLINK、FLUSHALL 、ASYNC、FLUSHDB。引入这些的目的是：在某些状况下，尽量的提高效率，假设有一个key大到几十M，这时DEL这个key的时候，可能会短暂的阻塞，这时若是用unlink来删除，刚开始只是删除这个key，真正的value是后台线程去删除的。

IO多路复用

redis采用了非阻塞的IO多路复用技术。redis自己就是一个事件驱动程序，redis把socket抽象成文件事件。这里说的IO多路复用就是文件事件处理器以单线程的方式，来监听相关的套接字（accept、read、write、close）。

因为IO多路复用程序是一个单线程，那么当多个socket到来时，确定要排队，它们老是以队列的方式顺序地处理。

C10K问题

在没有IO多路复用的时候，假设如今有10000个客户端链接（fd1-10000），可是只有1个客户端有发数据，然而计算机并不知道哪一个fd有数据，只能遍历10000次，每次都要陷入内核，开销比较大，并且实际上9999次都是浪费的。

IO多路复用

IO多路复用的意思就是多个网路IO即为多个TCP链接 复用一个进程或者线程，这种模型最大的好处就是不用为每一个链接建立一个进程或者线程。比较经典的模型就是 select、poll、epoll。

1. select：select(fds)，一次性把fds交给内核，而后内核告诉哪些fd可读可写（内核本身遍历，而不用用户遍历，将屡次的系统调用变成1次系统调用）。fds最大是1024，这也决定了select模型最大并发是1024。
2. poll：和select差很少，只不过并发不止1024了，能够更多
3. epoll: select和poll的缺点是内核遍历的时间复杂度是O(n)，虽然用户态不用遍历了，减小了陷入内核的次数，可是内核仍是要遍历的。epoll的优势就是内核也不须要遍历了，当用户把fds传给内核时，而后依赖硬件中断，好比当网卡有数据到来时，就会中断告诉cpu，cpu就知道哪一个fd有数据到达了。

redis默认采用epoll，除非系统不支持。

总结

1. redis是内存型数据库
2. redis特殊的数据结构
3. 单线程避免锁的竞争
4. io多路复用

以上4点是单线程redis快的主要缘由。