FunPlus 后台开发 秋招一面

《面试题目》

1. 经营游戏中用户升级建筑，每次升级需要一定时间，可以用加速卡加速或直接取消升级，设计这个建筑的数据结构；升级完成时如何通知用户？
2. 双 11 买东西，怎么设计支撑高并发？
3. 深分页怎么解决？
4. HTTP 整体说一下，传输过程中怎么保证数据完整？
5. TCP 校验和是怎么计算的，校验和正确能保证数据完整吗？
6. 一些使用 AI 的问题
7. 与游戏相关的问题：帧保持一致

《参考解析》

建筑升级的数据结构：核心是把「升级」建模成一个带起止时间的任务，而不是给建筑存一个状态字段。每座建筑存 {id, level, upgradeStartTs, upgradeDurationSec, speedUpSec, status}，状态的判定由 now 与起止时间算出来，这样可避免定时器精度问题。加速卡作用于 speedUpSec，取消则把状态清回空闲（已消耗的加速卡按规则决定是否返还）。完成通知有两条路：一是写一张「到期任务表」由后端定时器（时间轮 / 延时队列 / Redis ZSet 按到期时间排序）扫描触发；二是客户端拉取时按 now 自行判定并在本地定时刷新。生产上通常两条都做——服务端用分片的时间轮扫到期的任务，客户端用本地倒计时做即时反馈，服务端结果为准，避免客户端改时间作弊。要提一句并发安全：用户连点加速和取消，用 Redis 原子操作或数据库乐观锁（版本号）保证只结算一次。

双 11 高并发设计：按流量链路分层答。接入层：CDN 静态化、限流（令牌桶 / 漏桶）、Nginx 或网关层做黑名单与防刷。应用层：无状态化方便水平扩容、热点数据提前预热、把非核心链路降级（推荐、积分、弹窗）。缓存层：Redis 挡读、多级缓存（本地 Caffeine + Redis）、热点 key 打散、缓存空值防穿透、加随机过期防雪崩、互斥锁或逻辑过期防击穿。库存扣减是核心：Redis + Lua 原子预扣、消息队列异步落库、库存分段（把 1000 件拆成 10 段放到不同 key）降低单 key 争抢。数据库层：分库分表、读写分离、最终一致性（本地消息表 / 事务消息 / 定时对账补偿）、不允许超卖就用唯一索引或乐观锁兜底。最后补一句容量与压测：先按峰值 QPS 估算，再全链路压测，别等大促才发现瓶颈。

深分页：limit 1000000, 20 之所以慢，是因为 MySQL 要先扫过并丢弃前 100 万行。三种解法：一是游标 / seek 法，记住上一页最后一个 id，改成 where id > last_id order by id limit 20，翻页不再随深度变慢，代价是不能跳页；二是延迟关联，先在覆盖索引上分页拿主键再回表（select * from t join (select id from t order by id limit 1000000,20) x using(id)）；三是业务上限制最大页数，或者用搜索引擎（ES 的 search_after、scroll）承接深度翻页。

HTTP 与 TCP 校验和：HTTP 是应用层文本协议，请求由请求行、头、空行、体组成，响应同理；HTTP/1.1 默认长连接、有队头阻塞，HTTP/2 做多路复用、头压缩、二进制分帧，HTTP/3 走 QUIC。传输完整性靠分层保障：TCP 有首部校验和、序列号与确认机制、超时重传，保证「到达且有序」；TLS 层有 MAC/AEAD 保证不被篡改；应用层可以再加内容哈希（比如文件下载的 md5/sha256）或 ETag 做端到端校验。TCP 校验和的计算是：把首部（校验和字段置 0）和数据一起按 16 位分组做反码求和，再取反，接收端同样计算并对比。要注意它只能发现错误、不能保证完整——校验和是 16 位弱校验，理论上存在碰撞，而且它只覆盖单段，无法防止中间人篡改。所以「校验和正确」只说明这一跳大概率没传错，真正要防篡改和确认完整，需要 TLS + 应用层哈希或签名。

这一轮的特点：FunPlus 作为游戏公司，题目明显偏「场景设计 + 网络基础」，八股问得少，几乎是让你现场做设计题。这类题的评分点不在标准答案，而在你有没有把约束条件问清楚、方案有没有取舍、边界（并发、幂等、异常补偿）有没有覆盖到。作者提到最后有个「帧保持一致」的题目没答上来，属于游戏方向的知识盲区，投游戏公司前补一下帧同步 / 状态同步、延迟补偿这类概念会明显加分。