发消费券用webman做API适合么？各位大佬帮忙哦。

看的qps；如果qps有上万，建议使用go为一个高并发接口服务；其它业务可以使用webman；然后nginx作为代理负载

我主要这个不是常驻内存么，万一进程卡住了咋办

你之前用过webman么，觉得如何

除非数据库有问题挂了，不然怎么会卡住？webman我们一直在用，性能确实比fpm的好非常多。

嗯

之前没搞过高并发的，很多工具都不熟悉，嗯，谢谢

嗯，是呀，就是觉得牵扯太多。

务实👍

另外再多提一嘴,你这个业务算是比较简单的秒杀逻辑(至少从描述中看起来比较简单),可以考虑在业务上做优化(如果可以),采用先扣库存再进行后续逻辑处理的方式(比如队列),比较典型的例子就是常见的"优惠券将会在稍后发放到您的账户中"这种, 前面上个负载均衡,平时就一台机器,发券前提前多开几台,结束后降回一台

是的，现在用的就是，除了会员的生成用mysql有点大，其他都放到了redis里，然后服务器有个计划任务负责发券，当前自己用到时没啥问题。

客户想包装成产品，做云端，买个其他各城市的部门来发券，相当于重新搞一个新系统再。

负载均衡还没有上，这几天正在研究nginx搞这个，现在有3台服务器，打算用最弱的一台做分发，其他两台方程序。

@nitron 现在mysql是了一台高性能的数据库服务器，但是还是感觉慢，想做主从，不过之前没弄过，还没有搭建好。

上次在客户公众号上搞，因为要授权，必须跳转一次PHP做会员初始化，结果一次来太多人，当时开了1000个静态的fpm进程，卡在那里不动了。

最后过了十分钟还那样，重启了phpfpm后好了，我觉得是cpu（8核）已经到头了没能力处理进程了。

授权这个,因为从公众号获取用户信息需要服务器向微信服务器发起一个Http请求,这个涉及第三方系统,没办法.
注意不要重复获取access_token就好

是的，这个没有，access_token都是缓存了的，就是一次太多人访问。。不过也的确没有好的办法，下次弄负载均衡估计就解决了。

大佬发言给力呀，先优化，实在扛不住了再换webman，也别一下子全搬过来，高并发的请求可以用webman处理，多异步，这么高并发的请求应该不会有新增完数据就要看的，mysql的增加删除和修改全给它异步了，查询缓存一做基本io上redis扛得住，就问题不大

@tanhongbin 【这么高并发的请求应该不会有新增完数据就要看的，mysql的增加删除和修改全给它异步了】是什么意思哈？求

为啥那？swoole似乎学习成本有点高

IO操作多的话Swoole表现会更好，workerman在异步这块现在可以说是空白

哦，我了解下。

他本来就是没有常驻内存的经验，直接上swoole玩php协程非常不推荐，学习swoole的难度不亚于学习一门新语言例如go。
如果系统瓶颈在数据库，那上啥也没用。如果瓶颈在框架性能低下，上webman是很好的选择，学习基本没有成本，同样的代码写法性能提高数倍，稳定性也好与swoole，并且性能也比swoole高。

感谢各位兄弟的建议，嗯，项目也比较紧，学习太久估计不行，就一个月时间。

如果说没有扎实的网络与操作系统相关的基础或经验，别说用swoole了，就是用了go也难解决性能瓶颈！～
深（身）有体会！！ ^_^

看来要恶补基础知识啦

说的不错,记得我以前刚开始工作的时候,有个项目每天零点要执行任务,当时项目有8,9万个会员以后,执行任务需要2,3个小时才执行完,但是现在如果让我再执行同样的任务,也就是十几分钟的事情.

你现在咋搞的？

减少数据库查询,批量插入或者更新数据库,这些是从代码层面去优化sql. 一个接口能少查询一次sql,那高并发下一秒就是少上千次查询.

👍

为什么不学go?

好吧

怎么突然问这个了。

哇~

用redis了么，如果用了是放到了一台业务服务器上了么

没有用到redis

那mysql压力很大呀

我问下，你每个业务的机器上就是启动了一个webman是吧。

使用docker打包部署服务，每台机子部署2个

对于mysql和redis，如果有预算并且是要短期保证业务稳定，个人建议使用云服务。比如阿里云的云rds或云redis，都有集群版的，比自己部署的要好要稳定要便捷。自己部署的话，非专业运维，包括调优，监控等等都会比较麻烦，并且单机部署，流量，性能和IO，都会有瓶颈。

你这边是如何发券的，减库存跳转链接用户点击领取 或 减库存调用api接口？

减库存，然后后台有个计划任务负责发券。

计算任务是crontab，还是？

嗯嗯，是crontab

以下思路，仅供参考：

1. 流量分流（前端资源加cdn或放在对象存储上；后端的用作负载的服务器，性能要好，带宽要高，保证接口请求的流量稳定）
2. 后端服务负载均衡（后端服务多台服务器部署，负载处理业务，后续有压力可扩容）
3. 云mysql 或 云redis 做库存处理（mysql的原子操作 或 redis的lua脚本执行 保证不会超发）
4. 消息中间件做发券处理（redis消息队列或rabbitmq等，减库存后，将发券任务交给中间件，多个消费者服务同时发券处理）

使用crontab会造成任务堆积的

现在是在一个内存最大的服务器上安置了redis，所在的云上没有云redis，这时候其他机器通过局域网访问这台机器的redis你觉得会不会有问题那？

还有问个问题哈，常驻内存的，如果这个进程比如调用一些外部api服务，响应时间比较长，岂不是后面的都卡主了。

crontab 之前发生过数据问题，正在考虑换个

fpm也一样卡住，所以调用外部api需要控制好超时时间，比如设置1秒超时。

如果当前请求未处理完，其他的请求会等待。
具体的业务场景有不同的处理方案。要在接口中等待外部api请求完成，比如微信授权，则可以把该接口分离成一个单独的服务来部署，这样可避免影响其他业务 或 合理设置超时时间；若可异步处理，比如发券，可使用消息中间件服务。

我这边在使用mysql或redis服务时，结合使用场景，一般会从三个角度去考虑，流量，性能及多机活备。
通过内网访问，流量是没问题的，至于性能及活备，因为无法预知上线后的业务情况，所以无法评估你当前配置的redis服务有没有问题。

如果没有更好的方案，建议提前开发好业务功能，按照当前思路部署服务，然后做压测来定位服务瓶颈。

@静默 但是fpm不是每个请求开一个进程么，如果一个进程卡出，应该不影响其他的把

@CaesarTang 好的，太感谢了

fpm不是每个请求开一个进程，是的话一秒来1万个请求，服务器内存直接爆了。
都是预先开一些进程，每个进程排队处理消息，包括nginx也是一样。

@静默 是的，我的意思是说每个fpm进程间不互相干扰，不需要等待。

webman在前面加一层nginx也一样，新请求会发给空闲的进程，不互相干扰

@静默 哦

我想问下，redis是放到一个机器上么？比如负载均衡了3台机器，redis要单独放一个机器么？

redis放任一台服务器，只要能访问即可。

好的，谢谢，现在也有了一些思路，不过我估计要用你的那个大胆的方案，客户所在的云没有云redis。。。

redis单机一般问题也不大的。webman启动的时候加载带领取的卷id到redis里，领劵的时候redis取个出来，然后丢队列，队列update 到取mysql那。

肯定是政务云机房哪些。。。。。

@MarkGo 被你说对了，特麻烦，开个端口还得发邮件申请。

我们之前也用过，价格特别贵，然后window系统还要另外支付授权费用。申请端口和远程进去要用跳板机。

@ MarkGo 对啊对啊，超级麻烦，那个堡垒机传文件夹还不智能，上次开个443端口，说要和省里申报，最少要一天（非工作日）才能过。

让加个白名单，相当不愿意。