到底什么级别才算是高并发?

简介: 写这个话题是因为我对搜索引擎给我的答案很不满意,然后决定把思考的一些东西分享出来,希望可以大家彼此讨论下。

作者:边鹏_尛爺鑫 https://segmentfault.com/a/1190000010844969


大家心里仔细想想,当你们听到高并发网站时,心里对这个网站是个什么概念?


首先想到的是淘宝吗?带着问题,我们一起思考技术~


写这个话题是因为我对搜索引擎给我的答案很不满意,然后决定把思考的一些东西分享出来,希望可以大家彼此讨论下。


我们经常在面试的时候,被问到有没有高并发的经验?先不说哪些考高并发的装逼公司。我思考的是什么才算是高并发?你一天几个pv肯定高不了。首先在网上查找一下,并未找到明确的标准定义。那么什么是并发呢?


并发,在操作系统中,是指一个时间段中有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是在同一个处理机上运行,但任一个时刻点上只有一个程序在处理机上运行。


摘自百度百科


我们说的高并发是什么?

上面的定义明显不是我们通常所言的并发,在互联网时代,所讲的并发、高并发,通常是指并发访问。也就是在某个时间点,有多少个访问同时到来。


我看到有人给高并发下了类似的定义:


高并发通常是指我们提供的系统服务能够同时并行处理很多请求。


来看看这个定义,这里首先把并发给混淆到并行了。关于并发并行的区别看这里我就不多说,继续探讨并发。


然后定义又说很多请求?什么叫很多请求?做为中国人,这个词让我想象力一发不可收拾......好了,拉回来,继续本文。


那么从上面的分析,可以看出来高并发在网络上业界也没有明确的定义。但根据我搜索情况,一般都是pv在千万级别以上的公司才会涉及到这个概念。所以我得出一个自定义概念:如果某个系统的日pv在千万级别以上,他就可能是一个高并发的系统。


为什么说是可能?那是因为有的公司完全不走技术路线,全靠机器堆,这不在我们的讨论范围。


高并发的问题,我们具体该关心什么?

讲真话,高并发是个比较抽象的概念。很难有一个统一的可衡量的标准。哪么有一些其它维度的标准指标来衡量系统的性能吗?


搬出以前计算机课程里边的一些指标来跟大家聊聊。网站性能测试指标(QPS,TPS,吞吐量,响应时间)详解,这篇看下。


先声明几个概念,别打瞌睡。


1.QPS(TPS):每秒钟 request/事务 数量,在互联网领域,指每秒响应请求数(指http请求);


2.吞吐量:单位时间内处理的请求数量(通常由QPS与并发数决定);


3.响应时间:系统对一个请求做出响应的平均时间。例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间(我认为这里应该仅包含处理时间,网络传输时间忽略)。


这里一定要注意呃,QPS ≠ 并发数


并发是指,某个时刻有多少个访问同时到来。QPS是指秒钟响应的请求数量。那么这里就肯容易推算出一个公式:


QPS = 并发数 / 平均响应时间


后面我们的分析都是围绕这个公示来进行展开,没明白的再回味一下。


现在我们来假设一个场景:既然QPS是每秒钟处理的http请求数量。那么1s = 1000ms。假设我们当前一个http请求服务器处理完成需要100ms(即那么 平均响应时间 = 100ms *)。那么它1s钟可以处理10个请求。也就是说 *qps = 10。推算出 并发数 = 10


常常我们被问到高并发的问题,其实从某种程度上来说是怎么提高现有程序的性能。现在我们基于上面的假设,来进行分析。假设现在有个系统性能上就是我们上面的假设,它每天有 300万pv,运行在单机上(当然经常宕机),按照上面的系统性能数据,给出优化解决方案。


提高并发能力

通过上面的分析,要提升并发能力,我们就需要提升我们的qps(_其实这里并不完全正确,为了说明问题,我们先放弃一部分正确性_)


最快速解决方案,就是增加机器。我们根据以上情况来实际计算一下。


1.访问量:200w pv


2.QPS:10


根据日常经验,80% 的访问量集中在 20%的时间,算一下这 200w pv实际需要机器达到多少qps才能满足。

qps = (200w * 0.8) / (24 * 3600 * 0.3)
qps = 61.7

实际上如果在单机上,要求我们每秒钟处理请求必须达到 61.7 以上才行,而实际上我们当前系统的qps是 10。那么怎么解决?


方案一:上机器


个人的能力是有限的,团队的力量是无穷的。既然一台机器搞不定,我们就多上几台机器。这就涉及到db主从、读写分离、负载均衡等技术。


它的原理就是分流,把以前集中的压力分散开来。改方案见效快,灵活,实践起来也更快。


方案二:增加单机性能


单机到底性能能够增加到一个什么程度,这取决于你的机器配置,也取决于你的服务到底有多复杂。


ps:写到这里突然有点能够理解为什网上对高并发都是讲很多请求,没有具体数据了,因为这真的只能针对业务来讲,100个并发对静态网页来说根本没有的事儿,但是对于某些密集计算型的估计...


那么常见的单机如何提升性能?比如:增加不常变化数据的缓存,开启php的opcache,优化代码(如:n+1问题、多重嵌套循环、深层递归等),db表优化等等。由于这些每一个点拿出来都够写一本书了。咋就不继续下去。


总结

由于笔者自己也是没有实际经历过kw级别pv场景,很多东西讲的不一定对,本文也是理清自己的一点思路。希望能够与更多朋友进行讨论。


也希望本文能够解决你的一点疑惑,让我们能够从高大上的概念落实到实际问题中去。


参考资料

1.http://h5ip.cn/ifP8 2.http://www.ha97.com/5095.html



相关文章
|
消息中间件 缓存 监控
GitHub上获赞上万的阿里亿级并发系统设计手册,让你吊打面试官
金九银十已经接近尾声,很多没有在这个时间段找到工作的小伙伴已经开始备战秋招了,在这里给大家分享一份阿里10亿级并发系统设计手册,专门给没有系统设计相关经验的小伙伴应对面试用的,下面将这么手册的内容以截图的形式展示给大家,有需要的小伙伴可以文末获取↓↓↓此份手册又份为六个部分,基础篇、数据库篇、缓存篇、消息队列篇、分布式服务篇、维护篇、实战篇共计328页 目录总览 基础篇 高并发代表着大流量,高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案,从而抵抗巨大流量的冲击,带给用户更好的使用体验。这些方案好似能操纵流量,让流量更加平稳得被系统中的服务和组件处理。
GitHub上获赞上万的阿里亿级并发系统设计手册,让你吊打面试官
|
移动开发 前端开发 JavaScript
若依低代码系统开发
若依低代码系统开发
1037 2
|
消息中间件 缓存 前端开发
评论系统如何不崩溃?揭开海量评论背后的技术秘密
小米介绍了一种高效处理海量新闻评论的技术方案。面对突发新闻带来的评论潮,通过采用消息队列异步入库、读写分离以及热点缓存等技术,不仅能有效减轻数据库压力,还能保证用户快速查看最新评论。消息队列如Kafka或RabbitMQ可缓存评论请求,后台异步处理入库,避免数据库过载。读写分离则通过主从数据库架构分散读取负载,配合热点评论的缓存机制进一步提升访问速度。这套架构确保了系统的稳定性和响应速度,适用于高并发的评论处理场景。
274 0
|
存储 缓存 物联网
MQTT常见问题之MQTT发送消息过多内存不够处理不过来如何解决
MQTT(Message Queuing Telemetry Transport)是一个轻量级的、基于发布/订阅模式的消息协议,广泛用于物联网(IoT)中设备间的通信。以下是MQTT使用过程中可能遇到的一些常见问题及其答案的汇总:
|
存储 SQL 缓存
收好这份武林秘籍,让你分库分表再无烦恼
互联网发展至今,各个公司企业的数据量都大幅增长,分库分表越来越多的被我们用到,那么我们应该如何针对我们自己的业务场景,对数据进行合理的划分,用最小的代价解决掉性能瓶颈。
484 0
|
canal 缓存 NoSQL
关于项目点赞问题的高并发解决
采用的技术方案是redis解决的
813 0
|
JavaScript 前端开发 小程序
微服务项目打包部署,一套带走 上
微服务项目打包部署,一套带走 上
|
机器学习/深度学习 数据可视化 PyTorch
【Deep Learning 5】FNN前馈神经网络
🍊本文详细介绍了FNN的原理,并给出了具体的推导过程🍊使用Pytorch搭建了FNN模型,并对糖尿病数据集开展分类任务实战。
2133 0
|
负载均衡 固态存储 关系型数据库
到底多大才算高并发?
到底多大才算高并发?
1042 0
到底多大才算高并发?