既然小程序了，就已经前后分离了；
具体业务你没提，我只能大概说说，

1 、活动页面，进入后 请求后端，后端能正常回应的话进入业务流程，不能正常回应的继续等待或定时重发请求；（此时界面丢个 loadding 的 gif 即可。
2 、后端先自己压测下，能接受多少请求，我看你这都是 socket 实现的，那就建立连接后 redis 计数器+1 ，断开连接后 redis 计数器-1 ，首次发起连接时候通过 redis 计数器来判断是否达到峰值（对应第一点）。



最后，你的问题是数据库 CPU 达到 100%，这种情况我觉得应该优先排查 SQL 语句，尤其是看慢查日志，一般出现这些问题基本都是 SQL 语句的问题。
分流对你并不适合，你的问题是数据库 CPU 100%，不是业务机器 CPU 100%。

@markgor 忽略我这个回答，如 2L 所说已经开放了，2 个月前我还在研究这种 URL

之前我用过 frp ，后来换成了向日葵....
因为主板不支持 WOL ，所以买了个向日葵的联网插座，控制电脑开关。
而且我还不用搭一台轻量云进去，还免去了运维这部分

之前研究过，但不算透彻；
1 、微信有开放接口给大厂商或合作商，但这个接口没对外开放；
2 、早期京东有个生成这个链接的接口，传入跳转 URL ，返回 ticket ，后来失效了，JD 对接口链接域名做了限制；
3 、现在市面上有生成这种链接的平台，他们估计都是利用类似第二点的方式生成的；（据我所知 JD 和 PDD 都有这个接口权限，还有没有其他的我就不清楚了

@NotreDame 阿里云的产品我不清楚，腾讯云的话 oss 对象外网访问是会产生外网费用，但不是走 cvm 带宽。

@NotreDame
可以給你参考，不过我用的是腾讯云，
resource.xxx.com -> COS 对象存储 ->回源地址 -> 源服务器。
这样当请求 A.JPG 文件 不存在时，COS 会回去源服务器拉取，然后存在 COS 。
代码中几乎不用改动（前提是资源域名做了划分，COS 可否根据请求类型区分是否回源我不确定。
提醒下，COS 回源有超时策略，大文件不多的情况下建议直接把大文件手动转移到同目录下的 COS 。
剩余的小文件就按上面的策略跑。

如果都是大文件的话那还是直接用工具转移去 COS 吧.

实话说，你要弄清楚哪部分卡；
1 、就算 ts 切片，你服务器带宽就 5M ，10 个人在线看，还不是照样卡吗？
2 、不知道你后端业务是怎样的，nginx 的话大文件会自动 range ，类似 ts 切片，一次加载一部分，大多数浏览器都支持 range 请求；但和第一点一样，带宽如何？
3 、一个视频几百兆，首先要做的就是针对请求限流吧？次要就是看带宽是否能支持；
4 、其实国内 CDN 大多按量计费，你这种场景非常适合上 CDN ，费用起码比你加大服务器带宽要便宜的多。
5 、如果一毛不拔，建议上传第三方视频平台。

我之前也试过，后来马上改了；
1 、部分产品允许超售，此时就会出现-1 的情况，无法分辨是超售了还是无限；
2 、设置为 NULL ，业务代码判断的时候需要单独区分判断，可以这样做，但对后续业务代码不友善；
3 、增加栏位，设定为是否不限库存；

最终我们选择的是第三点；
因为产品允许 超售|库存|不限；
包括后来增加的功能，部分产品需要二次询价，比方 A 给我们一个基本价，库存 10 ，超出库存的要二次确认，我们有单就飞过去，超出库存部分是否能做由他们决定，这种的话业务上会设置为库存产品|允许超售；
1 、因为业务需要统计还剩多少没卖，所以不能设定为不限库存产品；
2 、由于超出时候不是不能卖，只是流程上需要供应二次确认，所以只能设定为 可超售。

所以建议你还是加多个栏位进行判断。
BTW：
我们有些直连对接的分销，业务关系，我们不会反回这种产品究竟是 可超 /不可超 /库存数量这些的，一般情况下可超或库存大于 999 的直接返回 999 ；

@void1900
换种说法可能更容易理解；
nginx/httpd 如何知道这个文件需要转发给 phpfpm 还是直接读取返回呢？
这时候一般就几种方式；
1 、根据后缀来判断是否 php 文件；（其实就是#15 说的“解析文件时要么根据 MIME （后缀名也算）”
2 、根据目录转发请求；这种就和你所说的，和 mime 毫无关联
3 、全部请求转发，相当于 nginx 进行反代或均衡或缓存等；如 webman 框架，框架自身自带处理静态文件，上级的 nginx 做负载。

@jeeyong 你是在说某程吗，之前研究过携某的反爬，发现他们会通过浏览器特性来判断爬虫，
一但判定为爬虫，会直接返回相对高的价格，甚至后来直接不管是不是爬虫，列表价直接返回浮动价，只有预定价才会返回真实价，前端就弹出恭喜你，价格降低 xxx 之类的。

@void1900
常规场景下他说的没错，
apache 太久没碰不确认，但依稀记得是通过 AddType 添加 PHP 的 mime 进去的
nginx 的话就是看配置.php 后缀然后转发 php-fpm

当然也有场景是 php 直接监听端口，nginx 按目录请求转发到端口，这种就和 mime 没关系。


回到 LZ 的问题，
Nginx 通过 phpfpm 转发的话 fpm 挂了，那么会产生 5XX 错误，不会反回源码；
一般反回源码的情况是 Nginx/Httpd 没配置好的时候（即没把解析 PHP 配置好），就会出现反回源码。

站群、咨询类的 PHP 居多，因为真快也不用考虑效率。
业务系统类的，PHP 占有率不算高，因为这一块真要用 PHP 去堆砌，暂时发现性能跟得上的只有 swoole 和 workman，
但实话说 workman 或 swoole 的开发思想上和平常的真不同，特别是 swoole 。

使用者的心态：
1 、你开源了就必须对项目和使用者负责；
2 、我现在使用了你的项目，出了问题，我需要的是第一时间解决，而不是参考一大堆资料才找到答案。

开源者的心态：
1 、我只是把我的思路开放供参考；
2 、线上服务使用了出现问题可以提 issue，回复效率取决于我的时间。

能理解使用者的心态，但不支持使用者的这种行为；
首先他需要弄明白什么叫 “商业支持”，大家的时间都很宝贵，
并且漫无目的的喷码不是解决问题的方法。
对于这种人，没必要回复，实在气不过，直接把记录截图放到项目首页作为申明。

好奇问问，JS 属于吗？
在服务端，有 nodeJs
在 web 端，有 vue
在 app 端，有 uniapp （本质也是 vue
在 pc 客户端，有 electron
好像真的什么场景都有 JS 的身影

@2i2Re2PLMaDnghL 感謝提點，後續我把那兩個思路也進行測試下；可能換 Oracle 會得到更好的效果，但投入也是巨大的。

@2i2Re2PLMaDnghL
Oracel 之前某个业务使用过，但就目前个人对 Oracle 各项优化方式和使用上并不熟悉，除非 Oracle 内部对查询器进行了优化，否则我觉得性能上估计相差不大，而且除去成本而言，用 Oracle 的话太多关联的程序需要改动，代价太大了；

之前也有业务上使用 Oracle，当时大概是因为 需要通过存储函数 触发 脚本运行 把数据提交去上级的 Oracle 中。

@2i2Re2PLMaDnghL

》且抛开这个
SELECT id FROM tbl_price price WHERE price.bookDate BETWEEN '2021-10-10' AND '2021-10-17'
170W 左右的數據，耗時 1.3 秒；

SELECT * FROM tbl_price price WHERE price.bookDate BETWEEN '2021-10-10' AND '2021-10-17'
170W 左右的數據，耗時 23 秒；

第 2 點測試過，效果基本沒變化；
第一點由於要加欄位，所以只能後續在測試環境中測試下

@wowbaby 业务形式不一样，我们的是酒店价格，所以价格是按日为单位，每天的都不一样，
酒店--product
房间--spu
销售计划--sku

常规商城的价格这个放去 sku 表中，
但酒店由于每天房型价格都不一样，所以还会多一个价格表，记录销售计划和销售日期 的售价；
比方说：
汉庭酒店
|--标准房
|----当天可售
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|----提前 3 天预定
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|----不可取消
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|--豪华房
|----当天可售
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|----连住优惠
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......


实际业务情况是
可能哪天，整个房型都需要停售，这时候 spu 上的 isActive 就设置为 0 ；
可能哪天，某个房型的销售计划停售，这时候这个 sku 的 isActive 就设置为 0 ；
可能哪一天的房停售，这个时候 price 的 isActive 就会设置为 0 ；


一般情况下，当携带酒店 ID 和入住日期去查询信息，返回时间基本是毫秒级别；
仅仅是当需要显示列表形式的时候（只有入住日期没有酒店 ID ），查询时间十多秒。