skynet服务的设计

统观整篇文章，不难发现：

每个 skynet 服务都是一个 lua state，也就是一个 lua 虚拟机实例。而且，每个服务都是隔离的，各自使用自己独立的内存空间，服务之间通过发消息来完成数据交换。

架构图如下：

lua state 本身没有多线程支持的，为了实现 cpu 的摊分，skynet 实现上在一个线程运行多个lua state 实例。而同一时间下，调度线程只运行一个服务实例。为了提高系统的并发性，skynet会启动一定数量的调度线程。同时，为了提高服务的并发性，就利用 lua 协程并发处理。

所以，skynet 的并发性有3点：

1、多个调度线程并发
2、lua协程并发处理
3、服务调度的切换

skynet 服务的设计基于 Actor 模型。有两个特点：

1. 每个 Actor 依次处理收到的消息
2. 不同的 Actor 可同时处理各自的消息

实现上，cpu 会按照一定规则分摊给每个 Actor，每个 Actor 不会独占 cpu，在处理一定数量消息后主动让出 cpu，给其他进程处理消息。

skynet服务的缺陷

并发问题

这要从 skynet 一个服务霸占调度器的极端例子说起。

下面给出两个 lua 代码 main.lua 和 simpledb.lua，和一个配置文件 config 

配置文件 config

注意了，这里特地把 thread 设置为1，表示只启动一个调度线程。

现在，启动skynet执行我们的例子，结果如下： 

可以看出，simpledb 没有机会处理TEST消息，一直是main模块占据着cpu。

为什么会出现这个情况？ 

这和skynet的调度机制有关。skynet使用全局队列保存了要调度的服务，调度算法是先来先服务。如果某个服务有新消息，就把这个服务加到调度队列中，然后等待调度线程调度。而skynet服务的调度切换依赖于协程的挂起，如果当前调度的服务没有主动挂起或退出，就会一直执行，不调度其他服务了。

这种机制的好处就是实现简单，有利于长作业，上下文切换较少，缺点就是并发效率低，而且像这种长作业的服务超过调度线程数量，就可能导致其他服务饿死。 

内存隐患

细心的同学会发现，在服务处理新消息时，是通过创建新协程来处理的（见co_create），虽然协程会被重复利用，但在当前版本下，这种不断创建协程来消息的方式本身存在不稳定因素：

1、协程只增加不减少，意味过了某个并发高峰后内存不会降下来。
2、创建协程也有一定开销，容易触发GC，也占用内存，协程的数量规模不容易控制
3、如果解决第1点，最槽糕的情况是，不断要创建协程，不断要销毁协程，频繁触发GC

这里有一个极端的例子：

如果服务a不断给服务b发消息，但服务b的处理过程存在长时间挂起，这样，对于服务a发来的消息，服务b会不断创建协程去处理，就导致内存被大量占用的情况出现。

但是skynet也提供办法解决这个问题，方法是主动调用GC：

另外，有兴趣的同学，不妨看下实现代码：

而什么时候调用了 skynet.debug 呢？看这里

就是说，但给服务发送GC消息时，就会清空协程池，随后执行底层GC接口。这样，不再有内容引用到这个协程，所以，协程会在GC时被清理。

至于协程只是挂起没有结束，为什么会被清理？

因为从协程池移走后，那些协程就变成了不可达的协程了，没有方法能 coroutine.resume 激活他们了，所以就会被GC掉。

同步问题

同步也是skynet存在的问题，当一个服务call其他服务时，当前协程会挂起，但是这个服务还可以接受并处理其他消息。如果多个协程改到同一个数据，你不做同步处理就无法确定这个数据会是多少。

这样的例子特别常见，比如，服务正当处理玩家login请求，刚好遇到call挂起，这时候又有新的请求到来，比如logout，服务就会转去处理logout消息。那玩家究竟是login，还是logout？

当然，同步问题也容易解决，加多一个state的标识和一个协程列表，操作执行时，将state置doing，其他协程判断state=doing时就将自己加到协程列表，然后 skynet.wait。在操作执行完后，重置state，然后遍历协程列表依次 skynet.wakeup(co) ，最后将协程列表置空。

linuxC/C++服务器 skynet 网络模块封装 | reactor 网络模型、同步非阻塞

百万游戏案例演示游戏服务器开发 框架——skynet | 服务端开发 | actor模型