做一个企业网站大概需要多少钱,qq网页版登录网址,山西省建设厅网站首页6,无法分享到wordpress文章目录 面试题Redis为什么选择单线程为什么逐渐加入多线程特性Redis6、Redis7的多线程特性和IO多路复用入门Redis7多线程 面试题
Redis到底是单线程还是多线程#xff1f;IO多路复用听说过吗#xff1f;Redis为什么这么快#xff1f;
Redis为什么选择单线程
其实Redis单… 文章目录 面试题Redis为什么选择单线程为什么逐渐加入多线程特性Redis6、Redis7的多线程特性和IO多路复用入门Redis7多线程 面试题
Redis到底是单线程还是多线程IO多路复用听说过吗Redis为什么这么快
Redis为什么选择单线程
其实Redis单线程这个问法并不严谨为什么这么说呢Redis的版本很多3.x、4.x、6.x版本不同架构也是不同的不限定版本问是否单线程也不太严谨。 版本3.x 最早版本也就是大家口口相传的redis是单线程。版本4.x严格意义来说也不是单线程而是负责处理客户端请求的线程是单线程但是开始加了点多线程的东西(异步删除)。—貌似2020年5月版本的6.0.x后及2022年出的7.0版本后告别了大家印象中的单线程用一种全新的多线程来解决问题。—实锤 有几个里程碑式的重要版本5.0版本是直接升级到6.0版本对于这个激进的升级Redis之父antirez表现得很有信心和兴奋所以第一时间发文来阐述6.0的一些重大功能 “Redis 6.0.0 GA is out!”。当然Redis7.0后版本更加厉害。 为什么Redis会选择单线程通常说Redis是单线程究竟何意Redis是单线程主要是指Redis的网络IO和键值对读写是由一个线程来完成的Redis在处理客户端的请求时包括获取(socket 读)、解析、执行、内容返回(socket 写) 等都由一个顺序串行的主线程处理这就是所谓的“单线程”。这也是Redis对外提供键值存储服务的主要流程。但Redis的其他功能比如持久化RDB、AOF、异步删除、集群数据同步等等其实是由额外的线程执行的。Redis 命令工作线程是单线程的但是整个Redis来说是多线程的。Redis最核心的功能是对外提供键值存储服务也就是客户端发请求Redis执行请求返回结果。这个过程中的主要步骤是 从 socket 读取请求解析协议执行命令比如 GET、SET、ZADD 等操作 Redis 内存中的数据结构把结果通过 socket 写回客户端 上述整个流程是由 一个线程主线程串行完成的不会有多个线程同时操作内存中的数据结构因此 Redis 命令执行过程天然是“原子性”的不需要加锁。所以说 Redis 是单线程特指这一条主流程命令执行流程是单线程。 请说说演进变化情况QRedis3.X单线程时代但是性能依旧很快的主要原因A回答如下 基于内存操作: Redis 的所有数据都存在内存中因此所有的运算都是内存级别的所以他的性能比较高数据结构简单:Redis 的数据结构是专门设计的而这些简单的数据结构的查找和操作的时间大部分复杂度都是 0(1)因此性能比较高多路复用和非阻塞 I/O: Redis使用 I/O多路复用功能来监听多个 socket连接客户端这样就可以使用一个线程连接来处理多个请求减少线程切换带来的开销同时也避免了 I/O 阻塞操作避免上下文切换:因为是单线程模型因此就避免了不必要的上下文切换和多线程竞争这就省去了多线程切换带来的时间和性能上的消耗而且单线程不会导致死锁问题的发生。 作者原话使用单线程原因官网证据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 是基于内存操作的因此他的瓶颈可能是机器的内存或者网络带宽而并非 CPU既然 CPU 不是瓶颈那么自然就采用单线程的解决方案了况且使用多线程比较麻烦。但是在 Redis 4.0 中开始支持多线程了例如后台删除、备份等功能。新版本Redis官网原话去掉了单线程的 Redis4.0之前一直采用单线程的主要原因有以下三个 使用单线程模型是 Redis 的开发和维护更简单因为单线程模型方便开发和调试;即使使用单线程模型也并发的处理多客户端的请求主要使用的是IO多路复用和非阻塞IO对于Redis系统来说主要的性能瓶颈是内存或者网络带宽而并非 CPU。
为什么逐渐加入多线程特性
单线程也有苦恼举个例子正常情况下使用 del 指令可以很快的删除数据而当被删除的 key 是一个非常大的对象时例如key包含了成千上万个元素的 hash 集合时那么 del 指令就会造成 Redis 主线程卡顿。这就是redis3.x单线程时代最经典的故障big key删除的头疼问题由于由于redis是单线程的del bigKey …等待很久这个线程才会释放类似加了一个synchronized锁你可以想象高并发下程序堵成什么样子?如何解决使用惰性删除可以有效的解决性能问题。案例比如当 Redis 需要删除一个很大的数据时因为是单线程原子命令操作这就会导致 Redis 服务卡顿于是在 Redis 4.0 中就新增了多线程的模块当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的。
unlink key
flushdb async
flushall async上面三条指令都是 Redis 里用于删除键或清空数据库的命令它们有一个共同特点把删除工作交给了后台的子线程异步删除数据都可以异步删除不会阻塞主线程大大减少对 Redis 性能的影响。因为Redis是单个主线程处理redis之父antirez一直强调 “Lazy Redis is better Redis”。而 lazy free 的本质就是把某些cost主要时间复杂度占用主线程cpu时间片较高删除操作从redis主线程剥离让bio子线程来处理极大地减少主线阻塞时间。从而减少删除导致性能和稳定性问题。什么是 Lazy FreeLazy Free延迟释放/惰性释放是 Redis 4.0 引入的一个删除策略优化。它不是改变“逻辑删除”过程主线程依然快速 取消引用而是把真正释放内存的过程放到后台线程bio 子线程中完成。bio 是什么bio Background I/O。它是 Redis 内部实现的一个后台 I/O 线程机制专门用来做一些耗时、不可阻塞主线程的 I/O 操作避免影响 Redis 主线程的实时性能。bio 不是操作系统的 BIO/Buffered I/O 概念Redis 里的 bio 是一个模块管理一组后台 worker 线程。在Redis4.0就引入了多个线程来实现数据的异步惰性删除等功能但是其处理读写请求的仍然只有一个线程所以仍然算是狭义上的单线程。
Redis6、Redis7的多线程特性和IO多路复用入门
前面我们已经提到对于Redis主要的性能瓶颈是内存或者网络带宽而并非 CPU。所以Redis的瓶颈可以初步定为网络IO。Redis6/7真正的多线程登场在Redis6/7中非常受关注的第一个新特性就是多线程。这是因为Redis一直被大家熟知的就是它的单线程架构虽然有些命令操作可以用后台线程或子进程执行比如数据删除、快照生成、AOF重写但是从网络IO处理到实际的读写命令处理都是由单个线程完成的。随着网络硬件的性能提升Redis的性能瓶颈有时会出现在网络IO的处理上也就是说单个主线程处理网络请求的速度跟不上底层网络硬件的速度。为了应对这个问题采用多个IO线程来处理网络请求提高网络请求处理的并行度Redis6/7就是采用的这种方法。但是Redis的多IO线程只是用来处理网络请求的对于读写操作命今Redis仍然使用单线程来处理。这是因为Redis处理请求时网络处理经常是瓶颈通过多个IO线程并行处理网络操作可以提升实例的整体处理性能。而继续使用单线程执行命今换作就不用为了保证Lua脚本、事各的原子性额外开发多线程互斥加锁机制了不管加锁操作处理这样一来Redis线程模型实现就简单了。主线程和IO线程怎么协作完成请求处理的——四个阶段 这张图其实是一个典型的服务端 I/O 多线程处理流程图它分为主线程和IO线程两部分配合右侧文字说明其实描述的是一种请求处理模型通常用在高性能服务器里。 当有客户端请求到达时主线程只是负责接收请求然后把 Socket 交给 IO 线程来处理实际的读写主线程避免被 IO 阻塞。 主线程做轻量工作 → IO 线程做重活读数据、业务处理→ 主线程继续执行其他请求。 主线程部分左侧 接收连接请求主线程监听端口有客户端连接就 accept拿到一个 Socket。将 Socket 放入全局等待队列把新建立的 Socket 放到一个全局队列里防止处理不过来导致丢包或阻塞主线程。以轮询方式将 Socket 连接分配给 IO 线程主线程把队列里的 Socket 按轮询或者负载均衡分配给 IO 线程。等待 IO 线程完成读取和数据解析分配完之后主线程等待 IO 线程完成对这个 Socket 的数据读取 解析。执行请求命令操作IO 线程解析出具体的请求比如用户要查数据库交给主线程来做业务处理。请求命令操作执行完成主线程完成业务处理响应发回客户端。 IO 线程部分右侧 开始执行主线程分配 Socket 后IO 线程接管。绑定线程IO 线程“绑定”到这个 Socket负责读数据。读取 Socket 数据 解析IO 线程读取 Socket 中的数据解析出请求内容。并行/异步执行请求根据需要可能直接执行请求也可能转交回主线程执行。请求完成IO 线程标记请求处理完成准备处理下一个。 阶段一主线程主要负责建立连接拿到 Socket放到等待队列交由 IO 线程处理。 阶段二IO 线程处理 Socket 数据读取避免主线程阻塞。 阶段三IO 线程完成解析后主线程或者 IO 线程执行请求通常是主线程做复杂业务逻辑。 阶段四IO 线程完成请求处理后 Socket 解绑准备下一个请求。
客户端请求进来↓
主线程 accept → 得到 Socket↓
放入等待队列 or 直接分配给 IO 线程↓
IO 线程绑定 Socket开始 read↓
读数据 → 解析请求 → 处理请求可能交主线程/业务线程池处理↓
写响应 → 关闭/复用 Socket主线程 接收连接 分发任务不阻塞 IO 线程 处理 IO 解析协议 执行请求 主线程 只负责高性能接入避免自己被任何一个慢请求卡死 这个模型中主线程只负责接收新连接并分发 Socket 给 IO 线程主线程自身不做耗时 IO 操作IO 线程负责绑定 Socket完成数据的读写、请求解析和响应发送通过这种分工实现高并发、高性能处理主线程始终保持“轻盈”不会被单个慢请求拖慢整体性能。 主线程负责接入和分发IO 线程负责读写和处理解耦接入与IO提升系统吞吐量。 主线程只负责连接接入和 socket 分发IO 线程独立负责 socket 的读写和请求处理主线程永远不阻塞等待 IO 线程结果IO 线程直接写回客户端响应。 Unix网络编程中的五种IO模型 Blocking IO - 阻塞IONoneBlocking IO - 非阻塞IOIO 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 - 信号驱动IOasynchronous IO - 异步IO 场景体验说人话引出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多路复用原理有请求就响应没请求不打扰。小总结只使用一个服务端进程可以同时处理多个套接字描述符连接面试题redis为什么这么快IO多路复用epoll函数使用才是redis为什么这么快的直接原因而不是仅仅单线程命令redis安装在内存中。简单说明 Redis工作线程是单线程的但是整个Redis来说是多线程的主线程和IO线程怎么协作完成请求处理的-精简版I/O 的读和写本身是堵塞的比如当 socket 中有数据时Redis 会通过调用先将数据从内核态空间拷贝到用户态空间再交给 Redis 调用而这个拷贝的过程就是阻塞的当数据量越大时拷贝所需要的时间就越多而这些操作都是基于单线程完成的。从Redis6开始就新增了多线程的功能来提高 I/O 的读写性能他的主要实现思路是将主线程的 I/O 读写任务拆分给一组独立的线程去执行这样就可以使多个 socket 的读写可以并行化了采用多路 I/0 复用技术可以让单个线程高效的处理多个连接请求 (尽量减少网络IO的时间消耗》将最耗时的Socket的读取、请求解析、写入单独外包出去剩下的命令执行仍然由主线程串行执行并和内存的数据交互。结合图可知网络IO操作就变成多线程化了其他核心部分仍然是线程安全的是个不错的折中办法。 结论Redis6 - 7将网络数据读写、请求协议解析通过多个IO线程的来处理对于真正的命令执行来说仍然使用主线程操作一举两得 Redis 的基本 IO 处理模型 Redis 设计目标是简单、可预期延迟不是极端追求高并发吞吐。主线程 完成所有命令处理保证线程安全。IO 线程只辅助做socket 的读/写不会改内部数据结构否则要加锁。 Redis 的标准工作流程Redis 6.0 之后支持 IO 多线程之前完全单线程 没有启用 IO 多线程完全单线程 → 非常简单、性能也很好因为 Redis 是内存数据库命令快单线程足够。启用 IO 多线程从 Redis 6.0 开始可以配置 io-threadsRedis 启用 IO 多线程后分成两部分——1、IO 线程负责 read/write socket但是不解析命令、不执行命令。2、主线程执行所有命令逻辑改 Redis 内部状态。
# 没有启用 IO 多线程
主线程:accept socketread socket → 解析协议 → 执行命令 → write socket# 启用 IO 多线程
主线程:accept socketdispatch read 任务给 IO 线程IO 线程:read socket 数据 → 把读到的请求 buffer 交回主线程主线程:解析协议 → 执行命令 → 生成响应主线程:dispatch write 任务给 IO 线程IO 线程:write socket 返回响应解析协议 执行命令Redis 仍然是主线程干IO 线程只是做纯 IO 操作read socket → 填 bufferwrite socket → 发送响应。为什么这样设计保证 Redis 内部数据结构始终只被主线程访问完全避免加锁。只用多线程加速网络 IO 部分不影响主线程的数据一致性。主线程负责解析命令 执行命令 生成响应I/O 线程如果启用只负责读 socket 到 buffer、把 buffer 里的结果写回 socket不参与解析和执行逻辑。
Redis7多线程
如果你在实际应用中发现Redis实例的CPU开销不大但吞吐量却没有提升可以考虑使用Redis7的多线程机制加速网络处理进而提升实例的吞吐量Redis7将所有数据放在内存中内存的响应时长大约为100纳秒对于小数据包Redis服务器可以处理8W到10W的QPS。这也是Redis处理的极限了对于80%的公司来说单线程的Redis已经足够使用了。 设置 io-thread-do-reads 配置项为yes表示启动多线程。设置线程个数。关于线程数的设置官方的建议是如果为4核的CPU建议线程数设置为2或3如果为8核CPU建议线程数设置为6安程数一定要小于机器核数线程数并不是越大越好。总结 Redis自身出道就是优秀基于内存操作、数据结构简单、多路复用和非阻塞I/O、避免了不必要的线程上下文切换等特性在单线程的环境下依然很快但对于大数据的 key删除还是卡顿厉害因此在Redis 4.0引入了多线程 unlink key / flushall async 等命令主要用于Redis 数据的异步删除而在Redis6/7中引入了I/O多线程的读写这样就可以更加高效的处理更多的任务了Redis只是将I/O读写变成了多线程而命令的执行依旧是由主线程串行执行的因此在多线程下操作 Redis不会出现线程安全的问题。Redis无论是当初的单线程设计还是如今与当初设计相背的多线程目的只有一个让 Redis变得越来越快。
