腾讯游戏后端一面
一个半小时纯拷打场景和实操(藤子太哈人了)
总的来说，这次面试体验非常好，面试官虽然言辞犀利但还算温柔，愿意引导你进行操作，可以学习到很多知识，特别是一些中间件的底层逻辑，让我真正见识了后端的深似海，但我是第一次在面试中遇到需要实操的场景，非常紧张，终端实操和代码编写都写的不好，只完成了一部分，幸运的是，面试官人特别好，会议结束后就给过了，并鼓励我后面继续加油！
问项目：
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的键值存储） │ │ └─ 连接层：连接池 + 超时管理 + 心跳检测#日常实习#
