初探Redis整体架构-Toy模板网

这篇具有很好参考价值的文章主要介绍了初探Redis整体架构。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1、Redis为什么选择单线程

这种问法其实并不严谨，为啥这么说呢?
初探Redis整体架构

Redis几个里程碑式的重要版本

初探Redis整体架构

理清一个事实，我们通常所说的单线程究竟为何意？
Redis是单线程主要是指Redis的网络IO和键值对读写是由一个线程来完成的，Redis在处理客户端的请求时包括获取(socket读)、解析、执行、内容返回(socket 写)等都由一个顺序串行的主线程处理，这就是所谓的“单线程”。这也是Redis对外提供键值存储服务的主要流程。

初探Redis整体架构

但Redis的其他功能，比如持久化RDB、AOF、异步删除、集群数据同步等等，其实是由额外的线程执行的。Redis命令工作线程是单线程的，但是，整个Redis来说，是多线程的;

Redis3.x单线程时代但性能依旧很快的主要原因

基于内存操作：Redis的所有数据都存在内存中，因此所有的运算都是内存级别的，所以他的性能比较高;
数据结构简单:：Redis 的数据结构是专]设计的，而这些简单的数据结构的查找和操作的时间大部分复杂度都是O(1)，因此性能比较高;
多路复用和非阻塞IO: Redis使用 I/O多路复用功能来监听多个socket连接客户端，这样就可以使用一个线程连接来处理多个请求减少线程切换带来的开销，同时也避免了I/O阻塞操作
避免上下文切换和多线程加锁竞争：因为是单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的消耗，而且单线程不会导致死锁问题的发生

Redis是单线程的，如何利用多个CPU/核心呢？

这是官方以前的文档，不过蓝色框中的内容已经被拿掉或者做了对应的修改
初探Redis整体架构

这是现在官方文档的原话，可以做一下对比

初探Redis整体架构

简单来说，Redis4.0之前一直采用单线程的主要原因有以下三个：

使用单线程模型是Redis的开发和维护更简单，因为单线程模型方便开发和调试
即使使用单线程模型也并发的处理多客户端的请求，主要使用的是IO多路复用和非阻塞IO
对于Redis系统来说，主要的性能瓶颈是内存或者网络带宽而并非CPU

2、逐步加入多线程

前面谈到单线程既然这么好，为什么要需要逐步引入多线程呢？

1、随着硬件的发展，现在机器的CUP一般都是多核，只有一个单线程，对硬件的使用就不是特别充分，虽然Redis的瓶颈不是CUP

2、单线程也有痛点
正常情况下使用del指令可以很快的删除数据，而当被删除的key是一个非常大的对象时，例如时包含了成于上万个元素的hash集合时，那么del指令就会造成Redis主线程卡顿。这就是redis3.x单线程时代最经典的故障，大key删除的头疼问题，由于redis是单线程的，del bigKey…
等待很久这个线程才会释放，类似加了一个互斥锁，你可以想象高并发下，程序堵成什么样子?

对于删除大key问题是如何解决的呢？
使用惰性删除
此如当我(Redis) 需要删除一个很大的数据时，因为是单线程原子命令操作，这就会导致Redis服务卡顿，于是在Redis4.0中就新增了多线程的模块，当然此版本中的多线程主要是为了解决删除数据效率比较低的问题。
unlink key、flushdb async、flushall async等命令会把删除工作交给子线程异步来删除数据。
因为Redis是单个主线程处理，redis之父antirez一直强调"Lazy Redis is better Redis"
而lazy free的本质就是把某些cost(主要时间复制度，占用主线程cpu时间片)较高删除操作，从redis主线程剥离让bio子线程来处理，极大地减少主线阻塞时间。从而减少删除导致性能和稳定性问题。

在Redis 4.0就引入了多个线程来实现数据的异步惰性删除等功能，但是其处理读写请求的仍然只有一个线程，所以仍然算是狭义上的单线程

3、前面说到，CPU不太可能成为Redis的性能瓶颈，那么还剩内存和网路IO。对于内存而言，就连我3年前买的电脑都是16G，更何况那些大型的服务器，因此内存也不太可能成为Redis的性能瓶颈。那么现在就剩网路IO了。

Redis6/7全面支持多线程
Redis一直被大家熟知的就是它的单线程架构，虽然有些命令操作可以用后台线程或子进程执行( 比如数据删除、快照生成、AOF重写)。但是，从网络IO处理到实际的读写命令处理，都是由单个线程完成的。
随着网络硬件的性能提升，Redis的性能瓶颈有时会出现在网络IO的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度。为了应对这个问题：采用多个IO线程来处理网络请求，提高网络请求处理的并行度，Redis6/7就是采用的这种方法。

但是，Redis的多IO线程只是用来处理网络请求的，对于读写操作命令Redis仍然使用单线程来处理。这是因为，Redis处理请求时，网络处理经常是瓶颈，通过多个IO线程并行处理网络操作，可以提升实例的整体处理性能。而继续使用单线程执行命令操作，就不用为了保证Lua脚本、事务的原子性，额外开发多线程互斥加锁机制了(不管加锁操作处理)，这样一来， Redis线程模型实现就简单了

主线程和IO线程协同工作流程

初探Redis整体架构

阶段一：服务端和客户端建立Socket连接,并分配处理线程
首先，主线程负责接收建立连接请求。当有客户端请求和实例建立Socket连接时，主线程会创建和客户端的连接，并把Socket放入全局等待队列中。紧接着，主线程通过轮询方法把Socket连接分配给IO线程。
阶段二: IO线程读取井解析请求
主线程一旦把Socket分配给IO线程，就会进入阻塞状态，等待IO线程完成客户端请求读取和解析。因为有多个IO线程在并行处理，所以，这个过程很快就可以完成。
阶段三：主线程执行请求操作
等到IO线程解析完请求，主线程还是会以单线程的方式执行这些命令操作。
阶段四：IO线程回写Socket和主线程清空全局队列
当主线程执行完请求操作后，会把需要返回的结果写入缓冲区，然后，主线程会阻塞等待IO线程，把这些结果回写到Socket中，并返回给客户端。和IO线程读取和解析请求一样，IO线程回写Socke时，也是有多个线程在并发执行，所以回写Socket的速度也很快。等到IO线程回写Socket完毕，主线程会清空全局队列，等待客户端的后续请求。

3、Redis采用IO多路复用—epoll和Reactor架构

一种同步的IO模型，实现一个线程监视多个文件句柄，一旦某个文件句柄就绪就能够通知到对应应用程序进行相应的读写操作，没有文件句柄就绪时就会阻塞应用程序，从而释放CPU资源

I/O：指网络I/O，尤其在操作系统层面指数据在内核态和用户态之间的读写操作
多路：多个客户端连接(连接就是套接字描述符，即socket或者channel)
复用：复用一个或几个线程

也就是说一个或一组线程处理多个TCP连接，使用单进程(单线程)就能够实现同时处理多个客户端的连接，无需创建或者维护过多的进程/线程

实现IO多路复用的模型有3种：分别为select、poll、epoll
最高效的就是epoll，而Redis就采用的是epoll

从Redis6开始，就新增了多线程的功能来提高I/O的读写性能，他的主要实现思路是将主线程的IO读写任务拆分给一组独立的线程去执行，这样就可以使多个socket的读写可以并行化了，采用多路I/O复用技术可以让单个线程高的处理多个连接请求(尽量减少网络IO的时间消耗)，将最耗时的Socket的读取、请求解析、写入单独外包出去，剩下的命令执行仍然由主线程串行执行并和内存的数据交互。

初探Redis整体架构

不仅如此Redis采用高性能的Reactor模式

将用户socket对应的文件描述符(FileDescriptor)注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。这样，整个过程只在调用select、poll、epoli这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor反应模式。

初探Redis整体架构