.. SPDX-License-Identifier: GFDL-1.3-or-later 关于Fk在同一个Lua中运行多个游戏房间的思考 ========================================= 目前Fk的实现中，每个游戏房间是一根线程，这就出现了一个问题： 当同时游戏的房间很多的时候，会给RAM带来相当大的负担，毕竟lua_State太多了， 每个Room都有一个。 目前比较流行的模式是只需三人就可进行的斗地主， 有时候同时运行着30多桌斗地主，直接把内存推向1GB占用，云服务器那才多少点资源。 如果这么多房间都在同一个Lua运行的话，情况应该会有很大改观。 多个房间如何调度？ ------------------ 在当前阶段已经实现了重连和观战机制，这是借助于协程机制实现的。 当Lua正在执行delay或者等待用户答复时，Lua会从主协程中切换出来， 然后去另一个协程处理诸如旁观、重连等游戏逻辑之外的请求。 如果把这种空白时间更加充分的利用起来的话，或许就能同时执行多个房间了。 现在每个游戏房间在Lua中都是一个Room对象的实例，而Room 本身是通过一个协程执行着主游戏逻辑。 考虑修改一下，使得同一个Lua中能执行多个Room协程。 暂且考虑开个数组保存所有正在运行中的房间。 就绪队列 -------- 调度器除了维护运行中房间的数组之外，还维护一个就绪队列。 当房间不处于阻塞状态时，或者已经可以脱离阻塞状态，那么就认为他就绪。 此外还有一个特殊的协程，他用来处理托管、旁观等请求。 当他的这个请求队列为空的时候，也视为他未就绪。 .. note:: 所谓阻塞状态目前指的是正在delay或者正在等候答复时。自然而然的， 脱离阻塞状态就是delay的时间已经结束或者已收到答复。 当所有房间全部未就绪时，调度器调用sleep睡一段时间，让出CPU。 当房间因为delay而延时时，可以知道他恢复就绪的确切等待时间。但如果是等待答复、 等待新请求这种依赖玩家操作的协程，其就绪时间就完全不可预测了。 正是这种不可预测的等待时间才使得我们调度器只能小睡个几毫秒。 如何多睡一段时间？ ------------------ 假设有多个房处于delay中，那么能睡的最长时间就是其中所有delay剩余时间的最小值。 但问题在于那些不可预测的就绪时间。如果另一个线程能告诉Lua答复已经就绪的话， 那么睡眠问题就好解决的多了。 实际上，可以借助信号量机制。当调度器开始睡觉时，肯定是调用了cpp函数。 这个cpp函数里面先将一个信号量置为0，然后再tryAcquire这个信号量一段时间。 当收到答复/收到请求时，把这个信号量+1。这样调度器就知道自己该醒过来啦。 如何避免房间等待太久？ ---------------------- 目前的调度思路如下： - 若就绪队列为空，那么从所有运行中的房间进行一遍筛选。 - 若还为空，再筛选。 - 假如第二遍还空，那就睡觉。 - 假如就绪队列不空，那么弹出第一个，然后把控制权交给这个协程，等他自己让出。 在这个过程中，由于有些房间在等待就绪队列变空的过程中满足了就绪的条件， 那么再次筛选时，有可能重复的房间又会再次位于就绪队列靠前的位置。 这虽然不会导致某个房间永久等待下去的情况，但却可能让一个房间等待太长时间， 那我就又要被艾特了。 一种或许可行的解法是，在再次刷新队列的时候，优先选出上次队列里面没有的房间。 不知道这样如何呢？ 怎么把现有的改成这样？ ---------------------- CPP代码方面，首先Room已经不再是一个线程了，自然不能再当QThread的子类。 另外开个什么类来占据线程吧。 既然不是QThread的子类的话，那Room::run就得改了。原本是启动线程，现在还是改成 pushRequest吧。新请求立刻唤醒调度器，然后调度器切到请求处理协程处理新房间请求， 然后就开战！ 既然要pushRequest，那么原先的请求队列也要从Room中移走了，这个得直接归属于线程。 当然，lua_State也要从Room撤走。 Lua代码方面，首先由于Engine成了所有房间共用的变量，必须杜绝所有对Engine 内变量的修改。点名cost_data和card.mark，这两个东西得通过__index大法托管给 Room挂着。剩下的没啥好说的，当然还有实现调度器。 协程池 ------ 虽然题文无关，但是FK确实在运行过程中不断的产生着协程。 为了避免因为不断产生新的协程导致的开销，可以使用协程池来管理。 用完的协程就存在某个数组留待下次使用。当需要启动一个新协程的时候， 先从协程池找，没有的话就新建一个。