大量的 curl 导致 fpm 访问变慢甚至访问失败

问题:当大量的支付请求创建以后就会出现访问很慢甚至不能访问的情况 并且我们无数据库操做 全部都是操做 redis 可以忽略我们这边的 mysqlIO 情况#

服务器环境: 3 台 2 核 8G 的服务器#

事情背景: 公司做第三方支付业务 需要请求上有的支付接口实时返回给商户支付 并反馈相关的支付结果,上游的支付接口由于会请求银行 银行接口又非常慢 基本都在好几秒#

想要的结果 由于改造成 swoole 和 go 的成本太大 希望大家能够帮忙给出其他的方案#

《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 5
php炎黄

php 就这样,你换成 go 或者 swoole 应该会好些

5年前 评论
carter (楼主) 5年前

应该是有接入你们自己的前端 sdk 的吧,感觉可以改造前端 SDK。1:自己服务器做一个简单的下单操作,返回一些参数给前端,让前端直接请求银行?2:把请求银行的操作交给队列处理,前端过几秒再请求队列处理状态,返回参数?

5年前 评论
carter (楼主) 5年前

这个业务和我司的支付项目类似,我们是创建订单写队列的,消费队列请求上游,再通过回调给下游商户结果

5年前 评论
carter (楼主) 5年前

改成异步操作这是解决的方式之一,异步操作可以用 guzzlehttp 或者队列都行。看下银行接口是否给了 webhook 的功能,如果没有的话,使用专业队列也能解决。
但问题的本质是银行接口又非常慢 基本都在好几秒依旧存在,至少当前的异步方案可以解决访问很慢甚至不能访问的情况
最后说一点,phper 不要迷信 swoole 或者 go,我呆过的公司使用 fpm 模式也能很好抗住流量。

5年前 评论
carter (楼主) 5年前

一台 WEB 服务器才多少成本?按你说的配置,一台 WEB 最多 40 个进程,3 台 120 个进程,一个 PHP 执行 4 秒。相当于每秒可以支付 30 个支付请求?每秒 30 个支付请求。还差几台 WEB 服务器的成本?

另外看到很多人现在上来就是 SWOOLE 或是 GO,如果你是 SWOOLE 或是 GO 的高手,那么怎么都行。如果你是新手,你们有没有想过,如果线上环境突然出问题了,你多长时间能解决?这个时间内对业务对项目会有多大的影响。 选东西要综合自己的实情,另外如果逻辑或是代码不能解决的,最安全最有效的方式就是增加服务器。你就是加一倍的 WEB 服务器,一个月也才增加 700 块钱的成本,比起你别的什么方案都靠谱的多。

当然如果你有成千上成万台服务器,那另说,我估计整个社区的人员里面用的到成千上万的服务器的人也不多。再说了整个中国互联网能用到成千上成的服务器的项目也没有几个

5年前 评论
carter (楼主) 5年前
carter (楼主) 5年前
dongjw321 (作者) 5年前