简介基于 Skynet 框架的 MySQL 与 Redis 游戏服务器完整源码包面向游戏后端开发者与 Lua/Python 技术学习者适合用于研究轻量级高并发网络框架下的服务器架构、数据库访问层设计及缓存落地方式。包内共 22 个文件以 Lua 服务脚本和配置为主辅以 Python 客户端脚本、Shell 启动脚本、Proto/PB 协议定义、节点配置及项目说明文档整体仅 619KB结构精简便于快速定位核心模块。源码覆盖登录、网关、场景、代理、节点管理等服务划分并通过相应数据访问层对接 MySQL 持久化与 Redis 缓存可对照阅读理解 Skynet 的消息调度、服务通信和异步 IO 处理思路。此外还包含运行演示图与 README 说明降低上手门槛。已有132人学习适合希望借鉴生产级目录组织与数据库交互细节的进阶开发者。1. skynet游戏服务器源码mysql与redis不是附属品是整个运行时的心脏第一次拿到这套「基于skynet框架的mysql与redis游戏服务器源码」时我以为是玩票级别的教学包——框架在 GitHub 上开源mysql/redis 驱动是 skynet 自带模块作者只是把它们粘在一起。拆进去之后发现判断下早了这不是简单的 demo 缝合而是一套能落地的分布式服务端骨架数据库层、缓存层、服务节点的边界划分得很清楚确实能直接当做自己项目的基础来改。它的价值不在于「教你连数据库」而在于把游戏服务器里最常见的三件事——玩家数据落库、跨服共享数据、排行与热点缓存——全部用 skynet 的方式组织好了。适合已经写过 Lua 服务端逻辑、想从单机脚本往分布式服务端转的人。下面按我拆包的顺序从目录到进程模型再到 mysql/redis 的实际用法和踩坑记录一条条说。2. 拆包定位config、service 与进程模型数据库入口在哪拿到 zip 别急着双击看代码先扫一遍目录结构搞清楚「哪部分能改、哪部分别碰」。我拆这套包的第一步就是画目录树把框架本体和业务代码分开避免后续改的过程中误伤底层。2.1 目录速览先认这三个目录就能定位数据库入口路径 / 文件作用要不要动skynet/框架本体含 makefile 与 cservice 下编译好的 .so基本不动service/Lua 服务目录玩家服务、场景服务、DB 服务都在这主要改动区service/db/mysql 与 redis 驱动封装所在按需小改config.master主节点配置线程数、服务路径、监听端口部署时必改common/协议、常量、cjson 封装小幅调整proto/网络协议定义按项目改视线先落在 service/db/。这个目录下通常有 mysql.lua、redis.lua 或 dbmanager.lua 之类的封装文件它们是整个服务端读写后端的中枢。源码包的作者会把「连接参数」「查询封装」「回调槽位」集中放在这里而不是散落在各个业务文件里——这一点做得比较正规后面改连接池大小、加预处理逻辑都不用在业务代码里翻来翻去。skynet/ 目录则保持原样。它是云风的框架本体需要编译生成主程序。千万别只把 skynet 源码文件夹当成纯参考部署时这一步是绕不开的。2.2 进程与服务模型为什么逻辑拆分到服务数据库调用才吃得消skynet 的模型是 actor每个服务是一段独立代码运行在自己的消息循环里服务之间通过字符串地址发消息不共享内存。这份源码包沿用了这种组织方式典型划分是master 节点承载网关、登录、管理服务agent 服务每个玩家登录后拉起的代理玩家消息都进这里scene 服务场景、战斗这类实时性要求高的逻辑db 服务专门的数据库操作池业务服务通过消息向它发请求redis 服务缓存读写统一入口这个划分决定了数据库调用的写法。业务服务不能自己直连数据库写 SQL而是把请求发到 db 服务由 db 服务统一去连 mysql再把结果回包。这么拆的好处是连接数可控、SQL 逻辑收敛、事务边界清楚。坏处是你如果拿单机脚本的习惯去写——到处 connect、到处 query——很快连接池就爆了服务之间还会因为依赖关系相互卡死。初次跑通时先别急着改业务把服务启动顺序理一遍master 起来后加载全局配置再拉起 db、redis 服务玩家登录时才动态拉起 agent。启动顺序不对db 服务没起来业务服务一启动就报「connect mysql failed」这个现象非常典型。2.3 启动流程与配置参数一份能直接跑的 config.master源码包根目录会有 config.master也可能叫 config.master 加几个老节点配置。核心内容一般长这样root ./ thread 8 harbor 0 network 0.0.0.0:8888 luaservice root..service/?.lua;..root..service/?/init.lua cpath root..cservice/?.so logger logger logpath .代码块里每行的作用按部署时遇到的优先级说thread是 worker 线程数通常等于 CPU 核数。8 够大多数开发机跑真机压测再调。harbor 0表示当前是独立节点模式适合单机调试。如果它配成别的值说明还有 cluster 配置跨节点通信必须依赖它别乱改。luaservice决定了 Lua 服务的查找路径中间冒号分隔多个目录新增服务模块时如果找不到先检查路径写法对不对。cpath指向 cservice 下的 .so 文件。编译后这些 .so 会生成在这里路径错了服务起不来报错却很隐晦。network是网关监听地址客户端连接入口部署到云服务器要改成内网 IP 或 0.0.0.0。编译和首次启动我习惯用下面这套命令执行cd ./skynet make linux # macOS 下用 make macos cd .. rm -f *.log ./skynet config.mastermake linux是跳过不掉的。源码包里带的是框架源码直接执行根目录的 skynet 二进制会报错因为编译产物缺失。清理旧日志再启动可以避免把上一次跑挂的报错日志混到新日志里看错行。启动后立刻tail -f log/master.log看到节点地址、服务加载成功、监听端口的日志再进入下一步。3. mysql 接入实战连接池、事务处理与数据库常用命令mysql 在整个服务端里处于「最后一道防线」的位置。热数据在 redis冷数据和需要持久化的在 mysql。这份源码包的 mysql 模块基于 skynet 自带的skynet.db.mysql也就是 luasql 驱动那一层但作者大概率在外面包了一层做连接池管理和统一的异步回调。用之前把这一层的用法摸清楚比直接梭哈框架底层可靠得多。3.1 连接配置与驱动前置字符集、连接池与超时参数在 service/db/ 下的 mysql 封装文件里连接配置一般以表形式给出local dbconf { host 127.0.0.1, port 3306, database game, user game, password game123, max_pool_size 8, charset utf8mb4, timeout 3000, }连接参数里我想单独拎出来强调三个charset必须写utf8mb4不是utf8。玩家昵称里偶尔会出现 emoji 字符utf8会直接写入失败或乱码。这是很多人第一次连 mysql 碰到的隐性坑报错还不是立刻出现而是等写入特殊字符才翻车。timeout是连接超时毫秒数。游戏服务器对实时性敏感连接 3 秒没握上手还继续傻等会把整个 actor 的消息队列拖垮后面排队的查询全都延时。max_pool_size是连接池大小。默认给到 8开发阶段够用压测或上线前必须按并发量重新评估。下面避坑章里我会展开说连接池耗尽的问题。登录后拿到玩家的数据第一步通常是查玩家主表local skynet require skynet local db require service.db.mysql local function on_player_load(results, err) if err or not results or #results 0 then skynet.error(player load failed:, err) return end local row results[1] skynet.error(player loaded:, row.id, row.name, row.level) end function load_player(uid) local sql SELECT id, name, level, gold FROM tb_player WHERE uid %s db.query(sql, on_player_load, uid) end这段写法的逻辑db.query只是把 SQL 和回调函数发到服务端执行sql 里的%s是占位符由驱动拼参数。回调on_player_load在结果集返回时被唤起results是数组每行是一个表键名与 mysql 字段名一致。这里特别需要注意回调不是立即执行的而是等 mysql 真正返回后由 skynet 消息循环分发所以不能在回调外面直接拿 results 用。3.2 常用查询封装排序分页与索引别让 mysql 做无谓的 filesort游戏排行榜、邮件列表这类场景SQL 写起来简单但生产环境最容易崩的就是排序分页。源码包里的封装通常会接收一个limit参数local function get_rank_page(page, page_size, cb) local offset (page - 1) * page_size local sql SELECT uid, level, score FROM tb_rank ORDER BY score DESC LIMIT %d, %d db.query(sql, cb, offset, page_size) end这段逻辑看着直白其实索引约束很严格。ORDER BY score DESC要快必须给score建索引如果排序字段有多个比如先按score再按level就要建联合索引顺序写错mysql 还是走 filesort性能掉一个量级。常见的验证动作是拿某条高频 SQL 跑EXPLAIN SELECT uid, level, score FROM tb_rank ORDER BY score DESC LIMIT 0, 20;看Extra列如果出现了Using filesort就得回 mysql 补索引。这一点算是我在多个项目里反复踩的坑业务压测一上sql 还没写错但排序直接把数据库 CPU 打满。顺便说一句mysql 锁的分类也会影响排序和更新的并发性——行锁、表锁、意向锁在 InnoDB 下表现完全不同游戏排行榜这种高频更新场景尽量让更新语句走主键或唯一索引避免不必要的锁范围扩大。3.3 事务处理异步回调下事务必须自己控制边界很多新手拿到这份源码包以为执行几条 update 就算事务了。实际上 skynet.db.mysql 默认 autocommit 是开的每条 SQL 各自提交不带隐式事务。想要事务必须显式发START TRANSACTION和COMMITfunction take_reward(uid, reward_id) db.query(START TRANSACTION) db.query(UPDATE tb_items SET count count - 1 WHERE uid %s AND item_id %s, nil, uid, reward_id) db.query(INSERT INTO tb_user_reward (uid, reward_id, create_time) VALUES (%s, %s, NOW()), nil, uid, reward_id) db.query(COMMIT) end但这样的裸写法有很大问题。前面说过db.query是异步的START TRANSACTION发出去之后下一条UPDATE并不保证在同一个连接上执行。连接池会把请求分发到不同连接事务就名存实亡。所以更靠谱的做法是事务密集的操作单独走一个串联队列db 服务内部维护一个事务队列把事务内部的 SQL 一条条串起来全部执行完再 COMMIT期间这个连接被事务独占。源码包如果有dbmanager.transaction(fn)这类封装直接用没有的话一般做法是自己写一个事务锁local trans_queue {} function begin_transaction(uid, trans_fn) trans_queue[uid] trans_queue[uid] or {} table.insert(trans_queue[uid], trans_fn) if #trans_queue[uid] 1 then execute_next_trans(uid) end end这段逻辑的要点是同一个 uid 的多个事务排队前一个事务 COMMIT 完才算完再执行下一个。这样从业务层面保证同账号的事务串行避免后一个事务的 SQL 插进前一个事务中间执行。mysql 事务处理中常见现像是扣库存的 SQL 执行成功了但后面的插入 SQL 失败结果库存扣了记录没生成。排查时打开慢查询日志和SHOW ENGINE INNODB STATUS看最近事务的锁等待往往能直接看到是哪条 SQL 卡住了。SHOW PROCESSLIST也是一线排查利器能快速看到当前连接执行到的 SQL 状态是 sleep 还是 query 还是 locked。4. redis 接入实战数据类型、排行榜缓存与分布式锁游戏服务器里 redis 的角色我用一句话说清mysql 管「终态」redis 管「热态」。玩家在线期间的数据频繁读写全走 mysql 会把数据库压垮redis 承接这部分压力。这份源码包里的 redis 模块通常封装了单节点连接也预留了 cluster 模式的配置位实际操作时按自己环境选择。4.1 连接配置与序列化redis 数据类型到游戏场景的映射先看连接配置这与 mysql 的套路类似local redisconf { host 127.0.0.1, port 6379, password , db 0, }redis 数据类型在游戏里的映射我做了一张表实际开发时直接对着选redis 数据类型典型游戏场景String玩家基础数据、计数器、分布式锁Hash玩家属性、背包某类物品的字段级更新List邮件队列、世界公告、离线消息Set好友关系、每日在线集合、去重操作ZSet排行榜、匹配分值、跨服天梯代码里落地时最常用的操作是三件套setex设置带过期时间的 key、hset更新 hash 字段、zadd写入排行榜local skynet require skynet local redis require service.db.redis local cjson require cjson local rds redis.connect({ host 127.0.0.1, port 6379, db 0, }) -- 玩家数据整串缓存3600 秒过期 rds:setex(player: .. uid, 3600, cjson.encode(player_data)) -- 玩家等级、金币进 hash更新字段不需要整串回写 rds:hset(player:ext: .. uid, level, 20) rds:hset(player:ext: .. uid, gold, 9999) -- 排行榜score 必须为数值 rds:zadd(rank:level:server1, player.level, player: .. uid)这里有个很容易被忽略的坑redis 里的 Lua table 不能直接存必须先经过序列化。我见过有人在 redis 里存了原生的 lua table读出来之后是个 userdata打印全是问号这就是序列化没做对。规范做法是写入时用cjson.encode读取时用cjson.decode必须成对local data cjson.decode(rds:get(player: .. uid))这个序列化习惯直接影响缓存层的稳定。redis 连接工具也多连不上时别急着怀疑框架先拿桌面客户端或命令行redis-cli ping探一下网络和密码是否正常再回服务端排查。4.2 缓存与排行榜缓存穿透与回源设计这份源码包大概率在玩家登录时「先读 redis、miss 再回 mysql」。这个流程本身不难难点在防穿透。直接看伪代码function get_player_data(uid, cb) local key player: .. uid local cached rds:get(key) if cached then cb(cjson.decode(cached)) return end load_from_mysql(uid, function(data) rds:setex(key, 3600, cjson.encode(data)) cb(data) end) end逻辑说得通缓存命中直接返回miss 时回源 mysql 并回填缓存。但实际压测时会发现热点玩家数据缓存刚过期几十个请求同时来查询全部 miss 全部回源 mysqlmysql 被打穿。常见做法是给回源动作加锁只允许一个请求去 mysql 加载其他请求等结果返回再从缓存拿local loading_flags {} function get_player_data_locked(uid, cb) local key player: .. uid local cached rds:get(key) if cached then cb(cjson.decode(cached)) return end if loading_flags[uid] then -- 已经有请求在回源等完成后重试 skynet.timeout(50, function() get_player_data_locked(uid, cb) end) return end loading_flags[uid] true load_from_mysql(uid, function(data) rds:setex(key, 3600, cjson.encode(data)) loading_flags[uid] false cb(data) end) endloading_flags在 skynet 单服务内部是安全的因为 actor 模型下单个服务实例不会并发执行两段代码。这个「单飞」设计是游戏服务器里防缓存穿透的常规解法比单独引入分布式互斥锁要轻。4.3 Redis 分布式锁set nx ex 的 token 陷阱游戏里抢购、发奖、扣库存这类操作经常要保证同一时刻只有一个服节点执行。skynet 多节点部署下单服务内存锁失效就得靠 Redis 分布式锁。网上铺天盖地的解法是SET key value NX EX 10代码看起来也就三五行local token skynet.now() .. : .. skynet.self() local ok rds:set(lock:buy, token, NX, EX, 10) if ok then -- 拿锁成功执行扣库存、发奖等业务 rds:eval( if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end, 1, lock:buy, token ) else -- 拿锁失败直接返回错误 end写法和注释里藏了三个重要的细节血泪教训NX保证只有 key 不存在时才设置成功这是「互斥」的本质EX设置过期时间防止业务还没跑完服务先宕了锁永远不释放。释放锁时必须用 Lua 脚本比对token再删 key。如果直接del可能出现这种情况锁 10 秒超时业务实际跑了 15 秒锁已经过期被别的节点抢走了这时候你执行del删掉的是别人的锁。token 就是「锁是我的才删」的凭证。锁过期时间必须大于业务最大执行时长。我见过把EX设为 3 秒业务里查一次 mysql 排个队就超时了结果两个节点同时进临界区库存超卖。设置锁超时之前先给关键业务路径做一遍耗时估算留足余量。5. 避坑排查mysql、redis 与服务端启动的五个真实坑这套源码包跑通不难但在我拆过和用类似包的项目里有五个坑是反复出现在不同人屏幕上的。每个都按「现象、原因、解决」说清楚能帮你省下半天排查时间。5.1 编译错误cservice 目录缺失与 skynet 二进制不可用现象在源码包根目录执行./skynet config.master启动后立刻退出报错提示找不到某个.so或者直接提示skynet: cant load cservice/skynet.so。原因这个源码包带的是 skynet 框架源码不是编译好的二进制。首次拿到后不执行 make直接跑主程序cservice 下还没有生成对应模块的 .so 文件运行时就加载不到。解决先进 skynet 目录编译再回根目录启动顺序不能反过来。cd ./skynet make linuxmacOS 环境执行make macos。编译成功后ls cservice/能看到logger.so、skynet.so这类文件再启动就不会报这个错。编译期还容易遇到 gcc 版本过老报语法错误的情况先gcc --version确认版本Ubuntu 20.04 以后的环境基本没问题。5.2 mysql 连接为 nil驱动没装好与字符集配置错误现象服务能启动但日志里不断重复connect mysql failed或者调用查询时回调收到err内容是缺少某个 mysql 依赖库。原因skynet 的 mysql 驱动底层依赖系统里的libmysqlclient。云主机最小化安装或 Docker 容器里没有这个库驱动加载时直接失败。另外字符集配置传成utf8时连接字符集校验不过连接也会异常。解决先装系统依赖再检查字符集配置。apt-get install -y libmysqlclient-dev配置里统一使用charset utf8mb4。装完依赖后重启服务连接日志恢复正常。这里有一个玄学现象值得说mysql 驱动在报错时错误信息里往往不带「缺库」字样而是模棱两可地给一个连不上或超时容易把人往网络和防火墙方向带偏。排查顺序很重要先确认依赖再查网络。5.3 连接池耗尽max_pool_size 与请求尖峰不匹配现象压测一上量日志开始不断出现no more mysql connection所有查询延迟飙高服务响应明显变慢。原因连接池默认大小 8平时够用。压测时玩家登录集中在同一时间大量查询同时进来连接被占满后续请求排队等待超时后堆积更多请求形成雪崩。解决先拆慢查询再调大连接池。只调max_pool_size是治标不治本的因为慢 SQL 本身把连接占用时间拉长了。SHOW PROCESSLIST;看到多条query状态久未结束的 SQL先优化。常见的优化手段是给高频查询的字段建索引避免排序和回表。必要的时候调大max_pool_size到 16 或 24但连接数也不是越大越好mysql 服务器本身有最大连接数上限超了照样报错。生产环境更合理的设计是拆出多个 db 服务登录服务用独立的连接池业务查询用另一个池互不挤占。5.4 回调传函数无效匿名函数在消息序列化中丢失现象自己封装 db 调用时想图省事把回调直接作为参数传进跨服务消息里结果回调完全不执行或者报invalid address、callback not found之类的错。原因skynet 服务间通信传的是字符串、数字、table 这类可序列化数据Lua 函数没法在服务间传递。驱动层如果暴露的是底层消息接口匿名函数传过去就被丢弃了。解决给回调建槽位用数字 id 代替函数本身跨服务传递。一般源码包的 dbmanager 里会封装好这一层local cb_map {} local cb_seq 0 function db_query(sql, params, cb) cb_seq cb_seq 1 cb_map[cb_seq] cb inner_query(sql, params, cb_seq) end local function inner_query(sql, params, cb_id) local function on_result(results, err) local cb cb_map[cb_id] cb_map[cb_id] nil cb(results, err) end driver.query(sql, on_result, params) end逻辑说明cb_seq每次自增生成唯一 idcb_map保存回调引用跨服务只传 id。回调完成后再从表中移除避免槽位泄漏。新手最常见的翻车点是直接db_query(sql, function(...) end)然后跨服务调用看到代码没错就是调不通问题全在这个序列化边界上。写业务时统一走封装别在业务里自己造跨服务的函数参数。5.5 redis protected mode本机调试的拦路虎现象服务端连接本地 redis 启动正常但换到 WSL 调试或云服务器部署时连接报DENIED Redis is running in protected mode。原因redis 的protected mode默认开启只允许本机回环地址且无密码的连接。服务端进程跨网络访问、或者 bind 配置变更后redis 会拒绝这个连接。解决本机联调时直接关掉保护模式生产环境改为显式配置密码并绑定内网地址。redis-cli -p 6379 CONFIG SET protected-mode no持久化配置要写进 redis.conf 里protected-mode no否则重启后恢复默认。生产环境更推荐的做法是设置requirepass并且给 skynet 的 redis 连接配置加上对应password字段。Windows 本机调试时注意redis 若装在 Windows 子系统里通过127.0.0.1访问一般没问题跨主机访问大概率触发保护模式先查这个再怀疑服务端代码。还有人在 Windows 上用 Docker 跑 redisDocker 默认端口映射和 redis 配置冲突的情况很常见我一般直接装原生 redis 服务少一层容器网络问题调试效率更高。6. 对账验证缓存与 mysql 数据一致性的检查套路先把这套方法用在你自己项目上源码包跑通后别急着加业务先做一次「冷启动对账」。这个动作能同时验证 mysql 落库、redis 缓存、服务启动三条链路是否真的通也顺便把数据库选型是否合理的底摸清楚。对账的思路很简单以 mysql 为基准清洗 redis 业务缓存然后重新触发服务逻辑看 mysql 里的数据和 redis 里的缓存是否对应。先写一个清缓存脚本把player:*前缀的 key 全清掉redis-cli --scan --pattern player:* | xargs -I{} redis-cli del {}再重启 skynet模拟一次玩家登录流程让服务端走一遍 mysql 回源逻辑重新填充 redis。这时分别从两边统计数量mysql -h127.0.0.1 -ugame -pgame123 game \ -e SELECT COUNT(*) FROM tb_player; redis-cli dbsize比对两条记录数如果 redis 的 player key 数量与 mysql 的玩家记录数明显不匹配说明回源逻辑有漏写或过期策略有问题。再进一步验证单条数据是否一致可以抽一个 uid 分别取两边数据做结构化对比redis-cli get player:1001 mysql -h127.0.0.1 -ugame -pgame123 game \ -e SELECT * FROM tb_player WHERE uid 1001;字段值不一致重点排查序列化环节——写入时cjson.encode的字段和 mysql 字段名是否对齐数字是否被转成了科学计数法。最后压测时验证缓存穿透防护是否生效把回源单飞逻辑临时关掉看 mysql 的SHOW PROCESSLIST是否出现大量同一个 uid 的查询再打开单飞同一个 uid 的查询应该只剩一条。这个对比能直观确认「redis 缓存不再被击穿」不是靠直觉而是靠实测抓到证据。从那以后我每次拿到新的 skynet 服务端源码包都会强制把这套对账流程完整走一遍再开始改业务代码。数据库层的隐蔽问题如果能在这个阶段爆出来好过上线后被玩家流量打出来。希望帮到你。本文还有配套的精品资源点击获取
简介基于 Skynet 框架的 MySQL 与 Redis 游戏服务器完整源码包面向游戏后端开发者与 Lua/Python 技术学习者适合用于研究轻量级高并发网络框架下的服务器架构、数据库访问层设计及缓存落地方式。包内共 22 个文件以 Lua 服务脚本和配置为主辅以 Python 客户端脚本、Shell 启动脚本、Proto/PB 协议定义、节点配置及项目说明文档整体仅 619KB结构精简便于快速定位核心模块。源码覆盖登录、网关、场景、代理、节点管理等服务划分并通过相应数据访问层对接 MySQL 持久化与 Redis 缓存可对照阅读理解 Skynet 的消息调度、服务通信和异步 IO 处理思路。此外还包含运行演示图与 README 说明降低上手门槛。已有132人学习适合希望借鉴生产级目录组织与数据库交互细节的进阶开发者。1. skynet游戏服务器源码mysql与redis不是附属品是整个运行时的心脏第一次拿到这套「基于skynet框架的mysql与redis游戏服务器源码」时我以为是玩票级别的教学包——框架在 GitHub 上开源mysql/redis 驱动是 skynet 自带模块作者只是把它们粘在一起。拆进去之后发现判断下早了这不是简单的 demo 缝合而是一套能落地的分布式服务端骨架数据库层、缓存层、服务节点的边界划分得很清楚确实能直接当做自己项目的基础来改。它的价值不在于「教你连数据库」而在于把游戏服务器里最常见的三件事——玩家数据落库、跨服共享数据、排行与热点缓存——全部用 skynet 的方式组织好了。适合已经写过 Lua 服务端逻辑、想从单机脚本往分布式服务端转的人。下面按我拆包的顺序从目录到进程模型再到 mysql/redis 的实际用法和踩坑记录一条条说。2. 拆包定位config、service 与进程模型数据库入口在哪拿到 zip 别急着双击看代码先扫一遍目录结构搞清楚「哪部分能改、哪部分别碰」。我拆这套包的第一步就是画目录树把框架本体和业务代码分开避免后续改的过程中误伤底层。2.1 目录速览先认这三个目录就能定位数据库入口路径 / 文件作用要不要动skynet/框架本体含 makefile 与 cservice 下编译好的 .so基本不动service/Lua 服务目录玩家服务、场景服务、DB 服务都在这主要改动区service/db/mysql 与 redis 驱动封装所在按需小改config.master主节点配置线程数、服务路径、监听端口部署时必改common/协议、常量、cjson 封装小幅调整proto/网络协议定义按项目改视线先落在 service/db/。这个目录下通常有 mysql.lua、redis.lua 或 dbmanager.lua 之类的封装文件它们是整个服务端读写后端的中枢。源码包的作者会把「连接参数」「查询封装」「回调槽位」集中放在这里而不是散落在各个业务文件里——这一点做得比较正规后面改连接池大小、加预处理逻辑都不用在业务代码里翻来翻去。skynet/ 目录则保持原样。它是云风的框架本体需要编译生成主程序。千万别只把 skynet 源码文件夹当成纯参考部署时这一步是绕不开的。2.2 进程与服务模型为什么逻辑拆分到服务数据库调用才吃得消skynet 的模型是 actor每个服务是一段独立代码运行在自己的消息循环里服务之间通过字符串地址发消息不共享内存。这份源码包沿用了这种组织方式典型划分是master 节点承载网关、登录、管理服务agent 服务每个玩家登录后拉起的代理玩家消息都进这里scene 服务场景、战斗这类实时性要求高的逻辑db 服务专门的数据库操作池业务服务通过消息向它发请求redis 服务缓存读写统一入口这个划分决定了数据库调用的写法。业务服务不能自己直连数据库写 SQL而是把请求发到 db 服务由 db 服务统一去连 mysql再把结果回包。这么拆的好处是连接数可控、SQL 逻辑收敛、事务边界清楚。坏处是你如果拿单机脚本的习惯去写——到处 connect、到处 query——很快连接池就爆了服务之间还会因为依赖关系相互卡死。初次跑通时先别急着改业务把服务启动顺序理一遍master 起来后加载全局配置再拉起 db、redis 服务玩家登录时才动态拉起 agent。启动顺序不对db 服务没起来业务服务一启动就报「connect mysql failed」这个现象非常典型。2.3 启动流程与配置参数一份能直接跑的 config.master源码包根目录会有 config.master也可能叫 config.master 加几个老节点配置。核心内容一般长这样root ./ thread 8 harbor 0 network 0.0.0.0:8888 luaservice root..service/?.lua;..root..service/?/init.lua cpath root..cservice/?.so logger logger logpath .代码块里每行的作用按部署时遇到的优先级说thread是 worker 线程数通常等于 CPU 核数。8 够大多数开发机跑真机压测再调。harbor 0表示当前是独立节点模式适合单机调试。如果它配成别的值说明还有 cluster 配置跨节点通信必须依赖它别乱改。luaservice决定了 Lua 服务的查找路径中间冒号分隔多个目录新增服务模块时如果找不到先检查路径写法对不对。cpath指向 cservice 下的 .so 文件。编译后这些 .so 会生成在这里路径错了服务起不来报错却很隐晦。network是网关监听地址客户端连接入口部署到云服务器要改成内网 IP 或 0.0.0.0。编译和首次启动我习惯用下面这套命令执行cd ./skynet make linux # macOS 下用 make macos cd .. rm -f *.log ./skynet config.mastermake linux是跳过不掉的。源码包里带的是框架源码直接执行根目录的 skynet 二进制会报错因为编译产物缺失。清理旧日志再启动可以避免把上一次跑挂的报错日志混到新日志里看错行。启动后立刻tail -f log/master.log看到节点地址、服务加载成功、监听端口的日志再进入下一步。3. mysql 接入实战连接池、事务处理与数据库常用命令mysql 在整个服务端里处于「最后一道防线」的位置。热数据在 redis冷数据和需要持久化的在 mysql。这份源码包的 mysql 模块基于 skynet 自带的skynet.db.mysql也就是 luasql 驱动那一层但作者大概率在外面包了一层做连接池管理和统一的异步回调。用之前把这一层的用法摸清楚比直接梭哈框架底层可靠得多。3.1 连接配置与驱动前置字符集、连接池与超时参数在 service/db/ 下的 mysql 封装文件里连接配置一般以表形式给出local dbconf { host 127.0.0.1, port 3306, database game, user game, password game123, max_pool_size 8, charset utf8mb4, timeout 3000, }连接参数里我想单独拎出来强调三个charset必须写utf8mb4不是utf8。玩家昵称里偶尔会出现 emoji 字符utf8会直接写入失败或乱码。这是很多人第一次连 mysql 碰到的隐性坑报错还不是立刻出现而是等写入特殊字符才翻车。timeout是连接超时毫秒数。游戏服务器对实时性敏感连接 3 秒没握上手还继续傻等会把整个 actor 的消息队列拖垮后面排队的查询全都延时。max_pool_size是连接池大小。默认给到 8开发阶段够用压测或上线前必须按并发量重新评估。下面避坑章里我会展开说连接池耗尽的问题。登录后拿到玩家的数据第一步通常是查玩家主表local skynet require skynet local db require service.db.mysql local function on_player_load(results, err) if err or not results or #results 0 then skynet.error(player load failed:, err) return end local row results[1] skynet.error(player loaded:, row.id, row.name, row.level) end function load_player(uid) local sql SELECT id, name, level, gold FROM tb_player WHERE uid %s db.query(sql, on_player_load, uid) end这段写法的逻辑db.query只是把 SQL 和回调函数发到服务端执行sql 里的%s是占位符由驱动拼参数。回调on_player_load在结果集返回时被唤起results是数组每行是一个表键名与 mysql 字段名一致。这里特别需要注意回调不是立即执行的而是等 mysql 真正返回后由 skynet 消息循环分发所以不能在回调外面直接拿 results 用。3.2 常用查询封装排序分页与索引别让 mysql 做无谓的 filesort游戏排行榜、邮件列表这类场景SQL 写起来简单但生产环境最容易崩的就是排序分页。源码包里的封装通常会接收一个limit参数local function get_rank_page(page, page_size, cb) local offset (page - 1) * page_size local sql SELECT uid, level, score FROM tb_rank ORDER BY score DESC LIMIT %d, %d db.query(sql, cb, offset, page_size) end这段逻辑看着直白其实索引约束很严格。ORDER BY score DESC要快必须给score建索引如果排序字段有多个比如先按score再按level就要建联合索引顺序写错mysql 还是走 filesort性能掉一个量级。常见的验证动作是拿某条高频 SQL 跑EXPLAIN SELECT uid, level, score FROM tb_rank ORDER BY score DESC LIMIT 0, 20;看Extra列如果出现了Using filesort就得回 mysql 补索引。这一点算是我在多个项目里反复踩的坑业务压测一上sql 还没写错但排序直接把数据库 CPU 打满。顺便说一句mysql 锁的分类也会影响排序和更新的并发性——行锁、表锁、意向锁在 InnoDB 下表现完全不同游戏排行榜这种高频更新场景尽量让更新语句走主键或唯一索引避免不必要的锁范围扩大。3.3 事务处理异步回调下事务必须自己控制边界很多新手拿到这份源码包以为执行几条 update 就算事务了。实际上 skynet.db.mysql 默认 autocommit 是开的每条 SQL 各自提交不带隐式事务。想要事务必须显式发START TRANSACTION和COMMITfunction take_reward(uid, reward_id) db.query(START TRANSACTION) db.query(UPDATE tb_items SET count count - 1 WHERE uid %s AND item_id %s, nil, uid, reward_id) db.query(INSERT INTO tb_user_reward (uid, reward_id, create_time) VALUES (%s, %s, NOW()), nil, uid, reward_id) db.query(COMMIT) end但这样的裸写法有很大问题。前面说过db.query是异步的START TRANSACTION发出去之后下一条UPDATE并不保证在同一个连接上执行。连接池会把请求分发到不同连接事务就名存实亡。所以更靠谱的做法是事务密集的操作单独走一个串联队列db 服务内部维护一个事务队列把事务内部的 SQL 一条条串起来全部执行完再 COMMIT期间这个连接被事务独占。源码包如果有dbmanager.transaction(fn)这类封装直接用没有的话一般做法是自己写一个事务锁local trans_queue {} function begin_transaction(uid, trans_fn) trans_queue[uid] trans_queue[uid] or {} table.insert(trans_queue[uid], trans_fn) if #trans_queue[uid] 1 then execute_next_trans(uid) end end这段逻辑的要点是同一个 uid 的多个事务排队前一个事务 COMMIT 完才算完再执行下一个。这样从业务层面保证同账号的事务串行避免后一个事务的 SQL 插进前一个事务中间执行。mysql 事务处理中常见现像是扣库存的 SQL 执行成功了但后面的插入 SQL 失败结果库存扣了记录没生成。排查时打开慢查询日志和SHOW ENGINE INNODB STATUS看最近事务的锁等待往往能直接看到是哪条 SQL 卡住了。SHOW PROCESSLIST也是一线排查利器能快速看到当前连接执行到的 SQL 状态是 sleep 还是 query 还是 locked。4. redis 接入实战数据类型、排行榜缓存与分布式锁游戏服务器里 redis 的角色我用一句话说清mysql 管「终态」redis 管「热态」。玩家在线期间的数据频繁读写全走 mysql 会把数据库压垮redis 承接这部分压力。这份源码包里的 redis 模块通常封装了单节点连接也预留了 cluster 模式的配置位实际操作时按自己环境选择。4.1 连接配置与序列化redis 数据类型到游戏场景的映射先看连接配置这与 mysql 的套路类似local redisconf { host 127.0.0.1, port 6379, password , db 0, }redis 数据类型在游戏里的映射我做了一张表实际开发时直接对着选redis 数据类型典型游戏场景String玩家基础数据、计数器、分布式锁Hash玩家属性、背包某类物品的字段级更新List邮件队列、世界公告、离线消息Set好友关系、每日在线集合、去重操作ZSet排行榜、匹配分值、跨服天梯代码里落地时最常用的操作是三件套setex设置带过期时间的 key、hset更新 hash 字段、zadd写入排行榜local skynet require skynet local redis require service.db.redis local cjson require cjson local rds redis.connect({ host 127.0.0.1, port 6379, db 0, }) -- 玩家数据整串缓存3600 秒过期 rds:setex(player: .. uid, 3600, cjson.encode(player_data)) -- 玩家等级、金币进 hash更新字段不需要整串回写 rds:hset(player:ext: .. uid, level, 20) rds:hset(player:ext: .. uid, gold, 9999) -- 排行榜score 必须为数值 rds:zadd(rank:level:server1, player.level, player: .. uid)这里有个很容易被忽略的坑redis 里的 Lua table 不能直接存必须先经过序列化。我见过有人在 redis 里存了原生的 lua table读出来之后是个 userdata打印全是问号这就是序列化没做对。规范做法是写入时用cjson.encode读取时用cjson.decode必须成对local data cjson.decode(rds:get(player: .. uid))这个序列化习惯直接影响缓存层的稳定。redis 连接工具也多连不上时别急着怀疑框架先拿桌面客户端或命令行redis-cli ping探一下网络和密码是否正常再回服务端排查。4.2 缓存与排行榜缓存穿透与回源设计这份源码包大概率在玩家登录时「先读 redis、miss 再回 mysql」。这个流程本身不难难点在防穿透。直接看伪代码function get_player_data(uid, cb) local key player: .. uid local cached rds:get(key) if cached then cb(cjson.decode(cached)) return end load_from_mysql(uid, function(data) rds:setex(key, 3600, cjson.encode(data)) cb(data) end) end逻辑说得通缓存命中直接返回miss 时回源 mysql 并回填缓存。但实际压测时会发现热点玩家数据缓存刚过期几十个请求同时来查询全部 miss 全部回源 mysqlmysql 被打穿。常见做法是给回源动作加锁只允许一个请求去 mysql 加载其他请求等结果返回再从缓存拿local loading_flags {} function get_player_data_locked(uid, cb) local key player: .. uid local cached rds:get(key) if cached then cb(cjson.decode(cached)) return end if loading_flags[uid] then -- 已经有请求在回源等完成后重试 skynet.timeout(50, function() get_player_data_locked(uid, cb) end) return end loading_flags[uid] true load_from_mysql(uid, function(data) rds:setex(key, 3600, cjson.encode(data)) loading_flags[uid] false cb(data) end) endloading_flags在 skynet 单服务内部是安全的因为 actor 模型下单个服务实例不会并发执行两段代码。这个「单飞」设计是游戏服务器里防缓存穿透的常规解法比单独引入分布式互斥锁要轻。4.3 Redis 分布式锁set nx ex 的 token 陷阱游戏里抢购、发奖、扣库存这类操作经常要保证同一时刻只有一个服节点执行。skynet 多节点部署下单服务内存锁失效就得靠 Redis 分布式锁。网上铺天盖地的解法是SET key value NX EX 10代码看起来也就三五行local token skynet.now() .. : .. skynet.self() local ok rds:set(lock:buy, token, NX, EX, 10) if ok then -- 拿锁成功执行扣库存、发奖等业务 rds:eval( if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end, 1, lock:buy, token ) else -- 拿锁失败直接返回错误 end写法和注释里藏了三个重要的细节血泪教训NX保证只有 key 不存在时才设置成功这是「互斥」的本质EX设置过期时间防止业务还没跑完服务先宕了锁永远不释放。释放锁时必须用 Lua 脚本比对token再删 key。如果直接del可能出现这种情况锁 10 秒超时业务实际跑了 15 秒锁已经过期被别的节点抢走了这时候你执行del删掉的是别人的锁。token 就是「锁是我的才删」的凭证。锁过期时间必须大于业务最大执行时长。我见过把EX设为 3 秒业务里查一次 mysql 排个队就超时了结果两个节点同时进临界区库存超卖。设置锁超时之前先给关键业务路径做一遍耗时估算留足余量。5. 避坑排查mysql、redis 与服务端启动的五个真实坑这套源码包跑通不难但在我拆过和用类似包的项目里有五个坑是反复出现在不同人屏幕上的。每个都按「现象、原因、解决」说清楚能帮你省下半天排查时间。5.1 编译错误cservice 目录缺失与 skynet 二进制不可用现象在源码包根目录执行./skynet config.master启动后立刻退出报错提示找不到某个.so或者直接提示skynet: cant load cservice/skynet.so。原因这个源码包带的是 skynet 框架源码不是编译好的二进制。首次拿到后不执行 make直接跑主程序cservice 下还没有生成对应模块的 .so 文件运行时就加载不到。解决先进 skynet 目录编译再回根目录启动顺序不能反过来。cd ./skynet make linuxmacOS 环境执行make macos。编译成功后ls cservice/能看到logger.so、skynet.so这类文件再启动就不会报这个错。编译期还容易遇到 gcc 版本过老报语法错误的情况先gcc --version确认版本Ubuntu 20.04 以后的环境基本没问题。5.2 mysql 连接为 nil驱动没装好与字符集配置错误现象服务能启动但日志里不断重复connect mysql failed或者调用查询时回调收到err内容是缺少某个 mysql 依赖库。原因skynet 的 mysql 驱动底层依赖系统里的libmysqlclient。云主机最小化安装或 Docker 容器里没有这个库驱动加载时直接失败。另外字符集配置传成utf8时连接字符集校验不过连接也会异常。解决先装系统依赖再检查字符集配置。apt-get install -y libmysqlclient-dev配置里统一使用charset utf8mb4。装完依赖后重启服务连接日志恢复正常。这里有一个玄学现象值得说mysql 驱动在报错时错误信息里往往不带「缺库」字样而是模棱两可地给一个连不上或超时容易把人往网络和防火墙方向带偏。排查顺序很重要先确认依赖再查网络。5.3 连接池耗尽max_pool_size 与请求尖峰不匹配现象压测一上量日志开始不断出现no more mysql connection所有查询延迟飙高服务响应明显变慢。原因连接池默认大小 8平时够用。压测时玩家登录集中在同一时间大量查询同时进来连接被占满后续请求排队等待超时后堆积更多请求形成雪崩。解决先拆慢查询再调大连接池。只调max_pool_size是治标不治本的因为慢 SQL 本身把连接占用时间拉长了。SHOW PROCESSLIST;看到多条query状态久未结束的 SQL先优化。常见的优化手段是给高频查询的字段建索引避免排序和回表。必要的时候调大max_pool_size到 16 或 24但连接数也不是越大越好mysql 服务器本身有最大连接数上限超了照样报错。生产环境更合理的设计是拆出多个 db 服务登录服务用独立的连接池业务查询用另一个池互不挤占。5.4 回调传函数无效匿名函数在消息序列化中丢失现象自己封装 db 调用时想图省事把回调直接作为参数传进跨服务消息里结果回调完全不执行或者报invalid address、callback not found之类的错。原因skynet 服务间通信传的是字符串、数字、table 这类可序列化数据Lua 函数没法在服务间传递。驱动层如果暴露的是底层消息接口匿名函数传过去就被丢弃了。解决给回调建槽位用数字 id 代替函数本身跨服务传递。一般源码包的 dbmanager 里会封装好这一层local cb_map {} local cb_seq 0 function db_query(sql, params, cb) cb_seq cb_seq 1 cb_map[cb_seq] cb inner_query(sql, params, cb_seq) end local function inner_query(sql, params, cb_id) local function on_result(results, err) local cb cb_map[cb_id] cb_map[cb_id] nil cb(results, err) end driver.query(sql, on_result, params) end逻辑说明cb_seq每次自增生成唯一 idcb_map保存回调引用跨服务只传 id。回调完成后再从表中移除避免槽位泄漏。新手最常见的翻车点是直接db_query(sql, function(...) end)然后跨服务调用看到代码没错就是调不通问题全在这个序列化边界上。写业务时统一走封装别在业务里自己造跨服务的函数参数。5.5 redis protected mode本机调试的拦路虎现象服务端连接本地 redis 启动正常但换到 WSL 调试或云服务器部署时连接报DENIED Redis is running in protected mode。原因redis 的protected mode默认开启只允许本机回环地址且无密码的连接。服务端进程跨网络访问、或者 bind 配置变更后redis 会拒绝这个连接。解决本机联调时直接关掉保护模式生产环境改为显式配置密码并绑定内网地址。redis-cli -p 6379 CONFIG SET protected-mode no持久化配置要写进 redis.conf 里protected-mode no否则重启后恢复默认。生产环境更推荐的做法是设置requirepass并且给 skynet 的 redis 连接配置加上对应password字段。Windows 本机调试时注意redis 若装在 Windows 子系统里通过127.0.0.1访问一般没问题跨主机访问大概率触发保护模式先查这个再怀疑服务端代码。还有人在 Windows 上用 Docker 跑 redisDocker 默认端口映射和 redis 配置冲突的情况很常见我一般直接装原生 redis 服务少一层容器网络问题调试效率更高。6. 对账验证缓存与 mysql 数据一致性的检查套路先把这套方法用在你自己项目上源码包跑通后别急着加业务先做一次「冷启动对账」。这个动作能同时验证 mysql 落库、redis 缓存、服务启动三条链路是否真的通也顺便把数据库选型是否合理的底摸清楚。对账的思路很简单以 mysql 为基准清洗 redis 业务缓存然后重新触发服务逻辑看 mysql 里的数据和 redis 里的缓存是否对应。先写一个清缓存脚本把player:*前缀的 key 全清掉redis-cli --scan --pattern player:* | xargs -I{} redis-cli del {}再重启 skynet模拟一次玩家登录流程让服务端走一遍 mysql 回源逻辑重新填充 redis。这时分别从两边统计数量mysql -h127.0.0.1 -ugame -pgame123 game \ -e SELECT COUNT(*) FROM tb_player; redis-cli dbsize比对两条记录数如果 redis 的 player key 数量与 mysql 的玩家记录数明显不匹配说明回源逻辑有漏写或过期策略有问题。再进一步验证单条数据是否一致可以抽一个 uid 分别取两边数据做结构化对比redis-cli get player:1001 mysql -h127.0.0.1 -ugame -pgame123 game \ -e SELECT * FROM tb_player WHERE uid 1001;字段值不一致重点排查序列化环节——写入时cjson.encode的字段和 mysql 字段名是否对齐数字是否被转成了科学计数法。最后压测时验证缓存穿透防护是否生效把回源单飞逻辑临时关掉看 mysql 的SHOW PROCESSLIST是否出现大量同一个 uid 的查询再打开单飞同一个 uid 的查询应该只剩一条。这个对比能直观确认「redis 缓存不再被击穿」不是靠直觉而是靠实测抓到证据。从那以后我每次拿到新的 skynet 服务端源码包都会强制把这套对账流程完整走一遍再开始改业务代码。数据库层的隐蔽问题如果能在这个阶段爆出来好过上线后被玩家流量打出来。希望帮到你。本文还有配套的精品资源点击获取
![[从入门到入土!!!] Ubuntu20.04 系统开发环境配置（系统配置，显卡驱动，CUDA，ROS，VSCode，Anaconda等）](http://pic.xiahunao.cn/yaotu/[从入门到入土!!!] Ubuntu20.04 系统开发环境配置（系统配置，显卡驱动，CUDA，ROS，VSCode，Anaconda等）)
