首先感谢大神提供这么好用框架
背景:公司api项目以前用提tp框架,性能不高,qps才几百。现用workerman的WebServer来实现api开发,性能非常好,相比以前nginx+php-fpm模式,性能提升几十倍。
但是单机处理请求数是有极限的,所以想通过办法水平扩展增加服务器来提高qps,目标是达到并发1万,响应时间在100ms以内
可能的办法:
1.nginx(1台) + workerman(多台) + DB(多台):nginx负责所有请求分发,workerman处理数据并返回给nginx。这种方案难点在于 nginx如何与worker通信,协议如何制定?客户端通过nginx转发给workerman处理,增加一层网络开销,性能是否会有影响?
[attach]1734[/attach]
说明:
2.1)启动WebServer,开启5个子进程,监听客户端请求
2.2) 启动多个业务服务(假设服务为:Worker),并写入自己的ip+port到文件中。
2.3) 当有客户端请求来时,WebServer建立到Worker异步tpc连接
2.4) Worker处理完数据返回给WebServer
2.5) Worker返回数据给客户端
在这个设计中,WebServer相当于gateway/worker模型中的gateway, 业务服务相当于worker进程。WebServer进程开启一个定时器,读取注册的业务服务器ip+port,采用某种算法(假设随机抽取)分发请求。不知道这种方案是否可行,有没有需要改进的地方??(注:没有用gateway/worker框架是因为和客户端不需要长连接)
方案1,nginx可以直接做透明tcp代理,直接将请求转发给后端的workerman,不用考虑nginx和workerman之间的通讯协议。缺点是加了一层nginx,性能有一点点损耗,另外量大了nginx自身容易出现瓶颈,如果nginx故障则可能出现全站不可用的问题。
方案2,对于webserver而言,方案2过于复杂了。
方案3,最简单并且性能无损耗的是方案3 DNS轮询,请求量小的时候看起来可能不太均衡,请求量大的话是趋近于均衡的。如果某台服务器出现故障,会影响部分请求。
如果要想性能好并且均衡的话可以用lvs(阿里云的lbs)。如果某台服务器出现故障会自动踢出。
如果我选的话我会选择dns轮询,其次是lvs(lbs)。
非常感谢大神提供的意见,这么快的速度就回复了