本文主要是介绍老大说了,即使你是女程序员,这性能调优你也得拿下!,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
【悟思维】项目架构决定性能?优秀的架构胜过一万次的调优
这个问题很容易理解,一个单节点(一台应用服务器+一台数据库服务器)的系统架构,任凭你使出浑身解数来调优也不可能让系统达到百万级并发,别说百万级了,上万并发都不可能。不说其他的,在一个性能相对不错的物理机上,mysql最多也就能承载3500-4500的QPS,你说你能调优调到上万并发??在目前来看如果不借助于其他组件或者其他技术手段是不太可能的。
首先大家要明白一个最底层的逻辑,所有的性能问题归根结底绝大多数都是要解决IO的读写性能问题。
我们在线程模型上面孜孜不倦的追求,从BIO到NIO,再到reactor,最后到proactor,对这些模型的追求本质上就是不断对IO性能的追求。
那IO又分为读IO和写IO,在单节点上,高并发上来之后,请求直接通过tomcat打到mysql上达到3500qps左右的时候,mysql就会报警了,这时候怎么办?
打到mysql上的请求无非就是读和写,所以我们分两种情况来处理:
- 一是解决读IO的问题,如何解决?最直接的就是我们把热点数据直接放内存里(走逻辑io),不走mysql了(走mysql实际是到磁盘去拿数据的,走的是物理IO),所以我们大名鼎鼎的redis就派上用场了。绝大部分热点数据都存放在redis,高并发时候,读IO绝大部分都走redis了,这样就减轻了mysql的负担。
- 二是解决写IO的问题,当大量的写需求到达mysql的时候,如果我们在mysql前面加上消息队列相关组件,让写请求先进队列,然后再通过队列慢慢依次的来对mysql进行写操作,那么这样不就减轻了mysql的写请求IO了吗?
所以我们的架构就从单一架构(比如说是tomcat+mysql)变成了(tomcat+mq+redis+mysql)的架构,这两种架构的性能有着天壤之别。因为mq和redis分别解决了高并发时的读写问题,这才是影响性能的根本因素。那么第二种架构还有很多的优化空间,比如我们继续给他增加多级缓存,redis再做集群,mq也做集群,甚至tomcat,mysql都做集群,那么这个系统将会变的非常庞大,也更加的复杂,但是带来的效果却是显而易见的,达到百万并发,千万并发甚至亿级并发都是有可能的。
参考文档:https://smartan123.github.io/book/?file=001-%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/001-%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E9%9D%A2%E8%AF%95%E9%A2%98%E9%9B%86%E9%94%A6
这篇关于老大说了,即使你是女程序员,这性能调优你也得拿下!的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!