使用webman做短连接, gatewaywork长链接的一些问题

0

是这样的,本身需求有短连接和长链接


虽然webman可以自定义websocket,但是改了代码就会reload,或者业务频繁变动都会导致链接断开,所以针对长链接还是想用gatewaywork


如果这样配合的话,业务也不想写在gatewaywork,准备gateway只做网关用,在gateway的worker只处理一下最初的鉴权,然后绑定分组


消息的发送全部由webman使用gatewayclient来进行发送,可能的流程会是这样


用户点了某个按钮,发齐http到webman,webman业务代码
第一种:里根据逻辑发送了一个延时队列,然后webman http response用户信息,过了一会,队列执行了,然后队列里面通过gatewayclient给用户发送了一个消息,用户监听的websocket又收到了一条长链接信息
第二种:在业务代码直接调用gatewayclient给另一个用户发了一条推送消息,然后用户收到了自己的webman response


就是这种使用方式,会不会有什么坑


另外确认下 不管是 队列还是自定义进程,还是业务进程 reload都是安全的吧,都是执行完当前请求,退出,而不是立刻结束掉自己对吧,就是reload对代码执行是安全的

已邀请:

walkor

赞同来自: cai584887013

-



第二种:在业务代码直接调用gatewayclient给另一个用户发了一条推送消息,然后用户收到了自己的webman response



感觉这种方式更好一些。



另外确认下 不管是 队列还是自定义进程,还是业务进程 reload都是安全的吧,都是执行完当前请求,退出



大部分情况下是安全的。不过如果业务在2秒内没完成,进程会被强行杀死,这个时候是不安全的。



另外再补充一个忘了的比较重要的事,使用-d 守护进程后,如果进程因为什么原因崩掉了一般建议使用什么服务防止这个问题呢,推荐的额外的守护进程使用什么合适



workerman 主进程不处理任何业务,很稳定,所以不用担心主进程崩掉的情况。



workerman/crontab 这个组件我看默认启动是一个进程,启动两个进程会导致任务执行两次,请问这个是只能启动一个吗,这样的话会不会任务多了遇到性能问题,有什么方案吗



workerman/crontab 无法智能理解你任务的内容,无法根据你的业务自动做排重。多进程的时候需要自己写业务做排重。不同的任务排重方案可能不同,例如发邮件,你可以按照 用户uid % 进程数==$worker->id 来分散任务排重。
关于性能问题,一般定时任务处理的业务量都不大,大部分情况不需要考虑性能。如果你要极致性能,也可以考虑弄个队列(比如workerman/redis-queue),定时任务将大任务分散成多个小任务投递到队列,多个消费者一起消费。

dingdejing

赞同来自:

另外再补充一个忘了的比较重要的事,使用-d 守护进程后,如果进程因为什么原因崩掉了一般建议使用什么服务防止这个问题呢,推荐的额外的守护进程使用什么合适

dingdejing

赞同来自:

还要补充一个疑问
workerman/crontab 这个组件我看默认启动是一个进程,启动两个进程会导致任务执行两次,请问这个是只能启动一个吗,这样的话会不会任务多了遇到性能问题,有什么方案吗

要回复问题请先登录注册