到底多大才算高并发?

一、什么是高并发

定义:

高并发(High Concurrency)是使用技术手段使系统可以并行处理很多请求。

关键指标:

-响应时间(Response Time)

-吞吐量(Throughput)

-每秒查询率QPS(Query Per Second)

-每秒事务处理量TPS(Transaction Per Second)

-同时在线用户数量

关键指标的维度:

-平均,如:小时平均、日平均、月平均

-Top百分数TP(Top Percentile),如:TP50、TP90、TP99、TP4个9

-最大值

-趋势

「并发」由于在互联网架构中,已经从机器维度上升到了系统架构层面,所以和「并行」已经没有清晰的界限。「并」(同时)是其中的关键。由于「同时」会引发多久才叫同时的问题,将时间扩大,又根据不同业务关注点不同,引申出了引申指标。

引申指标:

-活跃用户数,如:日活DAU(Daily Active User)、月活MAU(Monthly Active Users)

-点击量PV(Page View)

-访问某站点的用户数UV(Unique Visitor)

-独立IP数IP(Internet Protocol)

-日单量

二、多大算高并发

这个问题的答案不是一个数字。来看两个场景:

场景1:

木头同学去一家创业公司面试。这个公司做的产品还没有上线,面试官小熊之前就职过公司的产品都没有什么量。

小熊:“有高并发经验吗?”

木头:“我们服务单机QPS2000+,线上有4台机器负载均衡。”

这时候小熊心里的表情大概是:

但是如果小熊就职的公司是美团之类的。那这这时候小熊心里的表情大概是:

场景2:

固态硬盘SSD(Solid State Disk)说:我读取和写入高达 1000MB/秒

mysql说:我单机TPS10000+

nginx说:我单机QPS10W+

静儿说:给我一台56核200G高配物理机,我可以创建一个单机QPS1000W

不在同一维度,没有任何前提,无法比较谁更牛。“我的系统算不算高并发?”这个问题就如同一个女孩子爱问的问题:“我美不美?”

三、高并发的本质

    俗话说:「没有对比就没有伤害」。算不算高并发,这个问题的答案需要加对比和前提。

对比包括:

-业界:在业界同类产品中并发量处于什么位置。举个栗子??,美团外卖的日单量是千万级别,一个系统日单量在百万,虽然差一个数量级,但是相比大多数公司已经很不错。

-自身:在自身系统中,并发问题是否已经是系统的瓶颈?如果是,这么这个瓶颈怎么打破?如果不是,那当初架构设计的时候是怎么保证并发不是问题的?(别告诉我:是通过系统没有访问量来保证的[擦汗])。

前提包括:

-业务复杂度:举个栗子??,访问百度首页的时间基本就是看自己家的网速,通常情况下都是点一下就看到结果了。而扫描二维码支付,通常需要等很久,虽然这可能已经是业界最牛的支付公司出品了。

-配置:用高配物理机得出的数据和最老最低配的虚拟器上的出来的结果是无法比较的。通常的配置有:cpu、内存、磁盘、带宽、网卡

高并发的本质不是「多大算高并发」的一个数字,而是从架构上、设计上、编码上怎么来保证或者解决由并发引起的问题。当别人问你:“做过高并发吗?”回答者完全可以描述自己系统的各项指标,然后开始叙述自己对系统中对预防、解决并发问题作出的思考和行动。

四、总结

过程大于结果,方向大于方法。

相关阅读:

学会用数据说话-分布式锁究竟可以多少并发?
大话高可用

原文地址:https://www.cnblogs.com/xiexj/p/10399385.html

时间: 2024-10-09 21:56:23

到底多大才算高并发?的相关文章

[转]浅析大数据量高并发的数据库优化

链接:http://www.uml.org.cn/sjjm/201308264.asp 高并发数据库可以同时处理海量信息,应用范围很广.今天我们将讨论的是大数据量高并发的数据库优化,希望对大家有所帮助. 一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性

(转)大数据量高并发的数据库优化与sql优化

大数据量高并发的数据库优化 一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整

大数据量高并发的数据库优化详解(MSSQL)

转载自:http://www.jb51.net/article/71041.htm 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 一.数据库结构的设计 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而

大数据和高并发的解决方案总结

现在,软件架构变得越来越复杂了,好多技术层出不穷,令人眼花缭乱,解决这个问题呢,就是要把复杂问题简单化,核心就是要把握本质. 软件刚开始的时候是为了实现功能,随着信息量和用户的增多,大数据和高并发成了软件设计必须考虑的问题,那么大数据和高并发本质是什么呢? 本质很简单,一个是慢,一个是等.两者是相互关联的,因为慢,所以要等,因为等,所以慢,解决了慢,也就解决了等,解决了等,也就解决了慢. 关键是如何解决慢和等,核心一个是短,一个是少,一个是分流. 短是指路径要短.典型的mvc结构是请求->con

大数据和高并发的解决方案汇总

大数据和高并发的解决方案汇总 1.3海量数据解决方案 1.使用缓存: 使用方式:1,使用程序直接保存到内存中.主要使用Map,尤其ConcurrentHashMap. 2,使用缓存框架.常用的框架:Ehcache,Memcache,Redis等. 最关键的问题是:什么时候创建缓存,以及其失效机制. 对于空数据的缓冲:最好用一个特定的类型值来保存,以区别空数据和未缓存的两种状态. 2.数据库优化: 1,表结构优化. 2,SQL语句优化,语法优化和处理逻辑优化.可记录各语句执行时间,有针对性的分析.

大数据量高并发的数据库优化

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

PHP如何解决网站大流量与高并发

首先,确认服务器硬件是否足够支持当前的流量.普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大, 那么必须首先配置一台更高性能的专用服务器才能解决问题 ,否则怎么优化都不可能彻底解决性能问题. 其次,优化数据库访问. 前台实现完全的静态化当然最好,可以完全不用访问数据库,不过对于频繁更新的网站, 静态化往往不能满足某些功能.缓存技术就是另一个解决方案,就是将动态数据存储到缓存文件中,动态网页直接调用这些文件,而不必再访问数据库,WordPress和Z-Blog都大量使用这种

大数据量高并发访问的数据库优化方法

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

PHP解决网站大数据大流量与高并发

1:硬件方面 普通的一个p4的服务器每天最多能支持大约10万左右的IP,如果访问量超过10W那么需要专用的服务器才能解决,如果硬件不给力 软件怎么优化都是于事无补的.主要影响服务器的速度 有:网络-硬盘读写速度-内存大小-cpu处理速度. 2:软件方面 第一个要说的就是数据库,首先要有一个很好的架构,查询尽量不用* 避免相关子查询 给经常查询的添加索引 用排序来取代非顺序存取,如果条件允许 ,一般MySQL服务器最好安装 在Linux操作系统中 .关于apache和nginx在高并发的情况下推荐