查看原文
其他

Redis为什么又引入了多线程?单线程不香了?

The following article is from 愚公要移山 Author 冯冬冬


关注公众号后台回复paymall获取实战项目资料+视频

相信你一定不止一次见过Redis是单线程模式,不过说实话那只是个老版本,这个问题是一位老哥的大厂面试题,跟我分享了一下。想着自己就知道redis6.0以前一直都是单线程,到了6的版本才加入了多线程,还不是很清楚,在多方打听并且搜索之下总结了这篇文章。

一、问题概述

Redis 6.0 之后的版本抛弃了单线程模型这一设计,原本使用单线程运行的 Redis 也开始选择性使用多线程模型,乍一看Redis的作者这么牛,也逃不过“真香定律”,

仔细想想,这个问题其实可以拆分,拆分为两个主要的问题:

(1)为什么 Redis 一开始选择单线程模型(单线程的好处)?

(2)为什么 Redis 在 6.0 之后加入了多线程(在某些情况下,单线程出现了缺点,多线程可以解决)?

其实,作者并不是没有逃脱真香定理,而是随着时间的推移,出现的问题也越来越多,原来的设计肯定就有些不合时宜,该做出改变就做出改变。OK,带着俩问题,我们就来好好地分析一下。

二、为什么Redis一开始使用单线程

不管是单线程或者是多线程都是为了提升Redis的开发效率,因为Redis是一个基于内存的数据库,还要处理大量的外部的网络请求,这就不可避免的要进行多次IO。好在Redis使用了很多优秀的机制来保证了它的高效率。那么为什么Redis要设计成单线程模式的呢?可以总结如下:

(1)IO多路复用

我们来看一下Redis顶层设计。

FD是一个文件描述符,意思是表示当前文件处于可读、可写还是异常状态。使用 I/O 多路复用机制同时监听多个文件描述符的可读和可写状态。你可以理解为具有了多线程的特点。

一旦受到网络请求就会在内存中快速处理,由于绝大多数的操作都是纯内存的,所以处理的速度会非常地快。也就是说在单线程模式下,即使连接的网络处理很多,因为有IO多路复用,依然可以在高速的内存处理中得到忽略。

(2)可维护性高

多线程模型虽然在某些方面表现优异,但是它却引入了程序执行顺序的不确定性,带来了并发读写的一系列问题。单线程模式下,可以方便地进行调试和测试。

(3)基于内存,单线程状态下效率依然高

多线程能够充分利用CPU的资源,但对于Redis来说,由于基于内存速度那是相当的高,能达到在一秒内处理10万个用户请求,如果一秒十万还不能满足,那我们就可以使用Redis分片的技术来交给不同的Redis服务器。这样的做饭避免了在同一个 Redis 服务中引入大量的多线程操作。

而且基于内存,除非是要进行AOF备份,否则基本上不会涉及任何的 I/O 操作。这些数据的读写由于只发生在内存中,所以处理速度是非常快的;用多线程模型处理全部的外部请求可能不是一个好的方案。

现在我们知道了基本上可以总结成两句话,基于内存而且使用多路复用技术,单线程速度很快,又保证了多线程的特点。因为没有必要使用多线程。

三、为什么引入多线程?

刚刚说了一堆使用单线程的好处,现在话锋一转,又要说为什么要引入多线程,别不适应。引入多线程说明Redis在有些方面,单线程已经不具有优势了。

因为读写网络的read/write系统调用在Redis执行期间占用了大部分CPU时间,如果把网络读写做成多线程的方式对性能会有很大提升。

Redis 的多线程部分只是用来处理网络数据的读写和协议解析,执行命令仍然是单线程。之所以这么设计是不想 Redis 因为多线程而变得复杂,需要去控制 key、lua、事务,LPUSH/LPOP 等等的并发问题。

Redis 在最新的几个版本中加入了一些可以被其他线程异步处理的删除操作,也就是我们在上面提到的 UNLINK、FLUSHALL ASYNC 和 FLUSHDB ASYNC,我们为什么会需要这些删除操作,而它们为什么需要通过多线程的方式异步处理?

我们知道Redis可以使用del命令删除一个元素,如果这个元素非常大,可能占据了几十兆或者是几百兆,那么在短时间内是不能完成的,这样一来就需要多线程的异步支持。

现在删除工作可以在后台进行。

四、总结

Redis 选择使用单线程模型处理客户端的请求主要还是因为 CPU 不是 Redis 服务器的瓶颈,所以使用多线程模型带来的性能提升并不能抵消它带来的开发成本和维护成本,系统的性能瓶颈也主要在网络 I/O 操作上;而 Redis 引入多线程操作也是出于性能上的考虑,对于一些大键值对的删除操作,通过多线程非阻塞地释放内存空间也能减少对 Redis 主线程阻塞的时间,提高执行的效率。

一句话讲完:之前用单线程是因为基于内存速度快,而且多路复用有多路复用的作用,也就是足够了,现在引入是因为在某些操作要优化,比如删除操作,因此引入了多线程。

有热门推荐👇

从此抛弃理try...catch!

Spring Security 真正的前后分离实现
Docker安装Jenkins+Shell脚本自动化部署项目
Mybatis 使用的 9 种设计模式,真是太有用了

Java数组转List的三种方式及对比

推荐一款日志切割神器!我常用~

使用 Stream API 高逼格 优化 Java 代码!

Spring MVC请求处理过程不是两张流程图就能讲清楚的

撸一个简易聊天室,不信你学不会实时消息推送(附源码)

最后分享一套微服务电商项目教程(资料笔记+视频):点击阅读全文获取面试资料+项目实战资料(电商/聚合支付)

SPringCloud微服电商完整务教程

1.框架搭建
- 电商项目介绍
- 微服务环境搭建
- 数据库搭建

2.分布式存储系统
- FastDFS原理讲解
- 文件上传
- 文件下载
3.商品发布
- 表结构梳理
- 代码生成器的使用
- 商品增删改
- 商品查询
4.lua,canal实现广告缓存
- 首页广告表设计
- Lua安装使用讲解
- Nginx限流实战
- Canal安装,原理介绍
- Canal同步数据实现
5.索引搜索
- ES安装讲解
- Kibana安装讲解
- DSL语句
- ES API使用
6.商品搜索
- ES 高级搜索功能
- ES 排序规则

 7.Thymeleaf实现静态页面
- Thymeleat 缓存配置讲解
- 搜索页面讲解
8.微服务网关和Jwt令牌
- 微服务网关Zuul/Gateway介绍
- 网关之负载和限流
- 用户服务搭建
- JWT token讲解
- 网关鉴权
9.Spring Security Oauth2
- 单点登陆介绍
- Oauth2介绍
- 共钥私钥讲解
- 加密算法讲解
10.购物车
- 购物车分析和购物车种类分析
- 订单服务创建
- 购物车功能实现
11.订单
- 用户地址测试
- 下单问题分析,幂等
- 用户积分规则
- 二维码生产讲解
- 微信支付流程及模式讲解
12.微信支付
- 微信支付SDK使用讲解
- 微信支付状态查询
- 内网穿透 花生壳
- 微信支付回调
- rabbitMQ 延时队列讲解
13.秒杀基础
- 秒杀需求分析
- 秒杀服务搭建
- 秒杀之Redis
- 秒杀之多线程
14.秒杀核心
- 重复抢单下单问题
- 超卖问题
- 秒杀支付
15.分布式事物
- 分布式事物介绍
- CAP理论介绍
- 2pc/3pc 机制讲解
- TCC事物补偿
- Seata案列讲解
16.高可用集群
- 分布式和集群概念
- Eureka集群介绍
- Redis 集群介绍
- RabbitMq集群安装

点击阅读原文,前往上面微服务电商教程文档

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存