为什么redis是单线程却能快速处理高并发？_并发状态下redis是单线程么

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。

丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。

原子 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。

丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

为什么这么快呢？

在我们平时买电脑的时候，主要参考的是 CPU 和显卡，CPU线程核心数越多，性能越好。
同理，Redis这么快，应该也是设计成多线程的才对啊。

实际上恰恰相反，Redis却是单线程的。

注意：

Redis的单线程，是真的只使用一个线程吗

Redis在其核心数据操作上运行在单线程模式，但是这并不意味着Redis的整个服务器进程只使用一个线程。
在Redis 6.0版本之前，所有的数据读取、写入、处理操作确实是在单个线程上串行执行的，
但即便在那个时候，Redis也会使用其他辅助线程来处理比如数据持久化（AOF、RDB）、集群消息传递等后台任务。

从Redis 6.0版本开始，引入了多线程模型来处理客户端的网络请求，但是这里的多线程仅仅是用于辅助任务，
如读取客户端的请求和将回复写入网络，而不是用于数据的读写操作。Redis中的数据读写操作仍然是单线程的，这保持了Redis的简单性和性能优势，
因为这样就避免了线程切换和同步的开销，同时也避免了并发数据访问时的竞态条件和锁的问题。

Redis快的原因

Redis之所以能够在单线程模型下快速处理高并发请求，主要得益于以下几个方面：

1、纯内存操作
Redis 将所有数据都存储在内存中，内存的读写速度非常快，这是Redis能够高速读写的基础。

2、非阻塞I/O
Redis在网络操作上使用非阻塞I/O，在连接客户端时和读写网络套接字时都不会阻塞处理器。即使某个操作因为资源暂时不可用而无法立即完成，它也不会等待，而是会继续执行处理其他任务，直到资源可用再回来完成之前的操作。

这种事件驱动模型带来的优势是显而易见的：

• 高效的并发处理能力：单线程可以管理多个网络连接，避免了多线程或多进程模型中常见的上下文切换和同步锁的开销。
• 响应性强：由于事件几乎是即刻处理的，这使得Redis能够快速响应外部的请求。
• 简化的编程模型：单线程的事件循环比多线程并发要简单，易于编写和维护。

3、高效的数据结构
Redis为了确保高效的数据操作和访问速度，内部实现了多种专门优化的数据结构。
这些数据结构不仅保证了操作的高效性，还能够提供对不同数据类型的支持。

下面我列出一些Redis中使用的关键数据结构：

• 简单动态字符串（SDS：Simple Dynamic String）

SDS是Redis用来保存字符串值的结构，它比C语言的传统字符串类型安全、高效，可以快速进行长度的计算和修改，且避免了频繁的内存重分配。

• 双端链表（Linked List）

Redis列表（List）类型的内部实现之一是双端链表，这种数据结构可以从两端快速添加或删除元素，适用于实现栈或队列这样的数据结构。

• 字典（Dictionary）

在Redis中，哈希表（Hashes）类型是通过字典这种数据结构实现的。字典使用了散列表（Hash Table），它是键值对的集合，可以提供O(1)时间复杂度的键的查找、添加和删除操作。

• 跳表（Skip List）

Redis的有序集合（Sorted Sets）在元素较多或者元素的成员较长时，使用跳表作为其内部实现之一。跳表是一种可以做到O(logN)时间复杂度搜索的有序数据结构，同时也支持快速的插入、删除、查找等操作。

• 整数集合（IntSet）

当一个集合（Set）类型的所有元素都是整数且元素数量不多时，Redis会使用整数集合来存储这个集合。整数集合是一种内存使用效率极高的数据结构，只支持整数值的存储。

• 压缩列表（ZipList）

压缩列表是Redis为了节省内存而设计的一种数据结构，它将多个元素序列化存储在一块连续的内存中。当列表（List）类型存储的字符串较小或者长度较短时，Redis会使用压缩列表来存储。

• 快速列表（QuickList）

快速列表是Redis 3.2中引入的，它是一种更为优化的列表数据结构，本质上是压缩列表和双端链表的结合体。快速列表可以很好地平衡内存和性能，特别是在列表元素较多或者元素大小不一时。

• 基数树（Radix Tree）

在Redis中，基数树（又称为radix tree）被用于实现Redis的Streams类型的内部数据结构。基数树是一种可以高效地存储键值对的树形结构，尤其适合存储具有大量共同前缀的键。

4、事件驱动模型
Redis使用了基于事件的编程模型，采用了多路复用技术，如epoll（在Linux系统上）来同时处理多个网络连接的I/O。
这意味着单个线程可以监听多个文件描述符，一旦某个描述符就绪（例如，一个TCP连接上有新数据可读），该线程就能立即处理它。

5、优化的命令执行
Redis中的命令大多数都非常简单并且执行快速，如GET和SET，这些操作的复杂度通常是O(1)。

6、单线程避免了多线程的问题
由于Redis是单线程的，它避免了多线程环境中常见的各种问题，如线程之间的上下文切换开销、竞态条件、死锁等，这也意味着它无需在内部使用锁来保护数据结构的完整性，进一步提高了效率。

多线程的引入使得Redis可以更好地利用多核服务器的网络I/O性能，同时保持其单线程的数据处理优势。即便如此，这些I/O线程的数量通常建议不要太多，因为Redis的瓶颈很少在网络I/O上，更多是在于内存速度和CPU处理命令的能力。

总的来说，Redis之所以快，是因为它主要在内存中操作，并且使用了高效的编程模型和数据结构。尽管它在6.0版本后引入了多线程处理网络I/O，但是Redis的核心优势仍然来源于它的单线程事件处理能力。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
的朋友，可以添加V获取：vip1024b （备注Go）**
[外链图片转存中…(img-io3bMe6I-1713187032834)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！