这篇文章主要介绍“怎么理解Redis中多线程”,在日常操作中,相信很多人在怎么理解Redis中多线程问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”怎么理解Redis中多线程”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
周末被一位小同学憋的很窝火。他要和我探讨一下,redis到底是多线程的还是单线程的。这个问题本来比较好解释,但我遇到的却是一个杠精。
答案是显而易见的:redis6,逃不过真香定理,引入了多线程;而在redis6之前,却是单线程的。
也就是说,这不是一个是和否的问题,还涉及到第二维度的版本参与。
可是,这位同学要打我的脸。不知道小姐姐的脸皮很嫩么?摸不得。
“照你的逻辑,redis5是单线程的了?”
“是的。”
“那下面这张截图是怎么回事?”
同学甩给我一张图,并送来一个鄙视的眼神。
“使用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进程。
这部分逻辑,是在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现在依然没有多线程的锁竞争和线程安全问题,因为它的数据读取这一步骤,仍然是单线程的,要排队运行。一些耗时的操作,比如keys *,hgetall等,仍然要注意。
redis并不是传统的reactor模型,说实话很多东西硬套概念的话肯定只能钻进个头去漏出个尾巴。它也并不是master,worker这种干干净净的类似于memcached的模型,因为它把命令执行操作给抽取出来了。其中缘由,看上面这张图就够了。
到此,关于“怎么理解Redis中多线程”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。