企业级 PHP 高并发解决方案 0x00 起步

架构1716 字

高并发架构的相关概念

高并发的概念

  • 并发:在操作系统中,是指一个时间段中有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是在同一个处理机上运行,但任意一个时刻点上只 有一个程序在处理机上运行。

    上面这一段是摘自百度百科的一段话,但是上面的定义很明显不是我们通常所说的并发,在互联网时代,所讲的并发、高并发,通常是指并发访问。也就是在某一个时间点,有多少个访问同时到来。

  • 高并发: 通常如果一个系统的日 PV 在千万以上,有可能是一个高并发的系统,有的公司完全不走技术路线,全靠机器堆,这不再我们的讨论范围。

高并发中需要关注相关概念

  • QPS: 每秒钟请求或者查询的数量,在互联网领域,指的是每秒响应请求数(指的是HTTP请求)。
  • 吞吐量:单位时间内处理的请求数量(通常由QPS与并发数决定)
  • 响应时间: 从请求发出到收到响应花费的时间。例如系统处理一个HTTP请求需要 100ms, 这个 100ms 就是系统的响应时间。
  • PV: 综合浏览量(Page View),即页面浏览量或者点击量,一个访客在24小时内访问的页面数量。同一个人浏览你的网站统一页面,只记录一次 PV。
  • UV: 独立访客(UniQue Visitor),即一定时间范围内相同访客多次访问网站,只计算为一个独立访客。
  • 带宽: 计算带宽大小需关注两个指标,峰值流量和页面的平均大小
  • 日网站带宽: PV/统计时间(换算到秒)*平均页面大小(单位KB)* 8,峰值一般为平均值的倍数,根据实际情况来定。
  • 压力测试: 测试服务器能够最大承受的最大并发数和QPS值,对于计算机来说,我们应该知道这台服务器最大能够承受多少QPS,而我们可以通过一天的PV来计算出峰值的QPS,这样我们就可以根据需求进行优化。

在这里我们需要注意,QPS 不等于并发数数量,QPS是每秒HTTP请求数量,并发连接数是系统同时处理的请求数量。

(总PV数 80%) / (6小时秒数 20%) = 峰值每秒请求数量(QPS), 80%的访问量集中在20%的时间,那为什么是6个小时呢?

6个小时主要是做了一个简单的估计,比如说我们访问网站中午两个小时,下午两个小时,晚上两个小时。

压力测试工具

在我们日常的工作当中下面这几款是我们比较常用的压测工具:

  • ab:Apache benchmark,是 Apache 官方推出的工具创建多个并发访问线程,模拟多个访问者同时访问某一URL 地址进行访问。
  • wrk:是一款开源的性能测试工具,简单易用,没有Load Runner那么复杂,他和 apache benchmark(ab)同属于性能测试工具,但是比 ab 功能更加强大,并且可以支持lua脚本来创建复杂的测试场景。
  • Jmeter:Jmeter 是测试人员最长用的压测工具,他的功能要比 ab 和 wrk 强大很多。

接下来,我们用 ab 来简单说明一下压力测试的使用方法。

ab 的简单使用

[root@stache34 ~]# ab -n 1000 -c 900 http://192.168.176.30/index.html
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.176.30 (be patient) #完成的进度
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:        Apache/2.4.6   #服务器软件版本
Server Hostname:        192.168.176.30 #服务器主机名
Server Port:            80                          #服务器端口

Document Path:          /index.html      #测试的页面
Document Length:        9 bytes            #页面的字节数

Concurrency Level:      900                     #请求的并发数,代表着访问的客户端数量
Time taken for tests:   0.489 seconds #整个测试花费的时间
Complete requests:      1000                     #成功的请求数量
Failed requests:        0                         #失败的请求数量
Write errors:           0
Total transferred:      267000 bytes     #整个测试过程的总数据大小(包括header头信息等)
HTML transferred:       9000 bytes         #整个测试过程HTML页面实际的字节数
Requests per second:    2045.81 [#/sec] (mean) #每秒处理的请求数,这是非常重要的参数,体现了服务器的吞吐量
                                               #后面括号中的 mean 表示这是一个平均值
Time per request:       439.923 [ms] (mean)      #平均请求响应时间,括号中的 mean 表示这是一个平均值

#每个请求的时间 0.489[毫秒],意思为在所有的并发请求每个请求实际运行时间的平均值
#由于对于并发请求 cpu 实际上并不是同时处理的,而是按照每个请求获得的时间片逐个轮转处理的
#所以基本上第一个 Time per request 时间约等于第二个 Time per request 时间乘以并发请求数
Time per request:       0.489 [ms] (mean, across all concurrent requests)

Transfer rate:          533.43 [Kbytes/sec] received #传输速率,平均每秒的流量
                                                     #可以帮助排除是否存在网络流量过大导致响应时间延长的问题
Connection Times (ms) #连接时间
              min  mean[+/-sd] median   max #median中间
Connect:        0   17  11.8     21      34
Processing:     1  145 153.9     35     446
Waiting:        1  145 153.9     35     446
Total:         16  163 161.2     63     474

Percentage of the requests served within a certain time (ms) #在一定的时间内提供服务的请求的百分比
  50%     63
  66%    244
  75%    255
  80%    260
  90%    468
  95%    471
  98%    474
  99%    474
 100%    474 (longest request)

注意事项

  • 测试机器与被测机器分开,因为 ab 在测试的时候同样会占用机器资源,如果在一台器上进行测试会影响测试结果。
  • 不要对生产服务做压力测试,避免影响生产环境。
  • 观察测试工具 ab 所在机器,以及被测试的前端机的 CPU,内存,网络等都不超过最高限度的75%。

QPS 的增长中会遇到的挑战

随着 QPS 的增长,每个阶段需要根据实际情况来进行优化,优化的方案也与硬件、网络带宽息息相关。

QPS解决收到解决方案
50可以称之为小型网站,一般的服务器都可以应付。
100假设关系型数据库的每次请求在0.01秒完成,并且页面中只有一个 SQL 查询,那么100 QPS 意味着1秒钟完成100个请求,但是此时我们并不能保证数据库查询能完成100次。数据库缓存层、数据库的负载均衡
800假设我们使用百兆带宽,意味着网站出口的实际带宽是8M 左右,假设每个页面只有10K,在这个并发条件下,百兆带宽已经吃完了。CDN 加速、负载均衡
1000假设使用 Memcache 缓存数据库查询数据,每个页面对 Memcache 的请求远大于直接 DB 的请求,Memcache 的悲观并发数在2W 左右,但有可能在之前内王带宽已经吃光,表现出不稳定。静态 HTML缓存
2000这个级别下,文件系统访问锁都成了灾难。做业务隔离,分布式存储

为了应对QPS 增长我们可以使用下面的手段来应对:

场景方案
流量优化防盗链
前端优化减少 HTTP 请求、添加异步请求、启用浏览器缓存和文件压缩、CDN 加速、建立独立的图片服务器
服务端优化页面静态化、并发处理、队列处理
数据库优化数据库缓存、读写分离、分库分表、分区操作、读写分离、负载均衡
集群Nginx、LVS
maksim
Maksim(一笑,吡罗),PHPer,Goper
OωO
开启隐私评论,您的评论仅作者和评论双方可见