阿八博客
  • 100000+

    文章

  • 23

    评论

  • 20

    友链

  • 最近新加了很多技术文章,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

Swoole rpc实践小结

欢迎来到阿八个人博客网站。本 阿八个人博客 网站提供最新的站长新闻,各种互联网资讯。 喜欢本站的朋友可以收藏本站,或者加QQ:我们大家一起来交流技术! URL链接:https://www.abboke.com/jsh/2019/0902/110461.html 1190000020258081

背景介绍
公司内部基础服务,基本上每个业务,每个页面都会调用的接口。随着业务的增加,在rpc服务提供之前,http接口每天的调用量有1亿次。原先有4台阿里云服务器(8C+32G),3台nginx+1台crontab,后来增加到5台nginx。业务高峰时负载较高,时常超过运维规定的报警峰值。
http接口:php 5.6.7 + yaf 2.3.5 + redis + MySQL

以其中标签业务为例:-最短响应(ms)<10ms<50ms读2.599.9%0.1%写7.573%27%RPC接口
php 7.1.9 + swoole 2.0.8 + zookeeper + redis + MySQL等
基于Swoole,实现dubbo的主要功能:服务注册+服务发现+监控+服务提供+服务消费,大致结构如下:

数据流:

效果

服务器配置数量http8C+32G5rpc8C+32G2

注:redis与mysql资源都是一样的。

使用rpc接口后数据与效果对比:-数据量最短响应(ms)<1ms<10ms<50mshttp读n2.50%99.9%0.1%http写m4.00%74%26%rpc读40n0.398%1.9%0.1%rpc写m0.928%62.5%9.5%

rpc读接口详细详细时间分布

服务器负载均降到1以内,业务高峰期不超过2

线上运行情况:

踩过的坑
4.1. 请求丢失(万分之几,周期性)
这个在开发初期,模拟线上业务长期压测的过程中出现。总是有周期性的丢包。联系过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模式下,注定一个请求的生命周期只有1次。也就是说,从FPM请求到请求,解析PHP脚本,FPM的Zend虚拟机分配资源执行,到最后的处理结束,PHP-FPM会回收这次请求的所有资源。所以高并发业务下,网络的处理会有劣势。
5.1.2. 对单个进程没有多线程的程序来说,如果频繁的有http接口的请求,服务容易被block。
5.2. 基于swoole的RPC方案,可以有效避免FPM模式的两个缺陷。
5.2.1. 维护连接池: worker常驻进程,可以保持对资源连接的连接池,并通过定期心跳维护连接保持。
5.2.2. 进程内使用协程,对每个资源的连接保存在SwooleChannel(高性能内存队列)内,不必考虑对资源的过多连接,协程处理请求又不相互影响。不同的资源连接在不同的资源池,不会相互影响,其中一个请求到IO时,底层会将IO事件注册到EventLoop,并让出执行权。接口请求并不会在进程里占用timeout时间。
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常驻进程解决。TODO
7.1 swoole协程对资源调用的IO操作有更好的处理,下一步在项目中验证。
7.2 使用协程抢占式调度器,解决单次请求响应时间过长/超时问题。

(刚看了一眼git tag记录,第一次上线时间是2018年5月22日,至今上线已有一年有余,至今稳定运行。 )

最后,欢迎路过的各路大神指点指正,互相交流。

相关文章

暂住......别动,不想说点什么吗?
  • 全部评论(0
    还没有评论,快来抢沙发吧!