关于 PHP 高并发，请教各位

[minuo0day]

H5 页面的核酸系统，前后端分离，前端 VUE ，后端 PHP 自己搭的 larave 框架，数据库 mysql,Nginx ， 三台负载均衡的天翼云应用服务器，都是 32 核 64G ，一台数据库服务器 16 核 32G ； 基本业务逻辑： 用户端，进入页面绑定自己身份证号手机号乡镇信息等个人信息，前端凭借身份证号直接生成个人二维码，向医护人员出示二维码，1 个小时需要做 40 万人口的核酸； 医护端，手机号身份证号登录或者申请，登入先选采集点，扫开箱码，再扫试管码选择十合一或二十合一，再点击添加人员打开扫一扫扫居民个人码添加；

24 日早上 4 点 30 ，医护人员开始大量的开始进入程序扫箱码开箱，并在后台开始大量的添加临时采集点，于 4 点 58 分，CPU 使用率 100%，系统崩溃，日志显示，瞬间请求数 1 万 4 ，重启在进入还是崩；

24 日下午系统整体挪到阿里云服务器，也是三台负载均衡的服务器，三台 32 核 64G ，加了 OSS ，用了阿里云的云数据库 RDS 版，主实例 8 核 16G ，只读数据库服务器 8 核，压测 10 分钟 15 万人，和 4000 医护人员同时在线也崩了，数据库和应用服务器的 CPU 利用率都打到了 100%，为了保障第二天不出问题，临时调大了一台应用服务器调到了 52 核，并同时把读写的两台数据库服务器都调到了最大 104 核，第二天检测才扛过去。

问：我们虽然调大了服务器的配置，但调大以后压测 10 分钟 20 万人和 4000 医护在线，服务器承载 20%都上不去，但前端页面会变得非常慢，基本上 10 几秒才能打开，这种情况请大神指点

[nine]

PHP1 小时 40 万，真的不算多。8 年前用 4 核云服务器+2 核 DB （那时候叫 VPS ）运维过别人的 PHP 代码，做过一天 600 万的访问，CPU 占用 25%。在我插手他架构，并魔改他代码之前，也是经常宕机，和你的情况差不多。

这种情况，一般就是卡在 mysql 上了。mysql 多核利用效果不好，所以才会有一堆读写分离、分库分表、KV 缓存、异步队列，这些看起来很骚的运维方案。

mysql 单核查询卡死，会导致其他查询堆积。你检查一下，如果 DB 服务器只有一个核是 100%，其他都是空闲，那基本就是这情况。
前端的 application server 会一直堆积请求，并发时会导致 application 服务器 CPU 高居不下，但这其实不太重要。因为 web 界面卡死主要还是 DB 数据读不出来。

----------------------------------------------------------------------------------------

你的具体问题主要就集中在“前端凭借身份证号直接生成个人二维码”这里。这里就是大量的 find_by(身份证: 字符串)，这种查询的读。如果不存在的话，还要插一条数据。

解决这里的代码逻辑结构，和读写结构。代码这里应该做一些设计。然后是数据库，（如果可以的话，DB 建议直接换成 PostgreSQL ，不过我感觉你们应该没有 PG 的运维经验）所以，先把 mysql 做读写分离吧。

二维码查询查一个库，生成写另一个库，前端页面和后台管理查另另一个库。

其他的可以再检查一下带宽和磁盘 IO ，密切监控。磁盘垃圾的话，基本也要卡死。

那些动不动喷 Laravel 和推 Go 、Swoole 的非蠢即坏，另外这种业务也不太适合上缓存和队列。LZ 好好检查下我说的这些点。解决了记得给我发红包。

[limingxinleo]

@noyidoit 是的。。。

[fourlee]

1 、先排查数据库，确认数据库的连接数是否打满，如果连接数已满，则放大连接数，同时应用层采用数据库连接池和长连接；确认 CPU 利用率，内存利用率，磁盘 IO 利用率，如果利用率达到了 80%以上，结合慢日志，优化查询 SQL 和数据库索引，也可以考虑读写分离，前置 redis 缓存，消息队列，结合业务场景，如果医护端对数据实时性要求比较高的话，可以不走消息队列，直接入库，对于读多写少的情况，尽量考虑如何提高前置 redis 缓存的命中率；如果以上不存在大问题，则问题不在数据库层，数据库的优化优先级就不高，放到最后。

2 、排查 redis 缓存，查看 redis 的内存利用率、网卡带宽和缓存命中率，如果缓存命中率较低的话，进一步分析原因，如果网卡带宽占用比较高，可以采用一主多从，网卡带宽占用较高，也会导致缓存查询时间上涨。

3 、如果以上两处问题解决，应用层就比较好办了，最快的方法就是增加机器。应用层的优化包括开启 php-fpm 的 slow log ，查看具体是哪个接口慢，再结合 xhprof 性能分析工具具体分析，开启 opcache ，优化服务器内核，开启 nginx 缓存，分析业务场景，优化接口请求减少或者合并部分接口，后续如果条件允许，再考虑采用 go 或者其他语言重构。

4 、前端 vue 及静态文件全部使用 CDN ，必要的时候部分接口不采用 https

[limingxinleo]

楼主可以到 Hyperf 群里联系我，如果你们的项目不是很大的话，我可以免费带你们重构。

我想让这些 xx 🤐

[ferock]

为了推广，鼓吹重构


看着就反胃。。。🤢。。。这水平还主动引战？
既然想做商务就别扯上技术问题。

[HalfaMillion]

@limingxinleo 你除了抄袭，无脑推 hyperf 能干点别的事？

[Felldeadbird]

楼主可以说一下最后的解决方案吗？我想学习一下。

[limingxinleo]

@HalfaMillion @ferock

项目没有不重构的，鼓吹重构是个问题么？

你提到抄袭的问题，那很好，你看看我们抄的那些组件，哪个没有写来源？最开始确实没有在许可证里写上，后面也都补上了。

[minuo0day]

@Felldeadbird 附言说了啊

[limingxinleo]

@ferock 另外，我们都不是全职做开源，根本没必要做什么商务，又不是没有工资。

[lbp0200]

看看是不是带宽被打满了

[zuokanyunqishi]

PHP fpm 模式没有这末不堪，😁。楼主是功力不到哇

[terranboy]

PHP 配 OPCACHE 是标配了啊 LZ 怎么不开啊 这个主要是数据库压力 别喷框架和语言了。。LARAVEL 再怎么不堪 用上异步队列 跟 JAVA 之类的有什么不同吗

[limingxinleo]

@minuo0day 兄弟。。那你们 FPM 进程是静态模式么？不会是动态模式吧。。。

[chouxiang7]

厉害了

[limingxinleo]

@minuo0day 楼主我错了，我不该给你把楼歪了。。浪费时间在那两个 213 身上。

撤了，很抱歉。。。

[lshero]

把 SQL 优化好 之前先不要谈论框架性能,因为不面对问题很容易被带偏即使换语言重构了还是解决不了实际上的问题。

既然是前后端分离了是不是前端资源已经上 CDN 了前端资源不占用负载均衡的带宽了？那就看看负载均衡的带宽有没有打满。

建议查看一下数据库的慢 SQL ，以及看一下数据库中是否有死锁。如果有慢 SQL 可以看看都是啥表，对应的表中有没有设计索引，where 条件有没有一些常见索引失效的原因比如隐式转换，使用了函数之类的。

看看有没有开启一些框架默认有但是你却没有使用的东西，比如 session 之类的

线上可以使用随机采样的方式开启 xhprof 持久化保存一些分析结果，然后离线倒入数据库中分析一下耗时的步骤再去找对应的代码看实现有没有问题。

使用 Redis 的时候要注意大 KEY 这些问题，如果写入的量比较大用 laravel 配合 Redis 做一个简单的队列，先写入队列再开几个 worker 慢慢消费，写入数据库中，写入数据库后删除 Redis 中对应的缓存信息，记得设置好 RDB 的备份周期（ Redis 备份恢复分析 KEY 就靠 RDB 了）

[bsder]

无语了，OP 上生产环境连 debug 都不关，还有 PHP 居然连 OPCACHE 也没配置，低级错误引发的“高并发”猜想。。

[elevioux]

线上 debug 不关，cache 没开，实在是。。。😬

[ferock]

@limingxinleo #170

“我确实来推一波框架”
“根本没必要做什么商务”

这脸疼不疼？歪楼也是你，撤了也是你，倒是挺始乱终弃的