face 29高并发大流量

高并发大流量

并发  并发访问，在某个时间点 有多少个访问同时到来

php如何处理网站大流量高并发问题

流量优化

防盗链处理：恶意请求

1.根据referer 判断 处理

2.判断签名 判断是否合法

niginx 模块 ngx_http_referer_module 用来阻挡非法访问

展示不属于本站的资源：常用小站盗用大战的图片音乐 视频 软件 等资源

前端优化，

减少http请求 css文件合并 js合并 图片合并

添加异步请求（不重要的数据 ajax）

启用浏览器缓存 和文件压缩 设置缓存文件过期时间

cdn加速

建立独立的图片服务器（集群）

  服务端优化

页面静态化

【并发处理

队列处理】

数据库的优化

数据库缓存 mechache redis

分库分表 (水平拆分 垂直拆分)、分区操作

读写分离

负载均衡

web服务器优化

负载均衡 nginx的反向代理  lvs软件 负载均衡

测试qps的极限值

根据qps对应优化

qps达到极限，根据实际情况进行优化，优化的方案也与硬件条件，网络带宽息息相关

qps达到50

小型网站，一般的服务器都能应付

100 数据库层的瓶颈

假设关系型数据库每次请求在0.01秒完成

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

方案：数据库缓存（避免访问数据库）、数据库的负载均衡（流量分散开）

qps 800 带宽瓶颈

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

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

方案：cdn加速，负载均衡

qps达到1000

假设使用memcache缓存数据库查询数据，

每个页面对memcache的请求远大于直接对db的请求

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

方案：静态html缓存

qps 达到 2000

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

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

常用性能测试工具

ab

  wrk

http_load

web bench

  siege

  apache Jmeter

ab :apache benchmark  apche官方推出的，创建并发线程 测试压力 也可以测试nginx  lighthttp  tomcat  iis等其他web服务器的压力

模拟并发  100次 总共请求5000次

ab -c 100 -n  5000 待测试网站

测试机器与被测机器分开

不要对线上服务做压力测试

观察测试工具ab所在机器 以及被测试的前端机的cpu,内存，网络等都不超过最高限度的75%

压力测试

测试能承受的最大并发

测试能承受的qps值

高并发：并发访问 日 pv在千万以上，有可能是一个高并发

有公司完全不走技术路线 全靠机器堆，不在讨论范围内

（总pv数*80%）/（6小时秒数*20%）=峰值每秒请求数（qps）

80%的访问量集中在20%的时间

qps:每秒响应请求数

并发连接数：系统同时处理的请求数量

吞吐量：单位时间内处理的请求数量

响应时间：从请求发出 到收到响应时的时间

pv：综合浏览量：页面的浏览量 或者点击量。一个访客在24小时内的访问量，同一访客浏览只记做一个

uv:独立访客，一定时间范围内 相同访客多次访问网站 只计算为一个独立访客，类似ip

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

日网站带宽=pv/统计时间（换算到秒）*平均页面大小（单位kb）*8

峰值一般是平均值的倍数 根据实际情况来定