关于 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 几秒才能打开，这种情况请大神指点

嚯，没想到引发了热议，对语言和框架就不评判了，目前确定 opcache 生效后，DEBUG 关闭后，5 分钟 30 万读和 4700 医护人员同时开管扫码加人速度提高了 10 倍不止，目前程序每个接口运行 1.7S ，速度很快，感谢各位大佬

“确定 opcache 生效和 DEBUG 关闭后”这个是一个确定语句，伙计们，勿喷
具体做了，直接取 redis 缓存，不用直接操作数据库，只有在用户更换采集点的时候去修改下缓存，以及而且大量操作的时候添加了一下锁；

已解决，数据库调整一下，不用分库分表，做索引，优化下缓存就解决问题了，大佬们不用讨论框架的问题了，FPM 是没有问题的

关于 QPS ，回答大家一下，崩的时候 QPS 才 7K 多，崩的原因是请求数过高，瞬时 1 万 5 ，导致 CPU 过载

[Dart]

是 DB 卡吧～～～～。 做个 queue 不就行了？？

[iSecret]

遇到过高并发 CPU 打满的问题，大概率 SQL 问题，70# 说得很对，得先排查读写压力，再尝试做缓存。

[fuchish112]

mark 一下，后续反馈处理结果呀，以及到底啥原因造成的

[yangqingrong]

这个需要分表，分库。mysql 调优。还需要用 nio 之类的技术。

[markgor]

>数据库和应用服务器的 CPU 利用率都打到了 100%
提议换 GO/JAVA 的，请问是 JAVA 或 GO 有超能力使 MYSQL 不被 100%吗？
如果不是的话，建议关注点还是放在 SQL 上。
数据库 100%后，应用服务器开始堆积请求，自然就大家 100%了。
遇到那么明显的问题，建议还是老老实实排查 SQL 语句吧。

[markgor]

1 、排查下 SQL ，rds 应该有配 slowLog 的啊，直接查 rds 的慢查日志。
2 、是否涉及 curl 操作，如果有设计 curl 的操作自己抽取出来或者在 curl 附近做做监测，看是否 curl 导致挂起。
3 、larave 的话建议可以替换为 webman ，但涉及改动，等哪天不是数据库 CPU100%再去考虑吧

[d119]

还是要分布式，读写分离、动静分离、高低频分离来应对这种情况，如此才好做扩展，并且能快速定位问题。

[shanghai1998]

1 可以自己用阿里云压测看下并发，你这种系统应该要 1wQPS 才好使

2 这种情况我们遇到过，原因是 php mysql 组件会占用数据库链接，导致链接数据库卡死

3 解决方案，接口换 swoole 或 go ，php fast_cgi 模式过万真的吃力

[dyyhobby]

1 、前端资源图片 js 走七牛或者阿里 OSS
2 、将 php-fpm 进程数调整到 cpu x2 并设置为静态调整。
3 、开启 opcache 将并设置缓存文件数和内存使用数等。
4 、检查 mysql 查询，利用索引优化慢查询。
5 、检查 mysql 连接数避免超出连接数。
6 、检查 mysql cpu 和内存使用频率，不可超出 80%。
7 、mysql 应读使用写分离。
8 、接口响应应低于 100ms 。
9 、如果还是很难撑过去，先读写 Reids 再同步到 MySQL 。

[running17]

和我们之前接的一个重构成 java 的项目有点像，主要瓶颈其实在递归死锁还有 SQL 上面，最早原逻辑重构到 java 也是扛不住 20w 的并发，后面整个逻辑重写+涉及的 SQL 挨条排查优化+能用缓存全部上缓存，还有一条就是不管 mysql 还是 redis 全部用 rds 后，很平稳的就撑过去了

[zhaokun]

有可能是服务器连接达到了最大限制，也可能是 fpm 进程数量达到了最大限制

[shuimugan]

阿里云 rds 有诊断报告，选中那个时间段，然后诊断一下，把报告脱敏出来看看呗

[gengchun]

不是自己开发的系统，至少火焰图整一张出来吧，APM 也上一下。一帮人瞎猜不知道猜到什么时候。

[reneiw]

如果你机器利用率上不去，看下你的 php-fpm 子进程的数量，尝试用固定模式并调大数值

[yumobs]

前端页面会变得非常慢,优化前端嘛做个 CDN 分布式嘛分开服务器放

[buaacss]

我说下我们排查这种问题的思路

1 、首先可以开一下阿里云 slb 的访问日志，你要先分析出所有的请求里哪些接口的请求是最多的，哪些是最慢的。sls 非常方便做统计和排查，比如访问最多的前 10 个 request_uri：
* | select request_uri, count(*) as cnt group by request_uri order by cnt desc limit 10 ，如果你的 request_uri 带有不同的 get 参数，可以用 split 处理一下；
访问最慢的* | select request_uri, request_time where request_time > 3 order by request_time desc

后面你说服务器 load 20%都上不去，要先确定 slb 这里有没有问题，因为 slb 的规格非常重要，首先您要看这里有没有丢弃的流量

2 、做好全平台监控。可以快速使用 cloudmonitor 建立全平台的监控大盘，包括 slb 、ecs 、memcache 、redis 、rds 、nat 。所有资源的 cpu 、内存、连接数使用率。

3 、做压测，在压测的时候看哪块是瓶颈，可以针对性优化。
1 、opcache 有没有开
2 、ecs sys 有没有很高，如果有可以通过 strace 或者 perf 看是什么系统调用占用导致
3 、全平台监控看哪儿有具体的瓶颈
4 、用 xhprof 看具体的 php 函数指标，找出调用链上的瓶颈

4 、优化
通过你的描述，比如创建临时采集点的时候，如果是录入信息太多，可否先用 mns 来写入到一个 queue 里，php 这边启动几个 consumer 来写入数据库，同时刷一个 memcache 缓存，前端可以通过查询缓存的方式来避免数据库的压力


其他的信息还比较少，暂时能想到的就这些，祝好运

[geligaoli]

嘿，楼主是不是在石家庄东软？ 我也做了套功能类似的核酸检测系统，thinkphp 版本的，实际运行一小时的峰值 4 万的时候还是很稳定未崩溃过。硬件配置是单台阿里云的特价 4 核 16G 。这种检测系统业务逻辑并不复杂，如果一小时四十万的峰值，我会做标配的数据库的分库分表、读写负载均衡，然后努力加缓存，数据异步入库，避免数据库锁。管码和用户信息在 APP 端做缓存并批量上传。再者说，这么赚钱的业务，就用几台服务器，公司真是会找省钱的。

[Joker520]

大概率 sql 问题

[limingxinleo]

换成 Hyperf 框架，解决战斗！！

[geligaoli]

就一个优化方向，php 尽量使用 redis 缓存，尽量减少数据库连接和读写操作。

[ferock]

为什么有的人动不动 swoole ，真的是来解决问题的么？还是来制造问题的？

[liunan1321]

试下

[undefinedList]

楼上那些上来就说：竟然用 PHP 的
php 是吃你家大米了还是害了你了？项目写的不好和 PHP 啥关系，上来就喷，真就为喷而喷呗。

1 、首先人现有的系统正在跑，重写现有的系统这个代价还是很大的~
2 、其次根据描述，还是开 sql 慢日志 + fpm 慢日志 + opcache
3 、根据 2 的日志查并改，短时间之内能加钱就不要考虑其他。确定能解决找个低谷期或同配置复制机器去做压测。

大概率数据库的问题

OP 有结果了记得这里通知下~我想大家也都好奇你们是个什么情况， 当然，再出个溯源帖子是最棒了~

其他：我这边接手别人的烂项目主要问题出在：mysql 的索引上，看似有索引但 SQL 不规范导致的类型转换会没有使用上索引，规范 SQL 解决

[liunan1321]

试下：
1. Laravel 加路由缓存了吗？ php artisan route:cache
2. 排查有没有 N+1 问题
3. 看你用了 redis ，那 Laravel 尽量能异步处理的任务都扔 redis 队列中去处理
4. 数据实时性要求不高的页面，全部用 redis 缓存处理

[pengtdyd]

PHP 也能谈并发了？？？ C 是不配还是怎么地。

[pengtdyd]

历史的教训告诉我们不要试图去优化一坨 s ，你应该做的是立刻丢弃它。

[pastor]

golang 火的依据+1

[limingxinleo]

@ferock 为什么提 Swoole ，是因为这个量，用 Swoole 真的很容易就顶住了。。。

哪来这么多麻烦事呢

[tobeagoodfather]

盲猜问题在数据层面。

[tobeagoodfather]

上一条没写完。建议楼主关注下查询和修改是否都命中索引，还有表设计是否合理。另外，看下日志里每次查询所花费的时间，关注重点接口的 sql 耗时，或者 db 的慢查询日志，逐条处理。还要看下 db 的连接数控制，阿里云的 rds 支持中间件，可以处理长连接，建议用上（不用改代码）。或者看下 Laravel 是否支持 db 长连接配置。

[JaguarJack]

坐等 OP 打楼上喷 PHP 性能的。从 OP 的描述来看，明显是代码写的有问题，大概是 SQL 导致的。

还有别一遇到性能就是 Swoole ，一个扩展社区都分裂。谁敢用呢？引入 Swoole ，只会引入新问题

[limingxinleo]

现阶段，如果不差钱的话，多加应用服务器放 Laravel 代码，然后 MySQL 加一个 代理，用来处理和 MySQL 的连接池。

或者不要代理，直接把 MySQL 写库性能顶到最高，加一排只读库。

都可以迅速解决问题。后面再慢慢排查吧。

[lait233]

swoole 口碑变差就是这帮无脑说 swoole 的人。人家已经定型的项目一直在这 BBswoole 。现在要的是 FPM 模式下的代优化和数据库优化。

[HalfaMillion]

哈哈 12306 为什么不用 swoole 做，swoole 这么牛掰

[HalfaMillion]

不对，还有 hypef

[suyuyu]

larave 高并发，，，上 swoole

[chowhwei]

卡在哪里知道吗？

[pxllong]

1 阿里云的 rds 对短连接不用好，先启用 php 长链接用阿里云的数据库代理，多开几个 rds 的从节点。
2. 配置这么高的 ecs 有点浪费。
3. 检查下数据库的慢查询和 php 的 slow log ，提前规划好分表， 建议用阿里云的 PolarDB.省去分表烦恼
4. 优化下访问链路 cdn->slb->ecs
5.大招 空间换时间了 redis 先抗住流量而不是打不开

[MoYi123]

larave 再差也是世界知名的框架, 并发量也不是很高, 一般情况都是先怀疑自己的代码的问题吧.

遇到性能问题上来就什么 GC 调优, 换框架, 加缓存, 加消息队列的感觉会把问题复杂化.

[limingxinleo]

加配置如果能顶住的话，就可以了。
多花点钱而已。
然后开始一点一点重构，无论是 Swoole 还是 Workerman 都行。

在 V2EX 里说 Swoole 很容易遭嘲讽，那就 Workerman 配合 fiber 。

[ferock]

@limingxinleo #128

现在改架构？你这是可行性方案么？何况性能瓶颈是换个架构就解决了？如果是屎山，用其他架构依然是一坨屎山
你怎么不说：“ 底层用 c 写 so 保证速度嗖嗖的？用 clang 真的很容易就顶住了。。。哪来这么多麻烦事呢”

这种方向正确的废话，对 LZ 有什么帮助？

[ferock]

@JaguarJack #131

“明显是代码写的有问题” +1
最反感那种不分析实际问题，动不动就大动干戈的人。

写出垃圾代码的项目，换什么都依然是产出垃圾代码

[HalfaMillion]

@ferock 他只管推自己的框架，这么牛批的 hyperf 当年不知为何 12306 没用他

[rapperx2]

“但前端页面会变得非常慢，基本上 10 几秒才能打开”， 端口数量不够用了吧，优化下 Linux ？

[limingxinleo]

@HalfaMillion 你这就是抬杠了，12306 你换什么都顶不住，早就不是一个框架能解决的问题了。

但是楼主这个问题，显然现在已经通过硬件加配顶住了，下一步重构是无可避免的。

另外，我确实来推一波框架，用 Swoole 真没这么多麻烦事。Swoole 的框架都自带连接池，这个问题绝对不是什么大问题。

@ferock 而且我第二个回复也说过了，楼主这个问题大概率是 MySQL 的问题，加个代理，80%的可能性可以解决这个问题。

[star7th]

作为一个有用 php 跑过生产环境的人，我想说，你这个服务器配置没问题，甚至说冗余了。我觉得大概率问题出现在 IO 上，导致没发挥出服务器性能。重点检查 nginx 的并发设计和 mysql 的慢查询日志。php 本身大概率不是瓶颈。

[limingxinleo]

@ferock @HalfaMillion 另外我真的懒得在这里推 Swoole ，这里的 PHP 氛围早就感受过了。

如果不是碰到这么个帖子，群友发给我的，我还真懒得来看。

不过在 PHP 环境里讨论高并发，确实能引出一大堆人来。

[HalfaMillion]

@limingxinleo 不是你个 213 上来说什么用 hyperf 秒杀一切问题？

[limingxinleo]

@ferock 另外，我还记得你。。我还记得你当时在这里说 Swoft 。。主动引战

[ToBeHacker]

进程线程模型处理大并发是很弱的

[rapperx2]

@defunct9 大哥开 SSH 让你上去看看？

[HalfaMillion]

@limingxinleo 换成 Hyperf 框架，解决战斗！！ 不是你原话？

[limingxinleo]

@HalfaMillion 我可没说秒杀一切问题，我只是说解决战斗而已。

一切问题这么绝对的事情，是你说的

[HalfaMillion]

@limingxinleo 你咋不说用 c 语言重写呢？

[HalfaMillion]

@limingxinleo 你咋不上天呢？

[limingxinleo]

@HalfaMillion 不过说真的，这个量级，换成 Hyperf 确实很容易就解决。

当然，最主要的原因还是因为 Swoole 的能力而已。

就算不用 Swoole ，重构成 webman ，加个 Mysql 连接池也可以处理。

当然，SQL 优化这些，肯定也要慢慢处理。

[limingxinleo]

@HalfaMillion 为啥要上天呢？这个量级跟真正的高并发比起来，真的不大。。。

FPM 、同步 IO 真的有瓶颈。。。

你不能不承认

[limingxinleo]

@HalfaMillion 而且，系统迟早都要重构的，重构的时候选型是必要的。

就算是屎山，你也得铲掉。

[noyidoit]

@limingxinleo 性能差距确实巨大, 我以前用 ab 小测了一下, 就一个输入 helloworld 的接口, swoole QPS 10000+, laravel 400...... laravel 文档里说过的优化部署都已经做过了

[xcsoft]

前端使用的是 vue. 打开速度慢 可以考虑将把静态文件加上 cdn 吧。
后端尝试使用 workerman 等框架

[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

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

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

[documentzhangx66]

@JaguarJack

1.PHP 本来就是有性能问题，只会 PHP 的入门程序员当然不知道。

2.Mysql 也有性能问题，真正的大佬会选 Mysql 企业版、Mariadb 、Percona 。知道为啥嘛？

3.那些说用 Redis 的也是醉了，一个简单的数据读写业务，还需要 Redis ？多大点数据？直接内存缓存不香嘛？

[ferock]

本来就一些基本优化就有 “速度提高了 10 倍不止” 的收益的事情，非要搞个 “重构”？
不重构没法显得自己技术牛逼？还是那句话


是来解决问题的还是来制造问题再解决制造的问题？

[minuo0day]

@ferock 问题解决了就好了，老哥，莫生气

[KasuganoSoras]

Swoole 一把梭，4 核 16G 机器，Mariadb 数据库+连接池，配合 Redis 缓存，正常业务查询可以做到 5~6W QPS ，简单查询可以做到 10~15w QPS ，我们公司现在就在用。
另外 Laravel 也可以轻松迁到 Swoole 的，详见 https://github.com/swooletw/laravel-swoole

[hefish]

贵公司跟 ZF 的关系通常都比较硬，没事的。

[Felldeadbird]

@minuo0day 看到了。第一次附言我以为是检查 opcache 有没有生效。生效后结束 DEBUG 。 。。

[JaguarJack]

@documentzhangx66 PHP 会有性能瓶颈。但是针对 op 情况，肯定不存在性能瓶颈的。从他的附言来看，已经无需多做解释

[kingjpa]

@JaguarJack 你就不该搭理那个 x66 键盘侠，30 万请求在他眼里都是可以直接写内存的， 他这种人除了会敲键盘 ，估计连个百人并发项目都没做过

[ahu]

@minuo0day 希望 OP 能做到管挖也管埋 😆

最后是否解决了？怎么解决的？也请及时的介绍一下，不枉这么多热心 V2er 给你出谋划策。

谢谢！

[defunct9]

@rapperx2 叫我上去的话，我估计会把它整个架构弄成 K8S 的。

[minuo0day]

@ahu 就是数据库索引还有队列优化和 redIs 缓存优化，把更多的资源请求和回源放到了 oss 和 redis

[yc8332]

直接抗流量用数据库不死就怪了。。。加一层 redis ，这个流量一点问题没有。。这个和语言没关系

[cagev5]

就喜欢这种用技术解答说明的，看不起那种既不解答直接就怼下的。

[xiaotianhu]

laravel-s/swoole 是个不错的解决方式，但是有风险。

可以找到哪个请求量不小，但是速度比较慢的接口，单独部署 2 台服务器走 laravle-s/swoole ，用 nginx rewrite 一下就行；如果失败了在走传统的 FPM 。
这样就 1-2 个接口，比较好测试，出了问题也好降级，随便弄 2 个 4 核 8G 的 ECS 就能抗住很多量了。

[yc8332]

这种流量不要去搞什么 php 常驻进程的 swoole 之类的，因为没必要，而且有很大的风险。。你们都不熟悉。。这种问题就是加一层缓存就好了，不要让性能瓶颈落到 mysql ，如果缓存还不行就是加个队列，把耗时的异常处理一下。。laravel 并发问题更容易解决了，多开几台 web 服务器，配置不用太高。成本又低

[wangsfox]

既然已经迁移到阿里云, 那就建议购买个阿里云队列服务, 调整一下请求的策略, 前端直接请求队列服务, php 程序作为队列服务的消费者在队列之后消费请求

[lysS]

语言不是太大瓶颈，数据库才是

[ElmerZhang]

楼主提供的只是些服务器、场景、性能数据等外围数据，单根据这些没办法给出准确的优化建议。
如果可以让我看数据库结构和源码的话可以微信联系我，就这场景单请求降到 100ms 以内应该不是问题。
微信号同 v2 id 。
PS：无偿的，只是想为防疫做点事情，我排队核酸时也遇到过系统崩溃的情况。

[ElmerZhang]

顺便说一下，楼上让你换框架换语言的都不要理他们，这种场景下框架和语言带来的影响不会超过 5ms

[minuo0day]

@ElmerZhang 感谢大牛，目前问题已经解决，各方派过来的技术团队都在做支撑，现在的情况基本应对轻松，如果有需要，再叨扰你，感谢~