给demo hallserver大厅服加上队列
前言
因为skynet中单进程写业务也容易遇到异步重入问题,写简单个人系统也得警惕此问题,着实让人难受。索性直接用queue
包裹一些执行入口,这样简单个人系统没有跨服的业务根本无需考虑此问题了。
实现方案
大厅服的业务函数处理通常以player_id
为第一参数用来处理玩家个人系统的数据。我们以player_id
来区分不同的队列,这样既可以有效利用skynet
多携程优势,又能避免个人系统的重入问题。
而对于需要处理多个玩家数据的函数,如果想简单的避免重入问题,我们需要等所有玩家queue处理完后,再执行,并且阻塞住后续的玩家queue请求。之前实现mult_queue
刚好符合这样的需求。
mult_queue
包裹入口处理函数
大厅服常用的处理入口有玩家消息,luaCMD消息,GM消息,登录,重连,掉线,登出动作,定时器,skynet.fock,hotfix热更。
不常用的处理入口有订阅,订阅同步,整点报时。
基于这些需求封装了queue_helper
,然后在对应入口函数处,使用对应queue方法包裹住对应处理函数即可确保避免异步重入问题。
1 |
|
玩家消息处理
修改 common/plug/hall_plug.lua
,在注册消息处理时做相应包裹。
1 |
|
luaCMD消息
跟玩家消息差不多,只是得规范第一参数是player_id,如果不是就会用unique
。
1 |
|
GM消息
1 |
|
登录,重连,掉线,登出动作
都是player_id相关的,包裹即可。
1 |
|
定时器
定时器使用queue_helper
中包裹的。
skynet.fock
fock也使用queue_helper
包裹的。
hotfix热更
重写了hotfix动作,加了queue包裹。
其他未处理的入口
比如time_point
回调,watch
,watch_syn
等等回调,需要使用者在恰当的时机用queue_helper
包裹相关处理函数。
使用注意点
慎用unique
因为执行完前会阻塞所有mult
包裹的处理。
注意避免环队列问题
队列中的处理函数调用call
最终调用到进入相同队列的处理函数,就会形成环队列。
如何避免,检查call
调用链会不会回归。
给demo hallserver大厅服加上队列
https://huahua132.github.io/2025/05/24/skynet_fly_ss/demo_hall_queue/