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