要说我为什么对这份卷子印象深其实很简单游戏服务器开发这个方向能拿来在校招笔试里成套考察的内容就那些但网易2018这套题的出题思路非常规整算法、网络、并发、数据库、业务场景设计全都有而且大部分题目跟游戏后端真实遇到的问题强相关。这几年我带团队面试应届生也经常把里面的题型改一改再拿出来考效果依然很好。这份试卷最适合谁看一类是准备校招游戏后端岗位的同学你需要知道备考重点和答题节奏另一类是刚入行不久、想系统梳理游戏服务器知识体系的开发你会发现很多平时“会用到但没深究”的技术点在这套题里都有一一对应的答案。不管你是哪种这篇文章我都会按题目考察方向拆开讲把每个模块背后真正想考察的能力说清楚并给出可落地的解法、代码和避坑经验。1. 这份笔试卷其实是在挑什么样的人1.1 游戏服务器开发和其他后端到底差在哪很多同学在准备游戏服务器笔试前是按普通互联网后端来复习的上来就刷Spring、微服务、JVM结果看到卷子发现完全不是一回事。游戏服务器开发和Web后端虽然有重叠但核心关注点差异很大。游戏服务器更看重实时交互、高并发短连接、状态同步、玩家数据一致性而Web后端更关注高可用、分布式事务、弹性扩缩容。实际线上场景里玩家每秒钟会往服务器发送大量移动、施法、拾取、聊天、战斗指令这些消息大多要求低延迟处理对服务器来说意味着网络收包要快、逻辑计算要快、数据落地不能拖后腿。所以笔试卷里网络编程、Linux并发模型、内存使用效率永远是重头戏而不会像Java后端笔试那样重点考JVM调优和Spring容器生命周期。网易这套卷子的筛选目标也很明确不是招一个“会写Java/C的人”而是招一个“能理解玩家行为、能在高并发下保障服务稳定、能设计合理状态同步方案的人”。所以读题的时候你要时刻问自己这道题放在我的游戏服务器里会在哪个环节出现这样答题才不会偏。1.2 从题型分布看考察地图虽然原卷的完整题目我没有全部原文但根据历年考生回忆和同类校招卷的结构可以把考察方向归纳成五块算法与数据结构、计算机网络、操作系统与Linux并发、数据库与缓存、业务场景系统设计。这五块对应游戏后端日常工作中的五种核心能力海量数据处理能力、网络协议理解能力、高并发服务端编码能力、数据存储设计能力、复杂玩法系统拆解能力。从占比来看算法和网络通常最大业务设计题是区分度最高的部分数据库和并发则是送分题和送命题并存。你可以把这张卷子理解成一场体检算法题查你的“基本功底子”网络题查你的“网络敏感度”并发题查你的“多线程意识”业务设计题查你的“工程经验”。哪一块弱进游戏公司做服务器开发都会很吃力。2. 算法题不只是刷题考的是海量数据下的取舍能力2.1 TopK问题排行榜背后的核心解法游戏服务器笔试里出现频率很高的算法题基本绕不开TopK和海量数据处理。比如服务器上有1亿条玩家战力数据需要快速找到战力前100的玩家并做实时榜单展示你会怎么设计这就是一个非常典型的TopK场景。很多人的第一反应是全部排序然后把前100条取出来但这是错误的做法。全量排序复杂度是O(n log n)1亿条数据排序一次要几秒资源消耗也很大而且排行榜是实时更新的不可能每次查询都重排整个数据集。正确答案是维护一个大小为K的最小堆遍历一遍数据堆顶就是当前第K大的元素。复杂度是O(n log K)K100的时候比全排序快好几个数量级。我用C给你写一个最简单的实现#include vector #include queue #include iostream std::vectorint topK(std::vectorint nums, int k) { if (k 0 || nums.empty()) return {}; // 小顶堆堆顶是最小值 std::priority_queueint, std::vectorint, std::greaterint pq; for (int num : nums) { if (pq.size() k) { pq.push(num); } else if (num pq.top()) { pq.pop(); pq.push(num); } } std::vectorint result; while (!pq.empty()) { result.push_back(pq.top()); pq.pop(); } // 结果是升序的需要的话可以reverse std::reverse(result.begin(), result.end()); return result; }这段代码的思路是堆里始终保存“当前已经扫过的元素中最大的K个”一旦发现新元素比堆顶即当前第K大的那个最小值还大就替换掉堆顶。遍历结束堆里的K个元素就是TopK。我在实际项目里做全服战力榜就是这种做法只不过底层换成了Redis的ZSET因为ZSET天然支持按分数排序和增量更新比在应用层维护堆更省事这点后面会细说。这个考点真正想考察的是你有没有“大数量级意识”。游戏服务器里任何一条玩家数据放大到全服规模都不是普通编程题那么简单。所以答题时不要只写思路要主动说出“为什么不用全排序”“堆为什么用最小堆而不是最大堆”“更新频率高时如何优化”这些细节才是加分项。2.2 字符串与文本处理敏感词过滤的底层逻辑字符串类题目在游戏服务器笔试里不是单纯考反转、回文这么简单更常见的是跟业务绑定的文本处理题。比如请设计一个敏感词过滤系统要求支持几十万敏感词、玩家聊天消息毫秒级返回过滤结果。第一次见到这题的同学很多会回答“用HashMap逐个匹配”敏感词少的时候确实能用可一旦敏感词库膨胀到几十万条每条消息又要和所有敏感词做匹配性能立刻崩掉。正确做法是用字典树加失败指针也就是AC自动机它能把多模式串匹配的时间复杂度压缩到近似O(n)n是消息长度和敏感词数量无关。这里简单说一下AC自动机的构建思路先把所有敏感词插入字典树然后通过BFS为每个节点构建失败指针失配时跳到另一个分支继续匹配而不是回到根节点重来。匹配时只需要扫描一遍玩家输入的文本就能找出所有命中的敏感词。我在自己项目里做过聊天过滤器词库大概20万条纯C实现AC自动机后一条普通聊天消息的过滤耗时从几十毫秒降到几百微秒效果立竿见影。考场上如果时间不够没必要把AC自动机完整代码写出来但你至少要把字典树和失败指针的核心思想讲清楚最好能画出一个小例子。更重要的是说一句“生产环境我会用AC自动机因为它匹配时间复杂度是线性的”这就能和只背了“敏感词替换”的同学拉开差距。2.3 算法题的答题节奏与自查清单针对游戏服务器方向的校招笔试算法题我给你一个实操建议先做会做的、分高的题不要一上来卡在难题上。通常试卷的题量和时间是不成比例的很多人最后不是因为不会做而是因为前面耗太久导致后面系统设计题没时间答。我建议的答题顺序是业务场景设计题优先做因为这类题即使不完美也能展示思路其次是网络和数据库题这些答案比较标准化算法题里如果遇到TopK、链表、树这种高频题快速写完遇到那种明显需要复杂推倒的压轴题先写暴力解保底有剩余时间再优化。自查清单也分享一份边界条件数组为空、K为0、负数、整数溢出用long long、输出顺序要求升序还是降序、多线程安全隐患如果有并发访问。这些细节在笔试中很容易因为疏忽被扣分但只要你养成习惯每次写完代码都默念一遍就能避免大部分低级错误。3. 网络题不能只会背八股粘包、拆包、重传必须落到代码3.1 TCP可靠传输三次握手四次挥手只是热身网络题是游戏服务器笔试的绝对核心而且网易这类公司的出题人不会满足于你背出“三次握手、四次挥手”。他们更愿意问为什么要三次握手而不是两次TIME_WAIT为什么要等2MSL滑动窗口怎么影响游戏消息的发送效率先说握手问题。三次握手的核心意义是让双方确认彼此的接收和发送能力都正常同时同步初始序列号。如果只用两次握手服务端无法确认客户端的接收能力也无法避免历史重复连接导致的资源浪费。四次挥手则是因为TCP是全双工的需要两个方向分别关闭所以至少四次。TIME_WAIT这个问题在游戏服务器里尤其重要。主动关闭连接的一方会进入TIME_WAIT状态持续2MSL。游戏客户端经常断线重连服务器如果作为主动关闭方TIME_WAIT连接多了会占用大量本地端口导致新连接无法建立。我在压测游戏登录服务器时就遇到过这个问题短连接压测跑一会儿端口耗尽新连接全部失败。解决方案是开启SO_REUSEADDR、调整TIME_WAIT复用参数或者减少服务端主动断开的频率。滑动窗口和拥塞控制同样值得展开。游戏消息大多是高频小包如果窗口太小带宽利用不起来玩家会感觉到延迟如果窗口太大又会导致缓冲膨胀、延迟变大。所以游戏服务器通常会在TCP之上自己做消息合并和优先级调度而不是完全交给内核默认策略。3.2 粘包拆包游戏消息边界的那道坎TCP粘包拆包是游戏服务器笔试必考题没有例外。TCP是字节流协议它不保证一个应用层消息的边界就像一根水管往桶里倒水你看到桶里有多少水但你分不清哪一段水来自哪一次倒水。如果不做处理接收方可能一次性读到两条半消息或者一条消息被拆成两次读取。通用解法有三种固定长度消息、分隔符、长度字段消息体。游戏服务器项目里最常用的是第三种因为业务消息长短不一固定长度浪费带宽分隔符又容易和消息内容冲突。具体协议格式一般是消息头4字节长度 2字节消息ID 消息体包头里记录整条消息的总长度。给一段接收缓冲区拆包的示例代码// 假设recvBuf已经累积了从socket读取的原始字节 bool parseMessages(std::vectorchar recvBuf, std::functionvoid(int msgId, const char* data, int len) handler) { size_t offset 0; while (offset 6 recvBuf.size()) { int msgLen *(int*)(recvBuf.data() offset); // 前4字节是消息总长度 short msgId *(short*)(recvBuf.data() offset 4); // 接着2字节是消息ID if (msgLen 6 || msgLen MAX_MSG_SIZE) { // 长度非法说明数据被污染或对端异常 recvBuf.clear(); return false; } if (offset msgLen recvBuf.size()) { break; // 半包等下次recv } handler(msgId, recvBuf.data() offset 6, msgLen - 6); offset msgLen; } if (offset 0) { recvBuf.erase(recvBuf.begin(), recvBuf.begin() offset); } return true; }这段逻辑的关键在于永远用“当前缓冲区已积累的字节数”判断是否能凑齐一条完整消息凑不齐就等下一次recv数据来了再继续解析。这个函数我一般放在主循环里每次epoll收到可读事件后先read到临时buf再append进recvBuf最后调一次parseMessages。游戏服务器踩坑最多的点就是这里有人会在半包时直接把recvBuf清空导致消息丢失有人会把offset算错导致解析错位。写题时如果能把“半包等待”这个边界说出来面试官印象分会高很多。3.3 高频包场景下的协议选型TCP、UDP还是自研可靠传输比粘包拆包更深一层的网络题是让你讨论游戏该用TCP还是UDP。这题没有绝对正确答案游戏类型决定了答案。MMORPG、回合制等对消息可靠性要求高的游戏用TCP省心因为不需要自己处理丢包重传MOBA、FPS这类对延迟极其敏感的游戏TCP的拥塞控制和重传策略会带来明显卡顿所以常用UDP并在UDP之上自研可靠传输协议。我在实际项目中给一个多人实时对战玩法做过方案选型当初在TCP和UDP之间纠结了很久。TCP的问题在于队头阻塞一个包丢了后续所有包都要等重传哪怕是位置同步这种不带关键逻辑的包也得排队。自研UDP协议则可以对不同消息做分级处理比如位置同步用不可靠UDP伤害结算用可靠UDP这样既保证最终一致性又最大限度降低延迟。如果笔试题里让你设计一个“类似KCP”的可靠UDP你可以从这几个点回答序列号、ACK确认、超时重传、快速重传、滑动窗口。答题时重点说清楚“为什么内核TCP的重传机制不适合游戏高频小包”而不是把KCP源码默写一遍。面试官真正想听的是你对“可靠性”和“实时性”这对矛盾有自己的权衡。4. Linux与并发游戏服的性能瓶颈都在这里4.1 epoll事件模型ET与LT怎么选游戏服务器的网络层几乎离不开epoll。笔试常考的是水平触发LT和边缘触发ET的区别以及游戏服务器应该用哪种。LT模式下只要fd上还有数据没读完每次epoll_wait都会返回这个fdET模式下只有数据从无到有的那一刻会触发一次事件之后如果没读完内核不再通知。如果你用ET就必须循环读取直到EAGAIN否则剩下的数据会永远留在缓冲区里没人处理。很多同学答到这里就停了但真正的加分点是“游戏服务器实际怎么选”。我自己的偏好是连接管理器用LT逻辑处理用ET配合非阻塞IO。原因很简单LT代码更安全不容易出现数据滞留ET性能更好可以减少epoll_wait的重复唤醒。用ET时接收缓冲区和发送缓冲区都要包一层循环读写的封装同时必须在fd上设置O_NONBLOCK否则最后一次read会阻塞住整个线程。答题时你也可以提一提Reactor模型。游戏服务器的网络层基本都是基于Reactor一个线程跑epoll_wait负责监听和处理可读可写事件事件触发后解析好的业务消息丢到任务队列由逻辑线程池处理。这里有个隐藏考点epoll_wait返回的活动fd列表如果很多你不能在事件循环里同步处理耗时逻辑否则后面的事件全部被阻塞。正确做法是“IO线程只收包和发包逻辑线程只管计算”。4.2 多线程并发模型从锁到无锁的演进游戏服务器并发题常见问法是多个玩家同时攻击同一个BOSS你如何保证伤害计算不出现并发问题这个问题表面考锁实际考并发模型选型。最朴素的方案是用互斥锁保护BOSS血量这个共享变量但游戏服务器里任何热门玩法都可能同时有几百上千人参与一把大锁会把并发性能压得很低。更好的方案是单线程逻辑模型所有玩家指令串行处理不存在共享变量竞争自然不需要锁。这也是很多MMORPG服务器的做法逻辑线程只有一个对CPU多核的利用则靠“开多个进程/多组逻辑线程分线”来解决。锁的细分也很常考互斥锁、读写锁、自旋锁各自适用什么场景CAS是什么什么时候用无锁队列。我的经验是游戏服务器中真正需要锁的地方大多在跨线程消息队列、日志写入、数据库异步落库这几个环节而不是业务逻辑本身。如果你能在答题时说一句“游戏逻辑尽量单线程跑锁主要用在IO线程和逻辑线程之间的队列上”说明你真的理解游戏服务器的瓶颈在哪。无锁队列也是加分项。生产者和消费者模型下多生产者写队列、单消费者读队列可以用一个无锁的MPSC队列如果只有一个生产者一个消费者用ring buffer就够了性能能顶到很高。我见过不少游戏项目用Disruptor思路改写自己的跨线程队列效果都很稳。笔试答到这一层已经不输给很多社招候选人了。4.3 线上排查top、strace、gdb三板斧除了理论有些笔试卷会把线上排查场景当应用题来出比如游戏服务器CPU飙到100%你怎么定位原因这类题很考验实战经验没有真实排查过的人只能瞎编。第一步永远是top找出CPU占用最高的进程和线程ID。然后top -Hp 找到具体的线程再用gdb attach到进程thread apply all bt打出所有线程栈看卡在哪个函数里。如果是用户态自旋或者死循环立刻能在栈上看到如果是内核态系统调用频繁比如epoll_wait被高频唤醒可以用strace -p -c统计系统调用次数。这套排查流程我在真实项目中救过好几次急。有一次线上CPU莫名飙高用gdb看线程栈发现大量线程阻塞在一个热点日志的字符串拼接上后来把日志从同步改成异步批量写CPU立刻降下来了。笔试里如果碰到类似题目你不光要说工具名称还要把“先看线程栈、再看系统调用、最后定位代码”的排查顺序讲清楚。5. 数据库与缓存玩家数据不是存进去就完事5.1 MySQL索引与事务读多写少的服主数据库游戏服务器笔试里的数据库题不会要求你写复杂的SQL优化但一定会问索引和事务隔离级别因为玩家数据的一致性太重要了。你应该能解释清楚InnoDB为什么用B树索引B树的非叶子节点不存数据单节点能存的key更多树更矮磁盘IO次数更少叶子节点通过链表相连范围查询非常高效。这正好匹配MySQL主键查询和范围扫描的常见模式。事务隔离级别也要能背下来更要会用读未提交会有脏读读已提交解决了脏读但可能不可重复读可重复读是MySQL默认级别通过MVCC实现避免不可重复读但可能产生幻读。游戏业务里充值订单、活动奖励发放这类操作必须严格保证一致性哪怕只是短暂的不一致都会引发玩家投诉甚至资损。我在项目里写发奖逻辑一定会加上事务和幂等校验防止玩家连点两次按钮被发两次奖励。这里给你一个答题套路不要只答概念要落到游戏场景。比如问“如何防止玩家购买道具时余额被扣成负数”你要答“使用UPDATE t_user SET money money - 100 WHERE uid ? AND money 100”配合受影响行数判断乐观锁和CAS思路都行。这才是游戏后端需要的数据库思维。5.2 Redis在游戏里的经典用法排行榜、在线状态、分布式锁Redis是游戏服务器开发绕不开的组件笔试卷几乎必考。它为什么适合游戏场景因为游戏数据的特点是读多写少、热点集中、需要极低的访问延迟Redis基于内存、单线程执行命令、支持丰富的数据结构完美匹配这些需求。具体到数据结构你要能举出游戏里的应用实例。ZSET可以做排行榜score是战力值每个玩家的排名用ZRANK直接查到更新用ZADDO(log n)复杂度。SET可以做在线状态维护玩家登录SADD掉线SREM在线人数SCARD。HASH可以存玩家基础属性避免频繁序列化整个对象。String可以配合SET NX EX实现分布式锁防止多服务器同时处理同一个玩家的请求。我自己的项目里排行榜就是ZSET加定时任务落库的组合Redis里维护实时榜单每5分钟把快照同步到MySQL这样即使Redis宕机重启后也能从MySQL恢复榜单。笔试卷上如果让你设计排行榜这个方案可以直接用。5.3 缓存穿透、击穿、雪崩的工程应对缓存相关的理论题笔试里问得也很细缓存穿透、缓存击穿、缓存雪崩分别是什么怎么解决。这三个概念很多人背得滚瓜烂熟但放到游戏场景里就说不利索我帮你串一下。缓存穿透是查一个不存在的key请求直接打到数据库解决方法是布隆过滤器或者缓存空值。在游戏里就是有玩家频繁查询一个不存在的角色ID。缓存击穿是某个热key过期瞬间大量请求同时打穿到数据库比如全区全服排行榜的key是热key一旦过期重建瞬间流量会压垮MySQL。解决方案是热key加互斥锁重建或者逻辑过期时间。缓存雪崩是大面积key同时过期导致数据库整体被打崩解决方案是过期时间加随机值避免同一时刻集体失效。这个考点我要特别提醒不要只答方案名称要能说出方案在代码里怎么落地。比如“缓存空值”要怎么设TTL太短没效果太长又浪费内存“互斥锁重建”要把谁加锁、谁等待、重建完怎么更新说明白。能落到这种颗粒度面试官才会相信你真的处理过线上问题。6. 业务场景题这是校招卷里区分度最大的部分6.1 排行榜系统设计从堆到ZSET再到定期落库前面聊算法时说了TopK和堆业务设计题里排行榜会再考一次但这次考的是工程方案不再只是算法。一个完整的排行榜系统要满足三个特性实时性玩家刷新分数后尽快看到新排名、稳定性服务重启后榜单不丢、扩展性支持多服、跨服、分组榜单。我的设计思路是这样内存里用ZSET承载热点数据key可以是“rank:server1”score是玩家分数member是玩家ID。玩家每次获得战力变更直接ZADD更新查询榜单用ZREVRANGE拿到前N名。为了稳定性每间隔一段时间做一次全量快照写入MySQL或者本地文件同时启动时先拉取上次快照再把日志期间的重放补上保证不丢数据。如果你有闲余时间还可以聊一聊“积分相同的排名怎么处理”。ZSET是按score升序再按字典序排序所以玩家分数一样时会按ID排序的这在业务上不一定正确。更好的做法是在score上构造一个复合排序值比如score 战力值 * 1e6 (999999 - 等级)这样战力大的排前面战力相同等级高的排前面。这类小细节很容易让面试官眼前一亮。6.2 聊天与消息广播按频道分发背后的设计取舍聊天系统几乎每个游戏都有笔试也特别喜欢出因为它涉及网络、数据结构、系统设计多个知识点的综合运用。题目通常这样出玩家发送一条世界聊天消息这条消息如何高效地广播给全服在线玩家最直接的想法是遍历所有在线连接把消息发给每个人但全服几万玩家时这个O(n)广播会产生大量无效IO而且不同频道、不同分线的玩家根本不需要收到消息。正确做法是设计频道订阅模型每个玩家在登录后把连接注册到对应的频道队列里比如“世界频道”“帮派频道”“附近频道”消息发送时只遍历目标频道的成员列表。我自己做过的聊天服大概是这样网关进程维护一张在线连接表逻辑进程维护频道成员表。玩家发消息时先由网关解析协议把消息投递到逻辑进程的频道队列逻辑进程根据频道类型找到目标连接列表再把消息通过网关下发。跨服聊天则需要通过中心消息队列中转类似“同城群聊”和“全国群聊”的区别。笔试答这道题时关键是体现出你考虑过“广播范围”的优化。如果你能说出“附近频道用AOI九宫格来圈定消息范围”“大型跨服频道用消息队列异步消费”这道题基本就稳了。6.3 AOI兴趣区域管理大型Online场景的同步武器如果笔试卷里有一道综合设计题AOI是一个非常常见的考点。AOI全称Area of Interest兴趣区域管理解决的是“如何让服务器只把某个玩家附近的动态信息同步给他”。最简单粗暴的做法是每次移动都广播全图所有人但一个大地图几千玩家时每个玩家每秒几次移动网络和CPU都会被打爆。比较经典的实现方案是九宫格把地图划分成固定大小的格子每个玩家根据坐标落在某个格子里需要同步时只取玩家所在格子周围 3x3 格子内的其他玩家进行视野进入/离开/移动的广播。我实现过一个简化版本格子大小是100x100超过这个距离的玩家互相看不到完美满足需求。除了九宫格还有十字链表方案按x坐标和y坐标分别用有序链表维护所有实体查询视野时在链表上双向遍历。九宫格适合人数多、地图广的场景十字链表适合实体分布不均匀的场景。笔试时你应该能概述两种方案并说出各自优劣不用写完整代码但要把同步流程说清楚进入视野发Enter、离开视野发Leave、位置变化发Move。6.4 一套最小可用的游戏服务器架构系统设计题的最后往往会让考生画一张整体的游戏服务器架构图或者用文字描述一台到多台服务器的部署方案。校招阶段不需要你设计微服务架构但你要能给出一个逻辑清晰的模块划分。最小可用架构一般长这样网关服负责客户端连接和协议解析只做转发不处理业务逻辑逻辑服承载玩家状态、玩法规则、排行榜等核心逻辑如果玩法有高频战斗或场景同步可以单独拆出战斗服或场景服数据服负责和MySQL、Redis交互提供异步存储能力跨服玩法还需要一个中心服来串联各个分服。我建议你画图时一定要画出数据流玩家操作 - 客户端 - 网关服 - 逻辑服 - 数据服 - MySQL/Redis再反向返回。这里有一个容易被忽略的点网关服和逻辑服之间怎么通信。一般用内网TCP或者消息队列消息结构要尽量轻量否则内网反而成为瓶颈。答系统设计题时能画出数据流并解释每层职责已经具备很强的说服力了。7. 复盘我踩过的坑和给你的答题建议7.1 校招笔试最容易犯的三个错误这么多年看下来校招笔试最常见的错误不是知识不会而是表达方式不对。第一个错误是“只写结论不写推导”。比如答TopK直接写“用小顶堆”没有讲为什么答粘包拆包直接说“加个长度字段”没有解释TCP是流协议。面试官看笔试卷想看到的是完整的思考链路而不是拍脑袋的答案。第二个错误是“代码不考虑边界”。很多人主逻辑写对了但k为0、数组为空、消息长度非法这些边界没处理。游戏服务器是7x24小时跑的线上数据千奇百怪一个越界就能导致整个进程崩溃。笔试时养成分段处理异常的习惯对后续工作也有益。第三个错误是“业务设计题答得太浅”。让你设计排行榜你就写“用Redis ZSET”——完了Redis挂了怎么办积分相同的怎么排跨服的怎么合榜分数刷得太快怎么异步落库这些问题都是真正上线前必须面对的。答业务题时把自己代入“我是这个系统的owner”多问自己几个“然后呢”深度自然就出来了。7.2 写在卷子之外的几句大实话如果你正在准备游戏服务器开发岗别把希望全押在刷题上笔试只是门槛真正让你拿到offer的是面试里表现出来的工程思维。我给你几个低成本高回报的练习方向自己写一个基于epoll的echo服务器把粘包拆包、消息分发、断线重连全跑通用Redis ZSET实现一个小排行榜加上持久化模拟一次CPU飙高的排查过程理解top、gdb输出里每一列是什么意思。这套组合拳打下来哪怕你没刷够题库面试聊到具体项目时也会比背书的人扎实得多。说句实在话网易这套2018年的笔试卷之所以现在还值得复盘就是因为里面的知识点到今天依然是游戏服务器开发的核心骨架。把这块骨头啃下来不管去哪个游戏公司你的底子都不会差。