- 博客(156)
- 收藏
- 关注
原创 RPC 模块面试讲解稿
老方案用。skynet 的 “lua” 协议是共享通道——所有 lua 消息走同一个 dispatch handler。-- 老方案if cmd == "__rpc_resp__" then -- 每个消息都要比对...endend)利用 skynet 的内核能力,注册独立协议类型。id = 13,end,-- 发送skynet 内核按协议号 13 直接路由,不需要字符串比对,O(1)RPC 响应和业务消息完全隔离,互不干扰框架自动注册在rpc.init()中,业务代码无感。
2026-10-23 12:47:09
395
原创 通用后端问题全景与解决方案
每个通用后端问题都不是孤立存在的,实际系统中往往是多个问题交织。建议在面试或设计时,先识别出问题属于哪几类,再按对应子场景选择合适方案,最后根据团队体量做取舍。如果需要某一类问题的更详细技术卡片(如网格分区AOI实现细节、时间轮Go代码示例),我可以进一步展开。
2026-10-21 12:03:44
226
原创 skynet——RPC 超时机制优化方案
指标当前方案(per-call fork+sleep)影响协程数N(每个 RPC 创建 1 个)内存 O(N),N 大时爆炸C 定时器N(每个 RPC 注册 1 个)定时器轮压力 O(N)协程创建每次调用创建 1 次高频 malloc + GC上下文切换父→子→父,至少 2 次CPU 开销。
2026-10-19 08:53:47
238
原创 skynet热更新实现问题与排错记录
- 代码热更新 - 完整流程-- Step 1: 清除 C 层代码缓存(process 级别,所有 lua_State 共享)-- lauxlib.c 的 struct codecache,以文件路径为 key 缓存编译后的 proto-- loadfile 命中此缓存会跳过磁盘读取,直接返回旧的字节码-- Step 2: 清除 Lua 层模块缓存(per lua_State)-- package.loaded 和 skynet/require.lua 的 loaded 是同一张表。
2026-10-19 08:10:35
282
原创 skynet cluster 完全指南:从基础使用到生产方案
读完这篇你会明白:cluster 怎么用、它的局限从源码层面是怎么来的、生产环境有哪些解决方案、各自优劣是什么。
2026-10-14 12:07:15
238
原创 C 扩展开发指南:从 Lua 到 skynet 的完整链路
读完这篇你会明白:C 扩展到底是什么、skynet 怎么加载它、怎么从零写一个、C++ 怎么写、有哪些坑。
2026-10-14 09:42:30
286
原创 skynet的gate和watchdog
维度方案一:加固方案二:C Gate方案三:MsgServer方案四:自研改造量小(只改 watchdog)中(换 gate,改 watchdog 协议)中(换整套)大适用并发< 10001000 ~ 10 万+< 5000无上限CPU 效率中高(C 层处理)中可定制登录态自己写自己写✅ 内置自己写断线重连不支持不支持✅ 内置 AFK可定制防多点登录不支持不支持✅ 内置可定制Agent 池化✅ 容易加✅ 容易加框架已优化按需运维接口手动加手动加框架自带。
2026-10-09 11:00:47
245
原创 sproto和protobuf
设计哲学:极简主义 设计哲学:功能完备最佳场景:Lua游戏后端 最佳场景:多语言微服务性能:编解码极快 性能:编码紧凑上手:10分钟看懂 上手:需要了解工具链生态:小众但专精 生态:Google背书,无处不在对你当前项目的建议:继续用 Sproto。它就是为了"Lua + 游戏服务器"这个场景量身定做的,你项目里的chatroom和arena用 Sproto 非常合适。理解它的逻辑之后,你会发现它比 Protobuf 简单得多。
2026-10-09 10:12:37
136
原创 通用AI辅助软件开发工作流
规则示例:纯文本- 语言:Go 1.22+- 风格:遵循 Uber Go Style Guide- 错误处理:所有错误必须显式处理,不允许 _- 日志:使用 structured logging(zap),关键路径打印 traceId- 并发:所有共享变量必须加锁或使用 channel,禁止裸 sync.Map- 事务:数据库事务必须显式控制边界,不允许自动提交- 幂等:所有写操作必须携带 requestId,并在数据库层去重。
2026-09-30 17:43:45
212
原创 系统设计第二十八天决策卡
在SLG大地图中,玩家通过行军指令调动部队进行攻击、采集、支援等操作。部分玩家可能通过外挂、修改客户端数据、网络加速器等手段进行作弊,例如:瞬移(部队瞬间跨越超远距离)、加速行军(缩短实际到达时间)、无敌行军(无视阻挡或陷阱)、虚假行军(伪造不存在的部队)、资源盗刷(通过异常行军反复获取资源)等。反作弊系统需要实时检测所有行军行为,识别异常并采取相应措施(警告、踢下线、封禁、回滚等),同时不能误伤正常玩家。
2026-09-21 10:40:12
121
原创 系统设计第二十六天决策卡
在SLG游戏中,大地图上分布着各类资源点(木材、石料、铁矿、粮田等)。玩家可以派遣部队前往资源点进行采集,采集过程中部队驻留在资源点上,每隔一段时间获得一批资源。同时,玩家的主城和分城内有资源建筑(农田、伐木场等),会持续产出资源,玩家可以手动收取。资源点是有限的,多个玩家可能同时瞄准同一个资源点,需要处理抢占、采集速度、产量衰减等逻辑。此外,还有资源保护机制(如仓库保护量、被掠夺时的损失计算)。
2026-09-20 11:11:41
192
原创 系统设计第二十五天决策卡
海量数据在线迁移与一致性常规方案:CDC(如Canal/Debezium)捕获增量 + 全量快照 + 数据校验脚本。优劣:CDC对主库压力小,但架构复杂;主从复制简单,但有延迟和切流停顿。跨服ID冲突与重映射常规方案:全局唯一ID生成器(Snowflake/Leaf) + 旧ID到新ID的映射表(Redis/DB)。优劣:全局ID一劳永逸;映射表灵活但查询有额外开销。赛季生命周期与数据隔离常规方案:物理隔离(独立数据库/表) + 配置驱动 + Saga模式(结算/继承/清理)。
2026-09-19 13:30:20
65
原创 系统设计复盘2026-09-18
已经在多个核心场景中完成了从“零散知识点”到“结构化思考”的初步转变。最大的进步在于敢于质疑权威方案(如质疑九宫格在SLG中的适用性、指出MQ不适合实时有序场景),并能主动识别自己的知识盲区(如“对保证响应时间没思路”“对顺序约束没思路”)。,导致面对新场景时仍会陷入“不知从何下手”的困境。知道很多技术名词,但到了实际设计时,大脑一片空白,不知道用哪个、怎么用、为什么用。根本原因是我的知识结构是点状的、孤立的,缺少一张“技术 → 问题 → 场景”的映射网络。
2026-09-18 20:02:28
99
原创 系统设计第二十四天决策卡
在SLG大世界中,玩家可以创建或加入联盟。联盟可以占领地图上的领地(如城池、关卡、资源点),形成连续的势力范围。联盟成员享有领地内的特殊权益(如资源加成、保护、传送)。领地在地图上以颜色标识,显示联盟的势力扩张。需要设计一套支持大规模联盟、动态领地、权限分级、跨服联盟战的联盟与领地系统。
2026-09-18 11:51:02
221
原创 系统设计第二十三天决策卡
在SLG大世界中,玩家派遣部队进攻敌方城池、要塞、资源田或拦截其他部队。当攻击方部队到达目标位置时,触发一场异步战斗。战斗过程不进行实时操控,而是根据双方兵力、武将、技能、阵型、士气、地形等参数,在一瞬间(或极短时间内)完成结算,生成战报。战报包含详细的战斗过程(回合制、伤亡记录、技能触发等),并推送给交战双方及相关联盟成员。需要设计一套高性能、公平、可验证的异步战斗结算与战报系统。
2026-09-17 12:04:14
210
原创 第二十二天决策卡新知详细文档
时序一致性容灾,并给出可落地的解决方案。理解为什么"先来后到"在分布式系统中是个难题掌握几种实用的顺序保证手段及其适用场景学会在实时性要求高的场景下替代消息队列的方案特别说明:在 SLG 行军、技能释放、交易这类对实时性要求极高的场景下,通常不会用消息队列来保证核心流程的顺序。消息队列的延迟(毫秒到秒级)和重试机制在这些场景下不可接受。本文会讲清楚什么场景该用什么。很多人以为状态机就是几个if-else判断。严谨的状态机应该是一张状态转换表当前状态 \ 事件出发拦截到达撤回待命。
2026-09-16 13:17:37
38
原创 系统设计第二十二天决策卡
在SLG大世界中,玩家可以派遣部队从一个坐标移动到另一个坐标(出征、集结、扫荡等)。行军过程中,部队会沿路径移动,期间可能发生拦截、撤退、加速等操作。当部队到达目的地时,触发一系列事件(如攻城战开始、资源采集开始、驻防生效等)。需要设计一套可靠、高性能的行军与到达事件系统。
2026-09-16 12:07:29
166
原创 系统设计第二十一天决策卡
你正在开发一款SLG手游,世界地图大小为 10,000 × 10,000 格,每格代表一块土地。全服同时在线 5000 人,每个人在大地图上拥有自己的主城、分城、部队和视野范围。玩家拖动屏幕时,客户端需要实时加载当前视口内的地块状态(资源点、敌方部队、联盟成员等)。你需要设计大地图的视野管理系统,保证玩家滑动地图时流畅加载,且服务器不会因为全服广播而崩溃。
2026-09-15 18:12:23
183
原创 R-Tree 数据结构详解
│ R-Tree 冷门原因 ││ 1. 领域专属性:GIS、游戏等特定领域才需要 ││ 2. 入门门槛高:需要理解空间数据处理需求 ││ 3. 实现复杂:分裂策略、平衡维护较难 ││ 4. 课程时间有限:优先教授通用数据结构 ││ 5. 替代方案多:B+Tree 足以应对大部分场景 ││ 6. 工业级库成熟:实际项目很少自己实现,用现成库 ││ R-Tree 核心价值 ││ 1. 用 MBR 简化空间关系判断(矩形比任意形状简单得多) │。
2026-09-15 10:41:11
198
原创 树结构在游戏行业中的应用
空间效率:通过分层组织,快速排除不相关对象决策智能:用行为树实现复杂的AI逻辑场景管理:场景图实现层级变换和可见性裁剪路径规划:堆结构支持高效的寻路算法2D游戏优先考虑四叉树3D游戏考虑八叉树或R-TreeAI决策使用行为树场景管理使用场景图合理使用树结构能显著提升游戏性能和可维护性。
2026-09-15 09:28:11
213
原创 系统设计第二十天决策卡
游戏内设有拍卖行系统,允许玩家将非绑定的装备、材料、宠物等物品上架出售,其他玩家可以通过搜索、竞价或一口价购买。拍卖行支持两种交易模式:一口价(立即成交)和竞拍(设定起拍价和持续时间,价高者得)。全服同时在线5000人,日活跃3万人,高峰期每秒约有500次上架/购买/竞价操作。拍卖行中同时存在的在售物品数量约为50万~100万件。你需要设计一套拍卖行系统,保证物品上架、搜索、竞价的实时性、一致性、防欺诈,同时控制数据库和搜索引擎的压力。
2026-09-14 13:41:35
160
原创 系统设计第十九天决策卡
你正在开发一款MMORPG,运营团队需要配置各类限时活动(如双倍经验、充值返利、限时BOSS、节日兑换商店)。活动有固定的开始时间和结束时间,到达指定时间点时,全服所有在线玩家需要立刻感知到活动开启(如收到弹窗提示、活动入口亮起、掉落加成生效)。活动结束后,相关效果需立即失效,并回收活动道具/货币。全服同时在线5000人,日活跃3万,运营可能同时配置10~20个活动(每个活动有独立的起止时间)。你需要设计一套活动定时调度系统,保证活动状态切换的准时性、一致性、可追溯性。
2026-09-11 11:02:45
177
原创 系统设计第十八天决策卡
全服同时在线5000人,日活跃用户约3万,每天系统发放邮件约10万封,玩家互发邮件约5万封。每封邮件平均包含1~3个附件。你需要设计一套邮件系统,保证可靠送达、高效存储、附件不丢失、过期及时清理。
2026-09-10 13:04:44
185
原创 系统设计第十七天决策卡
玩家在战斗过程中可能因网络波动、WiFi切换、隧道信号中断等原因短暂掉线。掉线期间,玩家的角色仍留在游戏世界中(可以被攻击、击杀),也可能被AI托管。玩家需要在重新连接后,尽快恢复到掉线前的完整状态(位置、血量、技能CD、Buff/Debuff、背包物品、任务进度等),并继续参与游戏。全服同时在线5000人,平均每小时约有5%~10%的玩家经历至少一次掉线重连。
2026-09-09 10:02:04
54
原创 如何实现slg中长距离行军的路线显示
服务端收到行军指令后,必须重新执行一次完整寻路,对比客户端提交的路径是否一致,防止外挂修改坐标或瞬移。原理:从起点开始,尝试向终点发射射线,如果被障碍挡住,则在最后一个可见点处记录转折点,然后从该点继续。将地图划分为若干区域块(如 10×10 格子一块),先计算块间路径,再在块内细化。JPS 是对 A* 在均匀网格上的极致优化,通过强制邻居规则跳过大量对称路径。关键函数 jump:沿一个方向递归前进,直到遇到障碍、边界、强制邻居或目标。微观寻路:在每个块内,从入口到出口运行A*,拼接成完整路径。
2026-09-08 20:01:22
342
原创 系统设计第十六天决策卡
开发一款MMORPG,战斗系统支持玩家与怪物、玩家与玩家之间的实时战斗。一次攻击的伤害值由攻击方的攻击力、暴击率、防御方的护甲、抗性、减伤buff、技能系数等多个因素共同决定。战斗中每秒发生数十次伤害计算,全服5000人同时在线,高峰期每秒产生数万次伤害计算请求。你需要设计一套战斗伤害计算系统,保证计算结果准确、一致、可扩展,且能灵活应对后续的数值调整。
2026-09-08 17:51:00
169
原创 系统设计第十五天决策卡
正在开发一款MOBA或MMORPG,每个英雄/职业拥有多个技能,每个技能有独立的冷却时间(CD)。玩家释放技能后,该技能进入冷却状态,冷却结束后方可再次使用。游戏支持全服5000人同时在线对战,每个玩家每秒可能释放0.5~2个技能。你需要设计一套技能冷却管理系统,确保冷却时间的准确性、实时性,同时控制服务器资源消耗。
2026-09-04 11:35:36
306
原创 系统设计第十四天决策卡
mmo游戏的地图大小为 10km × 10km,支持 5000 名玩家同时在线。每个玩家控制一个角色,角色位置会随玩家操作(移动、跳跃、施法等)实时变化。其他玩家需要看到该角色的当前位置,以实现交互(战斗、组队、聊天等)。你需要设计一个位置同步系统,使得所有玩家都能以较低的延迟(<200ms)看到其他玩家的大致位置,同时控制服务器和带宽成本。
2026-09-03 11:58:33
167
原创 系统设计第十三天决策卡
开发一款竞技类游戏(如 MOBA / FPS / 格斗),玩家点击"开始匹配"后,系统需要在全服等待队列中寻找一个实力相近、网络延迟可接受、等待时间合理的对手,组成 1v1 对局。匹配成功后,系统分配一台游戏服务器,通知双方玩家进入对局。
2026-09-02 12:42:54
189
原创 系统设计第十二天决策卡
游戏内有一个全服通用的"战力排行榜"。玩家的战力值会随装备、等级、战斗结果实时变化。排行榜需要支持玩家随时打开界面查看自己的排名和全服 Top 100 的玩家列表。运营还要求能按不同维度(如"今日战力增长榜"、“历史最高战力榜”)查看。
2026-09-01 10:43:05
160
空空如也
给普通码农的技能建议
2026-06-25
非专业游戏产品开发讨论
2026-06-16
游戏后端的学习资源推荐
2025-10-25
skynet和lua的游戏开发疑惑
2025-07-13
求好的python web开源项目
2023-06-22
工作一年的游戏后端程序的当前职业发展的一些困境
2023-05-29
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅