Skynet 游戏服务器专题导航：从 Actor 模型到集群部署的 17 篇索引

Skynet 是云风（吴云洋）从 2012 年开始维护的轻量级游戏服务器框架：C 语言写核心，Lua 写业务，用 Actor 模型把并发拆成一个个互相发消息的服务。它国内生产验证充分，是很多 MMO、SLG 和休闲对战项目的默认底座。这个目录里的 17 篇按「先跑起来、再理解模型、然后联网、接数据、调性能、上生产」的顺序组织，读完能独立搭起一个可上线的 Skynet 服务端骨架。

和按发布时间堆列表不同，这里按能力阶段编排。每一篇都标注了它在学习曲线上的位置，方便你判断是现在读还是以后读。文章里的代码与配置以 Skynet 官方 master 分支为准，Lua 侧以 5.3 之后的写法为主。

专题速览

推荐阅读路径

• 完全没接触过 Skynet：按「安装与环境搭建」→「简介与核心概念」→「服务模型详解」→「消息传递机制」顺序读，先把 Actor 模型下「服务即单元、通信即消息」的世界观建立起来，再动手写代码。
• 准备写第一个联网服务：接着读「Lua API 参考手册」和「WebSocket 支持与实现」，然后直接看「如何实现一个简单的多人在线游戏服务器」，用最小可运行工程把 gate、socket 与业务服务串起来。
• 要做分布式部署：读「集群通信详解」，理解 cluster 模块如何跨节点发消息，再回看「玩家之间的通信和数据同步」，把单机思路扩展到多节点。
• 已经上线要保稳定性：优先读「性能调优实战」「热更新机制详解」「调试技巧与问题排查」和「最佳实践与生产部署」，这四篇基本覆盖了长期运营阶段的主要痛点。
• 想一次看完整工程：直接读「完整游戏服务器实战」，它把登录、匹配、实时战斗与聊天串成一个项目，读完可以再回头按需补细节。

入门与核心概念

先把框架跑起来，再理解它为什么这样设计。这一组的重点是 Actor 模型下的服务生命周期与消息语义，而不是语法细节。

网络通信与集群

从单机服务走向真实玩家连接，再到多节点协作。这一组解决「消息怎么进来、怎么发出去、怎么跨机器」。

数据集成 性能与热更新

进入生产后最常被追问的三件事：数据存哪、性能够不够、能不能不停机改。

调试 排障与生产实践

这一组偏工程经验：怎么定位问题、怎么组织代码、哪些坑已经有人踩过。

核心机制速查

这一段把散落在各篇文章里的关键机制抽出来，方便在设计和排障时快速对齐概念。深入用法请看上面对应的文章。

服务与调度

• 每个服务是一个独立的 Lua 沙箱，拥有自己的消息队列，由框架的工作线程调度执行。
• 服务之间不共享内存，所有交互都通过消息完成，因此不存在传统意义上的锁竞争。
• 服务的启动与退出都有明确回调，业务应在这些回调里完成资源申请与释放。

消息语义

• 消息发送默认不阻塞调用方，接收方按队列顺序处理，适合把耗时逻辑从热路径上挪开。
• 请求响应模式由框架提供的调用接口实现，注意设置合理的超时，避免调用方被慢服务拖住。
• 大量小消息会增加调度开销，必要时合并消息或改用更适合的批处理方式。

网络层

• 网关负责连接、协议解析与心跳，业务服务只处理已经解出的逻辑消息。
• WebSocket 与原生 TCP 可以并存，按客户端类型选择接入方式。
• 玩家会话与连接要分开管理，断线重连时靠会话标识恢复而不是靠连接本身。

集群与数据

• cluster 模块让节点之间可以像调用本地服务一样发起跨节点调用，前提是节点注册与地址配置正确。
• 数据库访问是异步的，回调里不要做重逻辑，也不要在回调里假设调用时的上下文仍然有效。
• Redis 常用于会话、排行与热点数据，MySQL 用于权威持久化，两者职责不要混。

热更新与运维

• 热更新适合修 bug、调数值与改配置，不适合改服务边界与消息协议。
• 每次热更新都要有明确的回滚方式，并记录改了哪些服务、影响哪些在线玩家。
• 上线前先把日志级别、指标采集与告警配置好，事故时才有证据可用。

学习与排查建议

最后补一段实践向的提醒，都是新手最容易卡住、老手最容易忘记的地方。

• 编译失败先看依赖版本与 Lua 版本是否匹配，多数环境问题出在这一步，而不是代码本身。
• 服务数量增长后要定期回看服务拆分是否仍然合理，过细的拆分会让一次请求穿过十几个服务。
• 消息堆积通常不是网络问题，而是某个服务在回调里做了同步阻塞操作，先查热点服务的处理耗时。
• 热更新之后一定要验证在线玩家的会话与房间状态，脚本换了但状态没迁移是最常见的隐性故障。
• 集群问题优先检查节点注册与地址配置，跨节点调用失败往往在配置层面就能定位。
• 数据库慢查询会通过异步回调层层放大，给数据库访问单独配指标，不要混在业务耗时里看。
• 压测要在真实行为模型下做，只压连接数或只压单接口都得不到可用结论。
• 日志要带会话标识与请求标识，否则一次玩家投诉会变成翻遍所有服务日志。
• 热更新的脚本要进版本库，线上出问题时要能确定当前跑的是哪一版。
• 新增服务时同步补上健康检查与告警，等出事再补通常已经太晚。
• 关键配置要有默认值与校验，缺字段直接拒绝启动，好过带着错误配置跑起来。

相关专题