教你如何定义网站并发量,选用合适框架

最近去面试

啥公司都问微服务了

真的有那么多公司业务量达到这么大需求

反正我是不懂。

哎,心累

言归正传

其实一个网站的并发量我以前也没有注意过

毕竟以前公司业务量小基本都是开发管理后台,用的人不多

要不就是还没上线就被砍掉(真的很伤,做了多少项目有多少被砍掉)

这几次面试问的多就慢慢留意了下

因特网上,经常用每秒查询率来衡量域名系统服务器的机器的性能,其即为QPS。

对应fetches

c,即每秒的响应请求数,也即是最大吞吐能力。

计算关系:

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

并发量 = QPS * 平均响应时间

通常QPS用来表达和衡量当前系统的负载,也可以用RPS来表示,

简单理解就是每秒访问网站的次数(我自己瞎理解)

1.请求QPS50次以下的---定义为普通网站

举个例子,像普通官网,一天都没几个去点击,更不用说同一秒好几个人去点击了

2.请求QPS50次到100 之间的---定义为数据库极限网站

大部分的数据库sql查询基本都在0.01秒左右,所以理论来说数据库能支撑的访问,

按照

互联网有一个传说中的“3秒定律”,可能当下更多的网站技术指标要求1.5秒以内加载整页,或者至少可以达到阅读的标准

这个阶段就要考虑做缓存(cache)或者多数据库(DB)负载。

3.请求QPS300次到800——定义为带宽极限型网站

目前服务器大多用了IDC机房都能够提供“百兆带宽”,“百兆出口”,似乎这就是单机的最高配了(等5g把),这意味着网站出口的实际带宽是8M Byte左右。假定每个页面只有10K Byte,在这个并发条件下,即便你的网站是静态页面,不用什么数据库之类的技术,百兆带宽早已经吃完。这个阶段就要考虑是CDN加速/异地缓存,多机负载等技术。

4.请求QPS500次到1000——定义为内网带宽极限+Memcache极限型网站

由于Key/value的特性,每个页面对memcache的请求远大于直接对DB的请求,Memcache的悲观并发数在2w左右,看似很高,但事实上大多数情况下,首先是有可能在此之前内网的带宽就已经吃光,接着是在8K QPS左右的情况下,但节点上的Memcache已经表现出了不稳定,如果代码上没有足够的优化,缓存的miss可能会导致系统直接将压力转嫁到了DB层上,这就使整个系统在达到某个明显的阀值之后,性能迅速下滑或直接宕机(缓存没查到直接向数据库发起请求)。

5.请求QPS1000次到2000——定义为锁/同步模式极限型网站

好吧,一句话:线程模型决定吞吐量。不管你系统中最常见的锁是什么锁,这个级别下,文件系统访问锁都成为了灾难。从网站内容的角度上讲,几乎任何的增删改都会牵扯到锁。“等解锁”的过程将会成为系统最重要的性能消耗。这就要求系统中不能存在中央节点,所有的数据都必须分布存储,数据需要分布处理。总之,关键词:分布

在往上的就不是我们能操心的事了

教你如何定义网站并发量,选用合适框架

有空还是得多看看别人的一些技术,才能够更好的提升自己