浅谈为什么单线程的redis那么快

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方式来组织数据：

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

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

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

惰性空间释放

• 假设有个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。

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

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

总结

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

以上4点是单线程redis快的主要原因。

到此这篇关于浅谈为什么单线程的redis那么快的文章就介绍到这了,更多相关redis 单线程快内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论