游戏网络通信的百万流程则是服务端先开启监听，等待客户端的连接，然后交互操作，最后断开。

套接字

每个Socket都包含网络连接中一端的线大型游戏服信息。每个客户端需要一个Socket结构，服务端则需要N+1个Socket结构，其中N为客户端的前两连接数，另外一个是服务端打开监听的套接字。

单线程事件模型(Reactor模型)

单线”指的章概是单线程，“事件”指的是事件触发，即当新连接 、断开连接、念笔收到数据这些事件到来时会触发某段代码。百万

一致性问题是线大型游戏服分布式系统的一大难题

可能会出现很多异常情况：重复执行等，需要保持一致性；

操作系统

单个程序中可能会存在一些阻塞语句让CPU空闲，开启多个程序可以填补CPU的空闲时间。比如：

如果程序中不包含阻塞语句，且运行在单核CPU下，同台物理机下部署多个程序是前两不能提升性能的。不过当代大多是章概多核CPU，可以同时执行多个程序，因此在非阻塞程序中，开启与CPU核心数相当的进程可以充分利用CPU 。

阻塞为什么不占用CPU

常见的念笔一些阻塞函数:等待客户端连接的函数，接收数据的函数等。那阻塞为什么不会占用CPU资源呢：
操作系统会分时执行各个运行状态的百万进程，由于速度很快，看上去就像是在同时执行多个任务 。
阻塞了会到等待队列，等到条件成立（比如等待一段时间）操作系统会重新将进程A放入工作队列中，继续执行。线大型游戏服

切换线程

CPU切换线程需要做很多工作，它执行一条语句大概需要几纳秒，完成一次线程切换大概需要几微秒，花销较大 。前两开启的章概线程数越多，CPU就需要做更多的切换工作，这会使响应变慢 。

网络模块的念笔底层实现有两种方式：

1）每当有新的客户端连接时，开启新线程处理该客户端。
2）使用多路复用技术，所谓“多路”，指的是服务端可以阻塞（如使用epoll_wait）等待多个客户端的连接，有任何一个收到数据即返回。
Web服务器可以用这两种方法，但游戏服务端大多只会用第2种方法 。这是因为Web服务器都是短连接，发送消息后即断开，同时在线的客户端很少；游戏服务端大多是长连接，同时在线的玩家很多，方法1只能支持数百名玩家。

难以分割的业务

实现分布式程序的前提是游戏逻辑能够分割
 。如果游戏规则复杂，各个功能紧密相连，则不容易找到分割的方案。

actor

合理分割功能是分布式模型的一大难点，我们需要寻找一种模式，它既能符合游戏逻辑的表达，又能让计算机高效执行。传统的多进程方式很多场景不能满足游戏逻辑的表达；

每个Actor都会包含自身状态（HP 、Coin），以及一个信箱（消息队列），Actor通过给其他Actor“寄信”来实现通信。至于收到信件后的反应，取决于收信的Actor。

由于各个Actor相互独立，计算机很容易让它们并行工作 。

对游戏服务端而言，Actor并发模型给游戏业务的分割提供了灵活性。

Skynet的强项在于单个节点内的并行运算

启动流程

skynet.socket模块

socket.read中所谓的阻塞模式和skynet.call一样，都利用了Lua的协程机制 。调用socket.read，服务有可能被挂起，直到接收到数据，才会往下执行。

skynet协程

Skynet服务在收到消息时，会创建一个协程，在协程中会运行消息处理方法（即用skynet.dispatch设置的回调方法）。这意味着，如果在消息处理方法中调用阻塞API（如skynet.call skynet.sleep 、socket.read），服务不会被卡住（仅仅是处理消息的协程被卡住），执行效率得以提高，但程序的执行时序将得不到保证
。