最近去面试

啥公司都问微服务了

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

反正我是不懂。

哎，心累

言归正传

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

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

要不就是还没上线就被砍掉（真的很伤，做了多少项目有多少被砍掉）

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

因特网上，经常用每秒查询率来衡量域名系统服务器的机器的性能，其即为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——定义为锁/同步模式极限型网站

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

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

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