天津 公司网站建设,用python网站开发,万达网站建设,二手交易网站开发方式#x1f603; 个人学习笔记#xff0c;不喜勿喷#xff0c;望大佬指正#xff01; 目录 一、Redis为什么选择单线程1. 是什么#xff1f;2. why#xff0c;为什么之前选择单线程#xff1f;3. 作者原话使用单线程原因#xff0c;官网证据 二、 为什么逐渐加入多线程特性… 个人学习笔记不喜勿喷望大佬指正 目录 一、Redis为什么选择单线程1. 是什么2. why为什么之前选择单线程3. 作者原话使用单线程原因官网证据 二、 为什么逐渐加入多线程特性1. 单线程也有苦恼举个例子2. 如何解决 redis6/7的多线程特性和IO多路复用入门对于Redis 主要的性能瓶颈是内存或者网络带宽而并非 C P U 。 \textcolor{red}{\large 主要的性能瓶颈是内存或者网络带宽而并非 CPU。} 主要的性能瓶颈是内存或者网络带宽而并非CPU。3. 所以Redis的瓶颈可以初步定为网络IOUnix网络编程中的五种IO模型4. 场景体验说人话引出epoll小总结5. 面试题redis为什么这么快6. 简单说明7. 结论 三、 Redis7是否开启了多线程1. 如何开启? 什么时候适合开启2. 总结 一、Redis为什么选择单线程
1. 是什么 这种问法其实并不严谨为啥这么说呢 \textcolor{blue}{\large 这种问法其实并不严谨为啥这么说呢} 这种问法其实并不严谨为啥这么说呢
Redis的版本很多3.x、4.x、6.x版本不同架构也是不同的不限定版本问是否单线程也不太严谨。
1 版本3.x 最早版本也就是大家口口相传的redis是单线程。
2 版本4.x严格意义来说也不是单线程而是负责处理客户端请求的线程是单线程但是开始加了点多线程的东西(异步删除)。---貌似
3 2020年5月版本的6.0.x后及2022年出的7.0版本后告别了大家印象中的单线程用一种全新的多线程来解决问题。---实锤有几个里程碑式的重要版本 \textcolor{blue}{\large 有几个里程碑式的重要版本} 有几个里程碑式的重要版本 5.0版本是直接升级到6.0版本对于这个激进的升级Redis之父antirez表现得很有信心和兴奋所以第一时间发文来阐述6.0的一些重大功能”Redis 6.0.0 GA is out!” 当然 R e d i s 7.0 后版本更加厉害 \textcolor{red}{\large 当然Redis7.0后版本更加厉害} 当然Redis7.0后版本更加厉害
2. why为什么之前选择单线程 理清一个事实通常说 R e d i s 是单线程究竟何意 \textcolor{green}{\large 理清一个事实通常说Redis是单线程究竟何意} 理清一个事实通常说Redis是单线程究竟何意
Redis是单线程主要是指Redis的网络IO和键值对读写是由一个线程来完成的Redis在处理客户端的请求时包括获取(socket 读)、解析、执行、内容返回(socket 写) 等都由一个顺序串行的主线程处理这就是所谓的“单线程”。这也是Redis对外提供键值存储服务的主要流程。 但Redis的其他功能 比如持久化 R D B 、 A O F 、异步删除、集群数据同步等等其实是由额外的线程执行的。 R e d i s 命令工作线程是单线程的但是整个 R e d i s 来说是多线程的 \textcolor{red}{比如持久化RDB、AOF、异步删除、集群数据同步等等其实是由额外的线程执行的。Redis \\命令工作线程是单线程的但是整个Redis来说是多线程的} 比如持久化RDB、AOF、异步删除、集群数据同步等等其实是由额外的线程执行的。Redis命令工作线程是单线程的但是整个Redis来说是多线程的 请说说演进变化情况 \textcolor{green}{\large 请说说演进变化情况} 请说说演进变化情况
QRedis3.X单线程时代但是性能依旧很快的主要原因
A
基于内存操作: Redis 的所有数据都存在内存中因此所有的运算都是内存级别的所以他的性能比较高 数据结构简单:Redis 的数据结构是专门设计的而这些简单的数据结构的查找和操作的时间大部分复杂度都是 0(1)因此性能比较高
多路复用和非阻塞 I/O: Redis使用 I/O多路复用功能来监听多个 socket连接客户端这样就可以使用一个线程连接来处理多个请求减少线程切换带来的开销同时也避免了 I/O 阻塞操作
避免上下文切换:因为是单线程模型因此就避免了不必要的上下文切换和多线程竞争这就省去了多线程切换带来的时间和性能上的消耗而且单线程不会导致死锁问题的发生
3. 作者原话使用单线程原因官网证据
官网https://redis.io/docs/getting-started/faq/
旧版本Redis官网说明说Redis就是单线程 Redis是单线程的。如何利用多个CPU /内核? CPU并不是您使用Redis的瓶颈因为通常Redis要么受内存限制要么受网络限制。例如使用在平均Linux系统上运行的流水线Redis每秒可以发送一百万个请求因此如果您的应用程序主要使用O(N)或O(log(N) )命令则几乎不会使用过多的CPU。
但是为了最大程度地利用CPU您可以在同一框中启动多个Redis实例并将它们视为不同的服务器。在某个时候单个盒子可能还不够因此如果您要使用多个CPU则可以开始考虑更早地进行分片的某种方法。您可以在“分区”页面中找到有关使用多个Redis实例的更多信息。
但是在Redis 4.0中我们开始使Redis具有更多线程目前这仅限于在后台删除对象以及阻正通过Redis模块实现的命令。对于将来的版本计划是使Redis越来越线程化。
他的大体意思是说 Redis 是基于内存操作的 因此他的瓶颈可能是机器的内存或者网络带宽而并非 C P U \textcolor{red}{\large 因此他的瓶颈可能是机器的内存或者网络带宽而并非 CPU} 因此他的瓶颈可能是机器的内存或者网络带宽而并非CPU既然 CPU 不是瓶颈那么自然就采用单线程的解决方案了况且使用多线程比较麻烦。 但是在 R e d i s 4.0 中开始支持多线程了例如后台删除、备份等功能。 \textcolor{red}{\large 但是在 Redis 4.0 中开始支持多线程了例如后台删除、备份等功能。} 但是在Redis4.0中开始支持多线程了例如后台删除、备份等功能。
新版本Redis官网原话去掉了单线程的 R e d i s 4.0 之前 \textcolor{red}{\large Redis4.0之前} Redis4.0之前一直采用单线程的主要原因有以下三个
使用单线程模型是 Redis 的开发和维护更简单因为单线程模型方便开发和调试;即使使用单线程模型也并发的处理多客户端的请求主要使用的是IO多路复用和非阻塞IO对于Redis系统来说 主要的性能瓶颈是内存或者网络带宽而并非 C P U 。 \textcolor{red}{\large 主要的性能瓶颈是内存或者网络带宽而并非 CPU。} 主要的性能瓶颈是内存或者网络带宽而并非CPU。
二、 为什么逐渐加入多线程特性
1. 单线程也有苦恼举个例子
正常情况下使用 del 指令可以很快的删除数据而当被删除的 key 是一个非常大的对象时例如key包含了成千上万个元素的 hash 集合时那么 del 指令就会造成 Redis 主线程卡顿。 这就是 r e d i s 3. x 单线程时代最经典的故障大 k e y 删除的头疼问题 \textcolor{red}{\large 这就是redis3.x单线程时代最经典的故障大key删除的头疼问题} 这就是redis3.x单线程时代最经典的故障大key删除的头疼问题由于redis是单线程的del bigKey …
等待很久这个线程才会释放类似加了一个synchronized锁你可以想象高并发下程序堵成什么样子?
2. 如何解决 使用惰性删除可以有效的解决性能问题 案例 比如当我(Redis)需要删除一个很大的数据时因为是单线程原子命令操作这就会导致 Redis 服务卡顿于是在 Redis 4.0 中就新增了多线程的模块当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的。 unlink keyflushdb asyncflushall async把删除工作交给了后台的子线程异步删除数据了因为Redis是单个主线程处理redis之父antirez一直强调Lazy Redis is better Redis。 而lazy free的本质就是把某些cost(主要时间复杂度占用主线程cpu时间片)较高删除操作从redis主线程剥离让bio子线程来处理极大地减少主线阻塞时间。从而减少删除导致性能和稳定性问题。 在Redis4.0就引入了多个线程来实现数据的异步惰性删除等功能但是其处理读写请求的仍然只有一个线程所以仍然算是狭义上的单线程。
redis6/7的多线程特性和IO多路复用入门
对于Redis 主要的性能瓶颈是内存或者网络带宽而并非 C P U 。 \textcolor{red}{\large 主要的性能瓶颈是内存或者网络带宽而并非 CPU。} 主要的性能瓶颈是内存或者网络带宽而并非CPU。 3. 所以Redis的瓶颈可以初步定为网络IO r e d i s 6 / 7 真正的多线程登场 \textcolor{red}{\large redis6/7真正的多线程登场} redis6/7真正的多线程登场 在 R e d i s 6 / 7 中非常受关注的第一个新特性就是多线程。 \textcolor{red}{在Redis6/7中非常受关注的第一个新特性就是多线程。} 在Redis6/7中非常受关注的第一个新特性就是多线程。 这是因为Redis一直被大家熟知的就是它的单线程架构虽然有些命令操作可以用后台线程或子进程执行(比如数据删除、快照生成、AOF重写)但是从网络IO处理到实际的读写命令处理都是由单个线程完成的。 随着网络硬件的性能提升Redis的性能瓶颈有时会出现在网络IO的处理上也就是说单个主线程处理网络请求的速度跟不上底层网络硬件的速度 为了应对这个问题: 采用多个 I O 线程来处理网络请求提高网络请求处理的并行度 R e d i s 6 / 7 就是采用的这种方法。 \textcolor{red}{采用多个IO线程来处理网络请求提高网络请求处理的并行度Redis6/7就是采用的这种方法。} 采用多个IO线程来处理网络请求提高网络请求处理的并行度Redis6/7就是采用的这种方法。 但是Redis的多IO线程只是用来处理网络请求的对于读写操作命今Redis仍然使用单线程来处理。这是因为Redis处理请求时网络处理经常是瓶颈通过多个IO线程并行处理网络操作可以提升实例的整体处理性能。而继续使用单线程执行命今换作就不用为了保证Lua脚本、事各的原子性额外开发多线程 互斥加锁机制了 ( 不管加锁操作处理 ) \textcolor{red}{互斥加锁机制了(不管加锁操作处理)} 互斥加锁机制了(不管加锁操作处理)这样一来Redis线程模型实现就简单了 主线程和IO线程怎么协作完成请求处理的-精讲版 四个阶段
Unix网络编程中的五种IO模型 Blocking IO - 阻塞IO NoneBlocking IO - 非阻塞IO IO multiplexing - IO 多路复用 Linux世界一切皆是文件 文件描述符简称FD句柄 FileDescriptor文件描述符 (File descriptor)是计算机科学中的一个术语是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上它是一个索引值指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时内核向进程返回一个文件描述符。在程序设计中文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。 首次浅谈IO多路复用IO多路复用是什么 一种同步的IO模型实现一个线程监视多个文件句柄,一旦某个文件句柄就绪就能够通知到对应应用程序进行相应的读写操作没有文件句柄就绪时就会阻塞应用程序从而释放CPU资源 概念 l/O网络I/O尤其在操作系统层面指数据在内核态和用户态之间的读写操作 多路多个客户端连接(连接就是套接字描述符即 socket 或者 channel) 复用复用一个或几个线程 lO多路复用也就是说一个或一组线程处理多个TCP连接使用单进程就能够实现同时处理多个客户端的连接无需创建或者维护过多的进程/线程 一句话一个服务端进程可以同时处理多个套接字描述符。 实现IO多路复用的模型有3种: 可以分select-poll-epoll三个阶段来描述。 signal driven IO - 信号驱动IO asynchronous IO - 异步IO
4. 场景体验说人话引出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就是干这个的。 IO多路复用模型简单明了版理解 将用户socket对应的文件描述符(FileDescriptor)注册进epoll然后epoll帮你监听哪些socket上有消息到达这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。这样整个过程只在调用select、poll、epoll这些调用的时候才会阻塞收发客户消息是不会阻塞的整个进程或者线程就被充分利用起来这就是事件驱动所谓的reactor反应模式。 在单个线程通过记录跟踪每一个Sockek(I/0流)的状态来同时管理多个I/0流一个服务端进程可以同时处理多个套接字描述符。 目的是尽量多的提高服务器的吞吐能力。 大家都用过nginxnginx使用epoll接收请求ngnix会有很多链接进来epoll会把他们都监视起来然后像拨开关一样谁有数据就拨向谁然后调用相应的代码处理。redis类似同理这就是IO多路复用原理有请求就响应没请求不打扰。 小总结 只使用一个服务端进程可以同时处理多个套接字描述符连接
5. 面试题redis为什么这么快
IO多路复用epoll函数使用才是redis为什么这么快的直接原因而不是仅仅单线程命令redis安装在内存中。
6. 简单说明
Redis工作线程是单线程的但是整个Redis来说是多线程的
主线程和IO线程怎么协作完成请求处理的-精简版
I/O 的读和写本身是堵塞的比如当 socket 中有数据时Redis 会通过调用先将数据从内核态空间拷贝到用户态空间再交给 Redis 调用而这个拷贝的过程就是阻塞的当数据量越大时拷贝所需要的时间就越多而这些操作都是基于单线程完成的。 从Redis6开始就新增了多线程的功能来提高 I/O 的读写性能他的主要实现思路是将主线程的 I/O 读写任务拆分给一组独立的线程去执行这样就可以使多个 socket 的读写可以并行化了采用多路 I/0 复用技术可以让单个线程高效的处理多个连接请求 (尽量减少网络IO的时间消耗》将最耗时的Socket的读取、请求解析、写入单独外包出去剩下的命令执行仍然由主线程串行执行并和内存的数据交互。 结合上图可知网络IO操作就变成多线程化了其他核心部分仍然是线程安全的是个不错的折中办法。
7. 结论
Redis6 - 7将网络数据读写、请求协议解析通过多个IO线程的来处理对于真正的命令执行来说仍然使用主线程操作一举两得 三、 Redis7是否开启了多线程
1. 如何开启? 什么时候适合开启
如果你在实际应用中发现Redis实例的CPU开销不大但吞吐量却没有提升可以考虑使用Redis7的多线程机制加速网络处理进而提升实例的吞吐量
Redis7将所有数据放在内存中内存的响应时长大约为100纳秒对于小数据包Redis服务器可以处理8W到10W的QPS。这也是Redis处理的极限了对于80%的公司来说单线程的Redis已经足够使用了。设置io-thread-do-reads配置项为yes表示启动多线程。设置线程个数。关于线程数的设置官方的建议是如果为4核的CPU建议线程数设置为2或3如果为8核CPU建议线程数设置为6安程数一定要小于机器核数线程数并不是越大越好。
2. 总结
Redis自身出道就是优秀基于内存操作、数据结构简单、多路复用和非阻塞I/O、避免了不必要的线程上下文切换等特性在单线程的环境下依然很快
但对于大数据的 key删除还是卡顿厉害因此在Redis 4.0引入了多线程unlink key/flushall async等命令主要用于Redis 数捷的异步删除
而在Redis6/7中引入了I/0多线程的读写这样就可以更加高效的处理更多的任务了Redis只是将I/O读写变成了多线程而命令的执行依旧是由主线程串行执行的因此在多线程下操作 Redis不会出现线程安全的问题。
Redis无论是当初的单线程设计还是如今与当初设计相背的多线程目的只有一个:让 Redis变得越来越快。
