Java最新Redis为什么这么快？一文带你深入理解Redis单线程分析(1)，java开发工程师面试题目

最新推荐文章于 2024-06-13 08:37:22 发布

2401_84002594

最新推荐文章于 2024-06-13 08:37:22 发布

阅读量719

点赞数 10

分类专栏：程序员文章标签： java 面试学习

本文链接：https://blog.csdn.net/2401_84002594/article/details/138716449

版权

程序员专栏收录该内容

208 篇文章 0 订阅

订阅专栏

总结

以上是字节二面的一些问题，面完之后其实挺后悔的，没有提前把各个知识点都复习到位。现在重新好好复习手上的面试大全资料（含JAVA、MySQL、算法、Redis、JVM、架构、中间件、RabbitMQ、设计模式、Spring等），现在起闭关修炼半个月，争取早日上岸！！！

下面给大家分享下我的面试大全资料

第一份是我的后端JAVA面试大全

后端JAVA面试大全

第二份是MySQL+Redis学习笔记+算法+JVM+JAVA核心知识整理

字节二面拜倒在“数据库”脚下，闭关修炼半个月，我还有机会吗？

MySQL+Redis学习笔记算法+JVM+JAVA核心知识整理

第三份是Spring全家桶资料

字节二面拜倒在“数据库”脚下，闭关修炼半个月，我还有机会吗？

MySQL+Redis学习笔记算法+JVM+JAVA核心知识整理

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

redis基本都在进行内存io，那它的瓶颈在io上吗？

redis在网络io上使用epoll实现了一个io多路复用的reactor模型，epoll是非阻塞io，所以避免了cpu阻塞在io上，所以它不是io密集型，瓶颈不在于等待io导致cpu利用率不高，不需要多个线程来屏蔽等待io执行完成的时间。当然redis的io利用率很高，但是io利用率高并不代表它是io密集型，因为它瓶颈不在等待io上。

所以第二点

redis在网络io上使用epoll实现了一个io多路复用的reactor模型使得cpu利用率更高，浪费在io上的时间更少

redis并不需要多线程来提高cpu利用率减少io等待时间，并且单线程架构也比较容易实现，所以顺理成章就采用了单线程架构。

第三点

由于采用了单线程架构，避免了线程线程切换产生的消耗

因为一次CPU上下文的切换大概在 1500ns 左右。

从内存中读取 1MB 的连续数据，耗时大约为 250us，假设1MB的数据由多个线程读取了1000次，那么就有1000次时间上下文的切换，

那么就有1500ns * 1000 = 1500us ，我单线程的读完1MB数据才250us ,你光时间上下文的切换就用了1500us了，我还不算你每次读一点数据的时间

那么redis是cpu密集型吗？答案是否定的。

redis也**不是cpu密集型。**大多数情况下redis机器上的cpu是很够用的。

redis的瓶颈在于内存大小和网络带宽。

如果想要更充分的利用多核cpu，可以采用多个redis实例的方法，同时为了减少线程争用，可以将实例和cpu绑定的方法。

但是如果做了CPU绑定，在rdb和aof时子进程会与父进程共享使用一个CPU。子进程重写时对单核CPU使用率通常在90%以上，父进程与子进程将产生激烈CPU竞争，极大影响Redis稳定性。（解决方法不清楚，也许多绑定一个CPU会好点？）

附录

======

DMA

DMA 传输将数据从一个地址空间复制到另外一个地址空间。当CPU 初始化这个传输动作，传输动作本身是由 DMA 控制器来实行和完成。

典型的例子就是移动一个外部内存的区块到芯片内部更快的内存区。例如磁盘移到内存。

客户端与Redis通信的一次流程

解释说明

①.在Redis启动及初始化的时候,Redis会(预先)将连接应答处理器跟"AE_READABLE"事件关联起来,接着如果一个客户端向Redis发起连接,此时就会产生一个"AE_READABLE"事件,然后由连接应答处理器来处理跟客户端建立连接,创建客户端对应的socket,同时将这个socket的"AE_READABLE"事件跟命令请求处理器关联起来;

②.当客户端向Redis发起请求的时候(不管是读请求还是写请求,都一样),首先就会在之前创建的客户端对应的socket上产生一个"AE_READABLE"事件,然后IO多路复用程序会监听到在之前创建的客户端对应的socket上产生了一个"AE_READABLE"事件,接着把这个socket放入一个队列中排队,然后由文件事件分派器从队列中获取socket交给对应的命令请求处理器来处理(因为之前在Redis启动并进行初始化的时候就已经预先将"AE_READABLE"事件跟命令请求处理器关联起来了).之后命令请求处理器就会从之前创建的客户端对应的socket中读取请求相关的数据,然后在自己的内存中进行执行和处理;