redis学习笔记（一）单线程的redis为什么快？

redis是单线程吗？

我们经常能听到这样的说法：Redis 是单线程。redis单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。 但 Redis 的其他功能，比如持久化数据、异步删除、集群数据同步等，其实是由其他的线程执行的。 所以，严格来说，redis 并不是单线程，但是我们一般把 redis 称为单线程（键值对存储服务）。

redis为什么用单线程？

要了解这个问题，首先得知道多线程的开销。

“使用多线程，可以增加CPU吞吐率”这个说法是没问题的，对于一个多线程的系统来说，在有合理的资源分配的情况下，可以增加系统中处理请求操作的资源实体，进而提升系统能够同时处理的请求数，即吞吐率。但是，通常情况下，在采用多线程后，如果没有良好的系统设计，实际得到的结果却是不确定的。

因为多线程一个关键的瓶颈在于，系统中通常会存在被多线程同时访问的共享资源，比如说一个基础的自增操作，如果多线程同时访问，就会出现原子性问题，并发访问控制一直是多线程开发中的一个难点问题，只是简单地采用一个粗粒度互斥锁，就会出现不理想的结果：即使增加了线程，大部分线程也在等待获取访问共享资源的互斥锁，并行变串行，系统吞吐率并没有随着线程的增加而增 加。 而且，采用多线程开发一般会引入同步原语来保护共享资源的并发访问，这也会降低系统 代码的易调试性和可维护性。为了避免这些问题，Redis 直接采用了单线程模式。

单线程的redis为什么快？

1、操作都是基于内存

2、高效的数据结构，例如哈希表和跳表

3、多路复用机制，使其在网络 IO 操作中能并发处理大量的客户端请求，实现高吞吐率。（具体可以看我这篇转载的文章 https://blog.csdn.net/weixin_40378837/article/details/104305201）

redis慢在哪里

强如redis也有它的瓶颈，Redis 之所以能快速操作键值对，一方面是因为 O(1) 复杂度的哈希表被广泛使用，包括 String、Hash 和 Set，它们的操作复杂度基本由哈希表决定，另一方面，Sorted Set 也采 用了 O(logN) 复杂度的跳表。不过，集合类型的范围操作，比如 List 类型的 LRANGE 和 ZSet 类型的 ZRANGE，因为要遍历底层数据结构，复杂度通常是 O(N)。（可以用 SCAN 来代替， 避免在 Redis 内部产生费时的全集合遍历操作），还有复杂度较高的 List 类型，它的两种底层实现结构：双向链表和压缩列 表的操作复杂度都是 O(N)。