找别人做网站怎么防止后门,wordpress win主题,网站设计公司网站设计,设计师有哪些种类不羡鸳鸯不羡仙#xff0c;一行代码调半天。原创#xff1a;小姐姐味道#xff08;微信公众号ID#xff1a;xjjdog#xff09;#xff0c;欢迎分享#xff0c;转载请保留出处。周末被一位小同学憋的很窝火。 他要和我探讨一下#xff0c;redis到底是多线程的还是单线程…不羡鸳鸯不羡仙一行代码调半天。原创小姐姐味道微信公众号IDxjjdog欢迎分享转载请保留出处。周末被一位小同学憋的很窝火。 他要和我探讨一下redis到底是多线程的还是单线程的。这个问题本来比较好解释但我遇到的却是一个杠精。答案是显而易见的redis6逃不过真香定理引入了多线程而在redis6之前却是单线程的。也就是说这不是一个是和否的问题还涉及到第二维度的版本参与。可是这位同学要打我的脸。不知道小姐姐的脸皮很嫩么摸不得。“照你的逻辑redis5是单线程的了”“是的。”“那下面这张截图是怎么回事”同学甩给我一张图并送来一个鄙视的眼神。“使用top -Hp 查看。redis5有4个线程。该怎么解释”这个问题我也不知道怎么跟他解释。使用top命令去观测redis5肯定是多线程的比如bgsaveaof等肯定要开启一个线程去操作否则早就炸了。按照这个逻辑去说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 32164519.20 requests per second165411.09 requests per second用这么强的硬件获得这样有限的性能提升差强人意。这就不难解释为什么现在实践的人那么少。出了因为新还是不够吸引人。毕竟4core的机器我部署上3台redis cluster的实例理论上会提升三倍呢。redis配置文件里有不少内容在注释这个新特性。4. 怎么实现如图一次redis请求要建立连接然后获取操作的命令然后执行命令最后将响应的结果写到socket上。在redis的多线程模式下获取、解析命令以及输出结果着两个过程可以配置成多线程执行的因为它毕竟是我们定位到的主要耗时点。但命令的执行也就是内存操作依然是单线程运行的。这种设计造成了一个特性。redis现在依然没有多线程的锁竞争和线程安全问题因为它的数据读取这一步骤仍然是单线程的要排队运行。一些耗时的操作比如keys *hgetall等仍然要注意。redis并不是传统的reactor模型说实话很多东西硬套概念的话肯定只能钻进个头去漏出个尾巴。它也并不是masterworker这种干干净净的类似于memcached的模型因为它把命令执行操作给抽取出来了。其中缘由看上面这张图就够了。End那么下一个吸引杠精的问题难题来了在这种多线程应用场景下redis算是I/O密集型还是计算密集型呢或许如果redis多线程中无处不在的轮询属于“计算”的话它算是一个计算密集型应用吧。作者简介小姐姐味道 (xjjdog)一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构日百亿流量与你探讨高并发世界给你不一样的味道。我的个人微信xjjdog0欢迎添加好友进一步交流。
