高并发系列文章第一篇:高并发和大流量解决方案

本文将从宏观的角度上全方位剖析高并发和大流量解决方案

   从一个面试题开始讲解:PHP如何解决网站大流量与高并发的问题？

   其实这个问题不光考察php的方向，更多的是考察你对高并发架构优化的方式和能力。

   主要考察点如下:

         一、高并发架构相关概念

互联网中的高并发通常指的是并发访问，也就是在某个时间点，有多少个请求来同时访问；

通常如果一个系统的日PV在千万以上，就有可能是一个高并发的系统，但是如果有些公司完全不走技术路线，全靠机器堆，那么这个不在我们所说的高并发的讨论范围、纯属人傻钱多的 

1、对于高并发的问题，我们具体应该关心什么?

     QPS:每秒钟请求或者查询的数量，在互联网领域，指的是每秒响应的请求数（通常指的是HTTP请求）； 这是一个非常重要的指标，通常在进行理解并发数在哪个点该做什么的优化可以根据QPS的量进行操作；

     吞吐量:单位时间内处理的请求数量（通常由QPS和并发数来决定的）

     响应时间:从请求发出到收到响应花费的时间。例如系统处理一个HTTP请求需要100ms，那么这100ms就是系统的响应时间；

     每个资源的响应时间如下图所示，

 PV：综合浏览量（Page View），即页面浏览量或者点击量，一个访客在多长时间内访问的的页面数量；用户每1次对网站中的每个网页访问均被记录1次。用户对同一页面的多次访问，访问量累计。

UV：独立访客（ UniQue Visitor），即一定时间范围内相同访客多次访问网站，只能算为1个独立访客；其实跟IP类似；

带宽：计算带宽大小需要关注两个指标 ，峰值流量和页面的平均大小;

【日网站带宽 = PV / 统计时间（换算成秒）* 平均页面大小（单位KB）* 8】

此处澄清一个概念QPS并不等于并发链接数

QPS是每秒HTTP请求数量，并发链接数是系统同时能够处理的请求数量

【峰值（每秒请求数）QPS  = （总PV数 * 80%）/ (8小时秒数  * 20% )】

   解释:通常80%的访问量都集中在20%的时间内；俗称二八定律 8小时是做了简单的估计

  2、 那么对于QPS来说 我们要做一个压力测试  

     为什么要做压力测试：

  （1）测试能承受的最大并发数

  （2）测试最大承受的QPS的值

             比如说我们日QPS为20000 单机峰值QPS能承受500 那么最少得40台才能撑住

    常用的性能测试工具如下:ab、wrk、http_load、Web Bench、Apache JMeter 

     性能测试工具非常多 我们通过ab来讲解:

    ab 全称(apache benchmark)：是apache官方推出的工具，可以创建多个并发访问线程，摸你多个访问者同时对某一URL地址进行访问。它的测试目标是基于URL的，因此，它既可以用来测试apache的访问压力，也可以来测试 nginx、lighthttp、tomcat、IIS等其他的web服务器的压力。

    ab的使用:模拟并发请求100次,总共请求5000次

    注意事项:

     1）测试机器与被测试机器要分开 

     2）切记不要对线上服务做压力测试

    3）观察测试工具ab所在的机器，以及被测试的前端机的 CPU、内存、网络等都不能超过最高限度的75%  可以通过top、htop、glances命令来观察

测试：ab -c 50  -n 1000  http://192.168.56.10:82/index.html

QPS达到极限我们该怎么做：

  随着QPS的增长，每个阶段需要根据实际情况来进行优化，优化的方案也与硬件条件，网络带宽息息相关。通常在对QPS进行优化的时候阶段也是不一样的

1、QPS达到50 

     可以称为小型网站、一般的服务器都可以轻松应付

2、QPS达到100

      假设关系型数据库的每次请求需要在0.01秒完成，如果单个页面只有一个SQL查询，那么100QPS意味着1秒要完成100次请求，但是此时我们并不能保证数据库查询能完成100次

      优化方案:数据库缓存层（redis、memcache）、数据库的负载均衡流量进行分散

3、QPS达到800

      假设我们使用的是百兆带宽、意味着网站出口的实际带宽是8M左右，假设每个页面只有大小10KB，在这个条件下，百兆带宽已经被吃完、对于带宽来说已经是极限

      优化方案:CDN加速访问、负载均衡

4、QPS达到1000

      假设使用Redis缓存数据库查询，每个页面对Redis的请求远大于直接对DB 的请求 ，那么Redis的悲观并发数大于在4w左右，但有可能在之前内网带宽已经呗吃光，表现出不稳定

     优化方案:静态HTML缓存

5、QPS达到2000

     在这个级别下、文件系统访问锁都成了灾难

     优化方案:做业务分离、分布式存储

         二、高并发架构解决方案案例

    1、流量优化：防盗链处理 

    2、前端优化：减少http请求、添加异步请求 、启用浏览器缓存（添加缓存过期时间）和文件压缩（图片压缩、文件压缩、nginx gzip）、CDN加速、建立独立的图片服务器（减少IO消耗、集群处理优化cpu、IO方面）

    3、服务端优化：页面静态化、并发处理、队列处理

    4、数据库优化：数据库缓存（Redis、MongoDB）、分库分表（水平、垂直拆分）、分区操作、读写分离、负载均衡

    5、web服务器优化: 负载均衡（7层Nginx Proxy、 4层LVS）

本文就到此结束、下篇开始会对上述方案逐一来详细的进行解答、请耐心等待。。。