高并发大流量网站的优化方案

高并发常用术语：

• QPS：每秒钟请求或者查询的数量，在互联网领域，指每秒响应请求数(指HTTP请求)
• 吞吐量：单位时间内处理的请求数量(通常由QPS与并发数决定)
• 响应时间：从请求发出到收到响应花费的时间，例如系统处理一个HTTP请求需要100ms，这个100ms就是系统的响应时间
• PV：综合浏览量(Page View)，即页面浏览量或者点击量，一个访客在24小时内访问的页面数量，同一个人浏览你的网站同一页面，只记作一次PV
• UV：独立访问(UniQue Visitor)，即一定时间范围内相同访客多次访问网站，只计算为1个独立访客
• 带宽：计算带宽大小需关注两个指标，峰值流量和页面的平均大小
  日网站带宽=PV/统计时间(换算到秒)平均页面大小(单位KB)8
  峰值一般是平均值的倍数，根据实际情况来定
  QPS不等于并发连接数
  QPS是每秒HTTP请求数量，并发连接数是系统同时处理的请求数量
  (总PV数80%)/(6小时秒数20%)=峰值每秒请求数(QPS)
  80%的访问量集中在20%的时间！！！

• PS达到50
  可以称之为小型网站，一般的服务器就可以应付
• QPS达到100
  假设关系型数据库的每次请求在0.01秒完成

        假设单页面只有一个SQL查询,那么100QPS意味着1秒钟完成100次请求,但是此时我们并不能保证数据库查询能完成100次

        方案:数据库缓存层、数据库的负载均衡

• QPS达到800

        假设我们使用百兆带宽，意味着网站出口的实际带宽是8M左右

        假设每个页面只有10k，在这个并发条件下，百兆带宽已经吃完

         方案：CDN加速、负载均衡

•  QPS达到1000

            假设使用Memcache缓存数据库查询数据，每个页面对Memcache的请求远大于直接对DB的请求

             Memcache的悲观并发数在2W左右，但有可能在之前内网带宽已经吃光，表现出不稳定

              方案：静态HTML缓存

• QPS达到2000

         这个级别下，文件系统访问锁都成为灾难

         方案：做业务分离，分布式存储

---

优化方案：

前端优化：（压缩工具，uglifyjs,webpack）

   文件合并，减少HTTP请求

    （图片地图，CSS 精灵，多个脚本合并，多个样式表合并，图片使用base64编码）

   

  启用浏览器缓存和文件压缩

    本地缓存：

      

pragma	当该字段值为“no-cache”的时候，会知会客户端不要对该资源读缓存，即每次都得向服务器发一次请求才行
expire	启用缓存和定义缓存时间，响应报文中Expires所定义的缓存时间是相对服务器上的时间而言的。如果客户端上的时间跟服务器上的时间不一致（特别是用户修改了自己电脑的系统时间），那缓存时间可能就没啥意义了
cache-control.nostore	所有内容部保存到缓存或Internet临时文件中
cache-control.nocache	不使用缓存，向服务器发起请求
cache-control.max-age	告知客户端该资源在delta-seconds秒内是新鲜的，无需向服务器发送请求

    协商缓存：

Last-modified	资源最后一次修改时间
if-Match	比较Etag 资源匹配信息
if-None-Match	比较Etag 资源匹配信息
If-Modified-Since	比较资源最后更新时间是否一致
if-Unmodified-Since	比较资源最后更新时间是否一致

nginx相关配置：

  etag:on|off

  gzip压缩：

  gzip: on|off

  gzip_comp_level[1-9] 压缩级别越高压缩越小，越浪费CPU

　CＤＮ加速 

　异步请求（实时数据要求比较高）

　建立独立的图片服务器

后端优化：

　　防盗链

      1)referer  2)签名

　　页面静态化

　　并发处理

　　队列处理

　　数据库缓存

　　分库分表（分区）

　　读写分离

　　负载均衡