腾讯游戏后端一面

一个半小时纯拷打场景和实操(藤子太哈人了)

总的来说，这次面试体验非常好，面试官虽然言辞犀利但还算温柔，愿意引导你进行操作，可以学习到很多知识，特别是一些中间件的底层逻辑，让我真正见识了后端的深似海，但我是第一次在面试中遇到需要实操的场景，非常紧张，终端实操和代码编写都写的不好，只完成了一部分，幸运的是，面试官人特别好，会议结束后就给过了，并鼓励我后面继续加油！

问项目：

1、大文件上传怎么做的

2、某个分片上传时间超过了24小时，因此被定时任务清理掉了，应该怎么办？

修改清理触发条件/校验文件完整性，断点续传重新触发

3、合并文件时java的RandomAccessFile底层是如何实现的

4、写文件时，如何确定某个块是否写入成功了呢

5、如何判断整个文件上传成功的

6、分布式锁的实现

7、redis宕机了怎么办

Redis 宕机的处理逻辑是「先检测→再降级→后容灾」：

快速检测 Redis 状态，避免接口超时阻塞；
优先保证业务可用，通过「本地锁 / 数据库唯一索引」兜底去重能力；
长期通过「主从 / 集群」提升 Redis 可用性，从根本上减少宕机概率；
故障后复盘优化，形成闭环。

8、如果redis上了主从，主节点上万锁，这时候宕机了，宕机前给client1发送了锁，client1变成了主节点，怎么办(Redis 主从架构下主节点宕机时，锁的「数据同步延迟」+「主从切换」导致的锁有效性问题)

方案 1：使用 Redis Redlock（红锁）—— 分布式锁的标准解决方案

Redlock 是 Redis 官方推荐的解决主从锁丢失的方案，核心逻辑是「多实例独立加锁，超过半数成功才算锁生效」，彻底摆脱单主从架构的同步问题。

实现逻辑

部署至少 3 个独立的 Redis 主节点（无主从关系，避免单集群故障）；
加锁时，向所有 Redis 节点发送SET key value NX EX命令；
只有「超过半数节点（≥2 个）加锁成功」，且总耗时≤锁过期时间的 1/3，才算最终加锁成功；
解锁时，向所有节点发送 DEL 命令删除锁

9、噩梦的开始，发了个redis的源码压缩文件，要求在linux（mac）环境上实操，面试官更改了一些源码，跑不通了，需要自行在linux环境中编译redis源码，检查报错后，通过测试查出是哪些命令跑不通，定位到具体的源码文件，找出错误原因并修改源码后重新编译通过即可（总共五个错误，吭哧费劲半天搞定了一个，剩下的没时间就让面完有时间自己做了）

10、介绍redis RESP

11、代码题：用Java编写一个简单的RESP规则的编码器和解码器，包括且不限于简单字符串，错误，整数，批量字符串和数组，大约就是写五个函数，再封装一个concat函数（给我整蒙了，我寻思不都是力扣嘛）还好不难，但花了很多时间去理解这个东西，没见过，根本不知道想让我做什么，写了两个之后发现就是做字符串的拼接

12、写完让讲一下RESP对数组编码的思路，以及解码器的思路

13、如果让你实现redis的cs架构，你如何设计服务端的架构(脑子懵了，仿照MySQL的回答，面试官似乎很欣慰)

服务端（Server）                                │
│ ├─ 网络层：Acceptor（监听端口）+ Handler（处理连接） │
│ ├─ 协议层：RESP解码器（解析客户端命令）+ 编码器（响应） │
│ ├─ 命令层：命令解析 + 命令执行器（如SET/GET/DEL）    │
│ ├─ 存储层：内存哈希表（模拟Redis的键值存储）         │
│ └─ 连接层：连接池 + 超时管理 + 心跳检测

#日常实习#