和杠精聊Redis多线程

时间:2022-04-27 05:28:11

周末被一位小同学憋的很窝火。他要和我探讨一下,redis到底是多线程的还是单线程的。这个问题本来比较好解释,但我遇到的却是一个杠精。

答案是显而易见的:redis6,逃不过真香定理,引入了多线程;而在redis6之前,却是单线程的。

也就是说,这不是一个是和否的问题,还涉及到第二维度的版本参与。

可是,这位同学要打我的脸。不知道小姐姐的脸皮很嫩么?摸不得。

“照你的逻辑,redis5是单线程的了?”

“是的。”

“那下面这张截图是怎么回事?”

同学甩给我一张图,并送来一个鄙视的眼神。

和杠精聊Redis多线程

“使用top -Hp 查看。redis5有4个线程。该怎么解释?”

这个问题,我也不知道怎么跟他解释。使用top命令去观测,redis5肯定是多线程的,比如bgsave,aof等,肯定要开启一个线程去操作,否则早就炸了。

按照这个逻辑去说,redis就从来没有单进程过。看着这张图,我陷入了无尽的忧愁。

Redis是否是单进程,主要是针对Redis的读写操作来说的”。但这句话对于杠精并没有什么信服力。

“写程序要严谨,你们这些人都太不严谨了。多线程就是多线程,你应该问'redis的读写操作到底是不是多线程的'”。

我问你个大头鬼。我并不想再和他交流,因为我为自己的博学感到无地自容。

但他接下来的一个问题,却让我陷入了真正的沉思。

1. redis的多线程有多快?

redis的多线程到底有什么性能提升呢?

官方的说法是:possible to easily speedup two times。可能会比较容易的提升到两倍速度。

我英文不太好,对这种英文的修饰感到很迷惑。既然easily了,为什么还有possible。two times,到底是提升了2倍,还是提升到2倍。

官方说,到底能够提升多少,还要看硬件的能力。

官方推荐,只有你的CPU核数,达到4个的时候,才有必要试一试这个多线程的Feature。

不要用土豪的眼睛盯着我,这种4core的配置,已经打死了大多数公司了。所以Redis贴心的把多线程功能是关闭的。(好像有点语病)

我只能求助那些在一线的前同事们。他们有没有在生产环境,用上这划时代的多线程Redis6x呢?

结果很令我满意,没有!

其中有一个回复我特别满意。他说:“你竟然在问一个停留在JDK1.6的我,跑着Windows版本Redis的我,是否用到了Redis6。我还在用着Redis3呢。”

另外一个回复我感到更满意,他说:“滚!”

2. 怎么用?

新技术肯定是要吹捧一下的,否则没人实践踩坑,作为追随者就只能吃翔。

多线程在理论上,肯定是会有性能提升的。一个爸爸赚钱和2个爸爸赚钱,效果自然不一样,只是苦了妈妈了。

Redis6的多线程开启,需要配置一个参数。

io-threads 4 

当开启之后,只有出流量使用多线程,如果你想要入流量也走多线程,那也可以配置以下参数。

io-threads-do-reads yes 

就这么两个参数,可以看到现在的redis多线程,还是稍显寒碜了一些。

我们把它开启之后,仍然使用top -Hp 查看相关进程,可以看到多了3个io_thd进程。

和杠精聊Redis多线程

这部分逻辑,是在networking.c种实现的。这个文件已经达到了3k多行,也是够庞大的了。

3. Redis为什么又搞多线程了

使用redis-benchmark测试,单机单核的吞吐量,能够达到10w+。

1秒是1000000000纳秒,单次内存操作大约是100纳秒左右,那内存操作可以达到1000w/s的速度。那Redis的瓶颈在哪里呢?

使用perf进行追踪,可以发现它的耗时,主要是体现在sys_write系统调用上,也就是向socket写数据。

既然瓶颈找到了,那就把它优化掉。redis选择的方式是使用多线程。

我使用benchmark测试了一下,4core的机器,CPU跑满的时候,QPS达到了16w,并没有翻倍(相对于单核的9w/s)。

benchmark 6379 clients 32 

164519.20 requests per second 

165411.09 requests per second 

用这么强的硬件,获得这样有限的性能提升,差强人意。

这就不难解释为什么现在实践的人那么少。出了因为新,还是不够吸引人。

毕竟,4core的机器,我部署上3台redis cluster的实例,理论上会提升三倍呢。

redis配置文件里,有不少内容在注释这个新特性。

4. 怎么实现?

如图,一次redis请求,要建立连接,然后获取操作的命令,然后执行命令,最后将响应的结果写到socket上。

和杠精聊Redis多线程

在redis的多线程模式下,获取、解析命令,以及输出结果着两个过程,可以配置成多线程执行的,因为它毕竟是我们定位到的主要耗时点。

但命令的执行,也就是内存操作,依然是单线程运行的。

这种设计造成了一个特性。

redis现在依然没有多线程的锁竞争和线程安全问题,因为它的数据读取这一步骤,仍然是单线程的,要排队运行。一些耗时的操作,比如keys *,hgetall等,仍然要注意。

redis并不是传统的reactor模型,说实话很多东西硬套概念的话肯定只能钻进个头去漏出个尾巴。它也并不是master,worker这种干干净净的类似于memcached的模型,因为它把命令执行操作给抽取出来了。其中缘由,看上面这张图就够了。

End

那么,下一个吸引杠精的问题难题来了:在这种多线程应用场景下,redis算是I/O密集型,还是计算密集型呢?

或许,如果redis多线程中,无处不在的轮询,属于“计算”的话,它算是一个计算密集型应用吧。