当前位置: 首页 > 后端技术 > PHP

Swoolerpc实践总结

时间:2023-03-30 01:19:03 PHP

背景介绍公司内部的基础服务,基本上每个业务,每个页面都会调用接口。随着业务的增加,在没有提供rpc服务之前,http接口一天调用1亿次。本来阿里云服务器4台(8C+32G),3台nginx+1台crontab,后来增加到5台nginx。业务高峰期,负载高,经常超过运维规定的告警峰值。http接口:php5.6.7+yaf2.3.5+redis+MySQL以标签业务为例:-最短响应(ms)<10ms<50ms读取2.599.9%0.1%写入7.573%27%RPC接口php7.1.9+swoole2.0.8+zookeeper+redis+mysql等都是基于swoole实现dubbo的主要功能:服务注册+服务发现+监控+服务提供+服务消费,总体结构如下:数据流:效果服务器配置号http8C+32G5rpc8C+32G2注:redis和mysql资源是一样的。使用rpc接口后的数据及效果对比:-最短响应数据量(ms)<1ms<10ms<50mshttpreadn2.50%99.9%0.1%httpwritem4.00%74%26%rpcread40n0.398%1.9%0.1%rpcwritem0.928%62.5%9.5%rpcreadinterfacedetaileddetailedtimedistributionserverloadreducedtolessthan1,businesspeakperioddoesnotexceed2,periodically)这个出现在模拟长期的过程中在发展的早期阶段对在线业务进行压力测试。总是有周期性的丢包。联系了swoole的作者,让韩大帮我解决,然后我自己解决了。因为在worker进程中加入了SwooleTimer::tick(),所以我想做一个心跳,检查worker状态+保持tcp连接,如果去掉就不会丢包了。4.2.如何维护心跳给worker进程加上心跳好像影响了swoole的运行机制。通过订单的注册流程,worker定时发送消息,worker收到消息后进行检查维护。4.3.如何传递变量($_SERVER,调用链跟踪)专门设置一个环境变量的参数,传递给下一级请求。4.4.连接数增加(worker_num*数据库数)这是个大问题。我们的php-fpm调用mysql使用的短连接,每次请求后都会释放。rpc使用swoole常驻进程,连接mysql使用长连接。连接数=worker_num*数据库数。导致mysql服务器的连接数剧增,通过mycat解决。4.5.状态监控(worker_num,active_worker_num)通过订单的注册过程,定期向worker发送消息进行维护。对比探索现在比较流行的PHP运行模式是LNMP,PHP以PHP-FPM模式运行。PHP-FPM是多进程模式,master进程管理worker进程,worker实际运行代码处理请求。5.1.PHP-FPM模式下的几个问题:5.1.1。无连接池:在PHP-FPM模式下,注定一个请求的生命周期只有一次。也就是说,从FPM请求到请求,PHP脚本解析,FPM的Zend虚拟机分配资源执行,最后处理结束,PHP-FPM会回收本次请求的所有资源。所以在高并发的服务下,网络的处理就会有劣势。5.1.2.对于单进程没有多线程的程序,如果有频繁的HTTP接口请求,服务很可能会被阻塞。5.2.基于swoole的RPC方案可以有效避免FPM模式的两个缺陷。5.2.1.维护连接池:worker驻留进程可以为资源连接维护连接池,通过定时心跳来维护连接。5.2.2.进程中使用协程,每个资源的连接都存储在SwooleChannel(高性能内存队列)中,所以不需要考虑过多的资源连接,协程处理请求互不影响。不同的资源接入不同的资源池,互不影响。当其中一个请求IO时,底层会将IO事件注册到EventLoop中,并放弃执行权。接口请求在流程中不占用超时时间。5.2.3.驻留进程、配置文件和程序初始化加载都可以在初始化阶段(onWorkerStart)完成,省去了请求开始时的脚本初始化和请求结束时的资源释放,可以响应请求更快。5.3.swoole协程解决的问题:5.3.1.如果FPM模式下接口A的响应时间超时,不会影响下一个请求的处理和worker的处理能力;5.3.2.资源类的IO通过协程转移worker的主动权,可以提升整体的QPS能力;综上所述,基于swoole的tcp/rpc接口对于短、扁平、快速的接口具有更好的性能。http接口调用php-fpm初始化需要一定的时间,使用swoole常驻进程可以节省时间。http接口频繁请求打开和关闭连接,给服务器造成压力,也可以通过swoole常驻进程解决。TODO7.1swoole协程对资源调用的IO操作有更好的处理,下一步要在项目中验证。7.2使用协程抢占式调度器解决单个请求响应时间长/超时问题。(刚看了一下git标签记录,第一次上线是2018年5月22日,上线一年多了,一直稳定运行。)最后,欢迎各位过路大神指出并相互交流。