Skynet基础教程03.优雅的Call,烧脑的挂起

本篇主要内容

• 讲解使用Skynet中逻辑挂起，恢复，以及坑点

建议提前掌握的知识

• Lua协程

什么是挂起

简单的来说，就是代码的逻辑可以暂停，直到被唤醒，然后接着暂停时逻辑继续执行。

Call的设计

在上一章我们讲到service之间的消息发送方式有两种，分别是call和send。

send的设计没什么选择，基本就是发目标一个消息，然后不关心返回值，继续做自己的逻辑。

call的设计就有两种了:

1. 基于send来做，调用接口时指定一个函数，等结果返回的时候，执行这个函数，比如nodejs中就是这么干的。
2. 基于挂起来做，调用后暂停当前的逻辑，等有返回值，继续执行接下来的逻辑。

从个人的角度，特别是在被nodejs中callback机制恶心过后(感兴趣的话可以搜索一下callback hell)，我坚定地认为第二种方式令人更舒服，这也是Skynet中call的方式。

Lua协程中的挂起与唤醒

下面这段代码演示下lua协程的挂起和唤醒的过程

local share_value = 0

-- 创建多个协程，每次被唤醒时打印下自己的编号，然后挂起
local co_num = 2
local co_list = {}
for id=1, co_num do
    local func = function()
        while true do
            share_value = share_value + 1
            print(string.format("coroutine %s, share:%s", id, share_value))
            coroutine.yield()
        end
    end
    table.insert(co_list, coroutine.create(func))
end

-- 主线每隔一段时间，就唤醒所有的协程
local max_loop = 3
for idx=1, max_loop do
    print(string.format("main thread, loop:%s", idx))
    for _idx, co in ipairs(co_list) do
        share_value = share_value + 1
        print(string.format("main thread, share:%s", share_value))
        coroutine.resume(co)
    end
end

print("main thread, end")

运行结果：

main thread, loop:1
main thread, share:1
coroutine 1, share:2
main thread, share:3
coroutine 2, share:4
main thread, loop:2
main thread, share:5
coroutine 1, share:6
main thread, share:7
coroutine 2, share:8
main thread, loop:3
main thread, share:9
coroutine 1, share:10
main thread, share:11
coroutine 2, share:12
main thread, end

上面的例子中，轮到协程运行时，它做完自己的时候后会挂起自己。轮到主线程的时候，它会挨个唤醒其他协程。

在轮到自己运行时，还会去给变量share_value加1，从运行结果可以看出，
share_value是共享的，但又不像多线程需要用锁保护一下共享资源，在同一个lua虚拟机中，同时最多只会有一个协程在运行。如果细想一下，马上意识到协程虽然相对多线程方便很多，但是还有坑的。(如果暂时没想到，可以先思考下再看后面的内容)

坑就在脚下

Skynet中，service的每一个消息处理过程，都是在一个协程中进行。在处理的过程中，当发生call其他service的操作时，对应的协程会挂起，直到接收方处理完以后返回。如果接收方的逻辑traceback了，发送方对应协程也会traceback。但如果接收方再也不返回了，比如没有写Skynet.retpack()，或者陷入了死循环, 那么发送者对应协程会一直挂起(目前的版本标准的call没有超时机制，如果实在想做这样的逻辑，也有其他办法)。除了call还有一些操作导致挂起，比如sleep，wait等。

下面，我们举几个例子说明下挂起可能引发的问题：

第一个例子

假设有一个购买东西的需求，这个东西需要远程的service处理，并且需要消耗一些金钱，下面是个有问题的写法

-- 伪代码
function buy(good_id)
    -- 第1步
    根据商品ID获取商品价格
    
    -- 第2步
    if 玩家没有足够的金钱 then
        return 金钱不足
    end

    -- 第3步
    向远程的服务请求购买

    -- 第4步
    if 购买失败 then
        return 金钱不足
    end
    
    -- 第5步
    扣除玩家的金钱
    给玩家奖励
    return 购买成功
end

第3步中，由于购买操作是一个远程服务Call操作，会引起挂起，有返回值时(被唤醒)，上下文可能变化。这意味着第5步中，扣除玩家金钱操控是不受第2步保护的。

也许有人会说金钱是可能会用在很多接口里面，如果是一个玩法专属的资源，并且只有一个接口可以操作它，比如票数之类的是不是就不会有问题呢？还是不行，因为虽然只有一个接口，只要但同一时间发很多相同的请求(比如利用网络延迟)，还是可以刷物品。

第二个例子

有些service是针对一种业务，但是很多个玩家的，比如邮件系统。接口基本都是一个玩家角色uuid为key，但由于一个服的玩家很多，不可能在开服的时候，直接把所有玩家的信息都从数据库都加载进内存，也不想全部依赖数据库，因为做复杂逻辑时很不方便。于是打算做个DB缓存，用到的时候拿出来，然后根据一定策略放回去(比如最近访问时间等的)。由于访问数据库是一个call操作，所以加载时会遇到类似的问题

-- 伪代码
function CacheMgr:load_player(uuid)
    -- 第1步, 如果缓存中有，立即返回
    local obj = self.cache[uuid]
    if obj then
        return obj
    end
    
    -- 第2步，从数据库中查玩家数据, 
    local data = self.db:load_player(uuid)
    
    -- 第3步，根据db的数据初始化对象
    obj = self.create_obj(data)

    -- 第4步，设置cache
    self.cache[uuid] = obj

    -- 第5步，返回cache对象
    return obj
end

由于第2步中的Call操作会引起挂起，意味被唤醒后，第1步的结论，即缓存中没有这个玩家的结论已经不靠谱了。如果第4步，直接设置，可能会导致cache中已经有对象被新对象覆盖，导致数据丢失。

其实无论挂起的方式还是回调函数的方式，都会遇到上下文变化的问题，这是高效率的并发机制下必然会遇到的问题，否则只能改为一个一个顺序处理消息了。服务端开发天然地存在不同线程的并行问题，然后又带了同一个线程下的并发问题，挂起的概念虽然很简单很好理解，但却是最容易导致bug的地方，当然也是最烧脑最有趣的地方。

编程挑战(欢迎你留言和我讨论)

• 上面的两个例子，怎样写才合理
• skynet.wait和skynet.wakeup分别是触发当然协程挂起和唤醒指定协程的接口，用这两个方法写一个协程级别的锁(可用于多个协程的挂起逻辑保序)