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

dingdejing

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

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

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

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

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

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

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

3142 3 0
3个回答

dingdejing

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

  • 暂无评论
dingdejing

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

  • 暂无评论
walkor

-

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

感觉这种方式更好一些。

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

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

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

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

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

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

  • dingdejing 2021-02-08

    恩恩,crontab确实可以只作为一个定时任务分发,具体执行任务重的话可以走队列;
    另外我的第一种、第二种不是说那种更好,是两种使用情况,就和上面的crontab一样,有些业务操作很复杂,可能利用会立刻受到webman的response(http 一问一答么),然后具体的任务交给队列处理,队列再通过gatewayclient 发消息给用户,一种就是任务简单了直接发了,我描述的1、2其实说的是我这样使用 gateway的网关那套框架 只用于给用户发推送,具体业务不写在gateway里,全都都通过webman调用gatewayclient推合适不合适,这样用不算是瞎折腾吧,因为想着还是http写业务简单点(当然其实之前单纯用gateway已经写过两个业务了很稳定);所以说了一下1、2两种使用情况,确认下可行不

  • dingdejing 2021-02-08

    虽然webman能自定义进行,直接做长连接服务,但是不是 reload会都导致重连么,而且之前用gateway感觉网关层挺稳定的,而且gatewayclient这个客户端拿来通过http推消息还挺方便的,所以才有此一问,

  • walkor 2021-02-08

    1 2方案可行。

  • dingdejing 2021-02-09

    @1:好滴谢啦

年代过于久远,无法发表回答
🔝