记一次 skynet 中使用 skynet.queue 给消息加锁时的问题

in 编程
关注公众号【好便宜】( ID:haopianyi222 ),领红包啦~
阿里云,国内最大的云服务商,注册就送数千元优惠券:https://t.cn/AiQe5A0g
腾讯云,良心云,价格优惠: https://t.cn/AieHwwKl
搬瓦工,CN2 GIA 优质线路,搭梯子、海外建站推荐: https://t.cn/AieHwfX9

应该大多数 skynet 项目都是以 Lua 作为主开发语言。在使用 Lua 编写 skynet 服务时,基本的执行单元是 coroutine 。当有消息到达使用 Lua 编写的服务时,skynet 都会起一个 coroutine 来处理消息,当某个 coroutine 涉及到异步让出执行时,skynet 便继续执行下一条消息,等到该 coroutine 的唤醒消息到达时便会继续执行。

比如客户端先发送 a 消息,再发送 b 消息,而 a 中有异步操作,b 中无异步操作,则 b 会先比 a 处理完返回到客户端。若 a 中需要扣除金币,在异步前检查了金币满足,在异步返回后还需要再次检查金币数量,因为这个时候金币可能被修改而不满足条件了。在游戏开发中,有时我们想保持处理客户端发送消息的顺序性。比如某玩法,客户端依次发送消息 a 和 b ,而我们确实想 b 一定要在 a 之后返回,这个时候就需要用到 skynet.queue 。具体的代码在 skynet 中 lualib/skynet/queue.lua 文件中。skynet.queue 函数执行后会返回一个 closure 而这个 closure 的参数是函数以及这个函数的参数。若对这个 closure 传入参数 f1 f2 f3 f4 等函数及参数,那么这 4 个函数将会按照顺序依次执行,假设顺序是 f1 -> f2 -> f3 -> f4 ,若其中有函数比如 f2 中间会让出,则会一直等待该函数执行完毕,才会执行 f3 。

local current_thread
local ref = 0
local thread_queue = {}

skynet.queue 中有 3 个变量,current_threadref 用于标识当前 coroutine 执行的函数,而 ref 用于进一步处理当前 coroutine 中的嵌套锁。如下。其实就相当于若发现当前执行是同一个 coroutine 则直接执行即可并且 ref 技术加 1 ,最后在 ref 为 0 时检查队列中是否有需要唤醒的 coroutine 。若发现 current_thread 不为 nil 值,而且和 coroutine.running() 返回值不一样,则表明先前的函数有异步操作,并且异步操作还没有返回,此时则把 coroutine 放到 thread_queue 中,然后 skynet.wait 使 coroutine 让出执行,等待前一个操作完成。

local lock = skynet.queue()
lock(function()
    print("get the lock")
    lock(function()
        print("get the lock again")
    end)
end)

其实 skynet.queue 返回的 closure 其实就是对要执行的函数加一层包裹( wrapper )。在 wrapper 函数中(返回的 closure )判断传入的函数 f 是否可以直接执行,还是需要把 coroutine 放到 thread_queue 中等待执行。只要我们持有这个 coroutine 我们就可以恢复它,继续执行,真的是很便捷的功能。下面我想模拟一下 skynet.queue 的实现,来实际感受一下。完整的代码放到这儿,直接使用 lua 就可以执行。下面列出一些代码片段来分析。

local commands = {}
commands.lock = queue()

function commands.f1()
    local lock = commands.lock
    lock(function()
        print("[f1] unlock first in f1")
        lock(function()
            print("[f1] unlock second in f1, then wait call return")
            call()
        end)
    end)
    print("[f1] f1 return now")
end

function commands.f2()
    local lock = commands.lock
    lock(function()
        print("[f2] unlock in f2")
    end)
    print("[f2] f2 return now, returned after f1")
end

function commands.f3()
    print("[f3] f3 return now, the first returned cmd")
end

local function dispatch(commands)
    local session = 0
    return function(cmd)
        session = session + 1
        local f = assert(commands[cmd])
        local co = cocreate(f)
        local ok, op = coresume(co)
        assert(ok)
        if op == "CALL" then
            session_to_co[session] = co
        end
        return session
    end
end

local run = dispatch(commands)
local f1_session = run("f1")
run("f2")
run("f3")
call_ret(f1_session)

模拟的情景是处理客户端依次发送 f1 f2 f3 消息。服务器会给 f1 和 f2 消息处理函数加锁,而处理 f1 时涉及到异步操作(调用了 call() 函数调用),加锁可以确保 f2 在 f1 之后执行完毕返回。而 f3 消息处理函数则会直接执行,不受锁的影响。代码 run("f1") run("f2") run("f3") 就是服务依次处理发来的消息,由于 f1 涉及到异步,call_ret 用于恢复 f1 的执行。所以,客户端发送消息的顺序是 f1 f2 f3 但是消息处理完返回的顺序是 f3 f1 f2 。下面是执行结果。验证了我们的分析。

D:\workplace>lua test.lua
[f1] unlock first in f1
[f1] unlock second in f1, then wait call return
[f3] f3 return now, the first returned cmd
[f1] f1 return now
[f2] unlock in f2
[f2] f2 return now, returned after f1

现在应该对 skynet.queue 完全理解了,来回到我在项目中碰见的问题。这个问题是这样的,我们项目中一个 agent 服务承载着多个玩家,会为每个玩家调用 skynet.queue 分配锁,然后为锁住每个玩家的客户端发来的消息,用于串行化消息的执行(目的是为了减少开发中过多的异步考虑,减少心智负担)。而其他服务给玩家发送消息时,也会用统一把锁来锁住消息处理函数。客户端发送 req_leave 消息时,服务器回以 res_leave 消息,这中间有异步,所以 agent 上该玩家一直等待 req_leave 消息处理完,当消息处理慢一些时,此时其他服务主动给客户端推送的 notify_update 消息,在经过 agent 上此玩家时,也会被之前的锁给锁住,从而要等待 req_leave 消息执行完,导致 notify_update 消息在 res_leave 消息后返回。而我们的玩法假定 res_leave 后不会再有消息发送到客户端,所以就出现了问题。
之前花了大半天来查到底为什么 notify_update 消息在 res_leave 消息后返回,没有什么头绪,后面被同事查到了,我觉得还是挺有必要写篇博客记录一下的,来进一步了解 skynet 中的异步流。同事就是把客户端发送的消息和服务器发回的消息 grep 出来后,看了大概的消息流,发现该玩家总是会卡在处理 req_leave 这段消息期间(为了方便调试,我们调用了 skynet.sleep 延长了消息的执行),之后就会恢复正常。所以定位到是锁的问题。因此最终的解决方案是 notify_update 这种仅仅通过 agent 服务发回到客户端的消息,不需要加锁,直接执行即可。
通过这次问题,我发现我这次 grep 时忽略了消息的前后执行上下文,只关注了单个消息的日志细节,所以没有注意到卡消息流的日志输出,以后还是得注意一下。

关注公众号【好便宜】( ID:haopianyi222 ),领红包啦~
阿里云,国内最大的云服务商,注册就送数千元优惠券:https://t.cn/AiQe5A0g
腾讯云,良心云,价格优惠: https://t.cn/AieHwwKl
搬瓦工,CN2 GIA 优质线路,搭梯子、海外建站推荐: https://t.cn/AieHwfX9
扫一扫关注公众号添加购物返利助手,领红包
Comments are closed.

推荐使用阿里云服务器

超多优惠券

服务器最低一折,一年不到100!

朕已阅去看看