redis7的单线程&多线程

1、redis为什么选择单线程

1.1、redis7单线程

Redis是单线程

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


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

1.2、redis7单线程快

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

简单来说，Redis4.0之前一直采用单线程的主要原因有以下三个：
1 使用单线程模型是 Redis 的开发和维护更简单，因为单线程模型方便开发和调试；
2 即使使用单线程模型也并发的处理多客户端的请求，主要使用的是IO多路复用和非阻塞IO；
3 对于Redis系统来说，主要的性能瓶颈是内存或者网络带宽而并非 CPU。

2、为啥加入多线程

1、单线程的问题

正常情况下使用 del 指令可以很快的删除数据
而当被删除的 key 是一个非常大的对象时，例如时包含了成千上万个元素的 hash 集合时，那么 del 指令就会造成 Redis 主线程卡顿。


这就是redis3.x单线程时代最经典的故障，大key删除的头疼问题，


由于redis是单线程的，del  bigKey .....
等待很久这个线程才会释放，类似加了一个synchronized锁，你可以想象高并发下，程序堵成什么样子？

2、解决办法
使用惰性删除可以有效的避免redis卡顿的问题

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


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

3、redis6/7多线程特性和IO多路复用

3.1、redis主要的性能瓶颈是内存或者网络带宽而非CPU

3.2、redis6/7真正多线程登场

在Redis6/7中，非常受关注的第一个新特性就是多线程。
这是因为，Redis一直被大家熟知的就是它的单线程架构，虽然有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF重写）。
但是，从网络IO处理到实际的读写命令处理，都是由单个线程完成的。


随着网络硬件的性能提升，Redis的性能瓶颈有时会出现在网络IO的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度,
为了应对这个问题:
采用多个IO线程来处理网络请求，提高网络请求处理的并行度，Redis6/7就是采用的这种方法。
但是，Redis的多IO线程只是用来处理网络请求的，对于读写操作命令Redis仍然使用单线程来处理。
这是因为，Redis处理请求时，网络处理经常是瓶颈，通过多个IO线程并行处理网络操作，可以提升实例的整体处理性能。
而继续使用单线程执行命令操作，就不用为了保证Lua脚本、事务的原子性，额外开发多线程互斥加锁机制了(不管加锁操作处理)，这样一来，Redis线程模型实现就简单了

3.3、主线程和IO线程是协作完成请求处理

3.4、Unix网络编程中的五种IO模型

Blocking IO 阻塞IO
NoneBlocking IO 非阻塞IO
IO Multiplexing IO多路复用
signal driven IO 信号驱动IO
asynchronous IO 异步IO


IO多路复用
一个服务端进程可以同时处理多个套接字描述符
实现IO多路复用的模型有3种：select-->poll-->epoll三个阶段来描述


模拟一个tcp服务器处理30个客户socket。
假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有下面几个选择：
第一种选择(轮询)：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有一个学生卡住，全班都会被耽误,你用循环挨个处理socket，根本不具有并发能力。
第二种选择(来一个new一个，1对1服务)：你创建30个分身线程，每个分身线程检查一个学生的答案是否正确。这种类似于为每一个用户创建一个进程或者线程处理连接。
第三种选择(响应式处理，1对多服务)，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。
此时E、A又举手，然后去处理E和A。。。
这种就是IO复用模型。Linux下的select、poll和epoll就是干这个的。


将用户socket对应的文件描述符(FileDescriptor)注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。
此时的socket应该采用非阻塞模式。这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，
收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor反应模式。
在单个线程通过记录跟踪每一个Sockek(I/O流)的状态来同时管理多个I/O流. 一个服务端进程可以同时处理多个套接字描述符。
目的是尽量多的提高服务器的吞吐能力。
大家都用过nginx，nginx使用epoll接收请求，ngnix会有很多链接进来， epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。
redis类似同理，这就是IO多路复用原理，有请求就响应，没请求不打扰。

3.5、简单说明

redis工作线程是单线程的
但是整个redis来说，是多线程的

4、redis7如何开启多线程

1.设置io-thread-do-reads配置项为yes，表示启动多线程。
2。设置线程个数。
关于线程数的设置，官方的建议是如果为 4 核的 CPU，建议线程数设置为 2 或 3，如果为 8 核 CPU 建议线程数设置为 6，线程数一定要小于机器核数，线程数并不是越大越好。

5、总结

Redis自身出道就是优秀，基于内存操作、数据结构简单、多路复用和非阻塞 I/O、避免了不必要的线程上下文切换等特性，在单线程的环境下依然很快；
但对于大数据的 key 删除还是卡顿厉害，因此在 Redis 4.0 引入了多线程unlink key/flushall async 等命令，主要用于 Redis 数据的异步删除；
而在 Redis6/7中引入了 I/O 多线程的读写，这样就可以更加高效的处理更多的任务了，Redis 只是将 I/O 读写变成了多线程
而命令的执行依旧是由主线程串行执行的，因此在多线程下操作 Redis 不会出现线程安全的问题。
Redis 无论是当初的单线程设计，还是如今与当初设计相背的多线程，目的只有一个：让 Redis 变得越来越快。