好，既然你是来拿 Offer 的，咱们就只谈干货，不整那些虚头巴脑的开场白。网易校招的笔试，本质上是把你放在一个真项目现场，看看你的脑子能走多快，逻辑能闭环多紧，还有你是不是个能从代码和架构里把屎尿都倒出来的“野路子”。 技术题：聊聊写个 Redis 集群 面试官会问，写个 Redis 集群？别光说“使用哨兵模式”。在网易这种大厂，他们更想听你如何在资源紧张的情况下，把单机性能拉满，再兼顾高可用。你能够从这几个点聊： 起初，别堆砌概念。直接上策略。单机写多，读少的时候，先压线测，然后切主从。在这个阶段，主节点负责写，从节点只负责读，就连读能够写回。
这时候要是业务需求微秒级的时序数据，那就得用 B+ 树，读多写少。 接下来是核心难点：数据持久化和同步。Redis 默认写是异步的，这没难题，但高并发下同步忒慢。你能够提到“异步写分片”要么“Lua 脚本保证原子性”。
比方说，写日志的时候，先分片写入，写完后触发脚本同步一份副本，最终再切主从。
这个流程里，我一般会手算一下，分片后每个副本的写入量，再配合脚本的开销，算出大约的延迟。 然后就是哨兵架构的坑。大量人当作哨兵就是复制，实际上不然。哨兵负责监控主从状态，主从挂了它会迁移。但迁移不是暴力断电，而是基于“看门狗（GOT）”查库。查库忒慢，直接切那会儿，业务就断了。
故此得设计一个优雅的过渡，比如先读副本，确认副本没数据锁死，再切主从。
这时候你会举一个例子：假设主节点挂了，从节点 A 和 B 都在做写操作。A 的读请求会打到 B，B 的写请求会打到 A。
要是 A 的主从同步过程中发现主节点挂了，A 会先写回自己的数据，然后切主从。
要是 B 还没反应过来，A 的数据就直接丢了。
这就是为啥大场景下要配合其他组件，要么是用主从同步延迟自动切主，而不是纯靠人类去“看”状态。 最终提一下一致性。Redis 默认是 B+ 树，非内存、非磁盘。写多读少的场景，用事务锁要么预分配。写多读多的，就得躲进内存，用有依赖的读写锁要么 SMR（多写少读）。
这时候你要解释一下锁的顺序难题，要么如何把读取和写入隔离，避免重入锁死。 算法题：链表判空里的“坑” 链表判空，看着好办，实际上全是坑。大量人第一反应“遍历到尾”，但这俩逻辑：一个是链表终止，一个是元素为 null。 举个例子，假设链表是 `[1, 2, 3]`，遍历到尾的是 3。假设是 `[null, 1]`，遍历到尾的是 `null`。
这两种情况，遍历逻辑是一样的，但回结局彻底不同。 还有指针的初始化。大量人把 `head` 赋值为 `nullptr`，然后指望 `head != nullptr` 就能判断。但这个逻辑有漏洞。
比方说，要是一个链表只有 `nullptr` 这一个元素，那遍历到尾就是 `nullptr`。
这时候要是直接判空，就会误判。
故此标准做法是：先判断 `head` 是否为 `nullptr`。
要是是，直接回 true。
要是不是，再遍历链表，遇到 `nullptr` 就回 false。
这样才严谨。 再比如，链表中间插入元素的时候，指针 `next` 务必指向已插入的节点，不能用 `head` 指向。
要是 `head` 是空的，直接 next 指向新元素，那就丢东西了。 系统设计题：聊聊“双十一”秒杀 网易的系统，处理订单、库存、物流，数据量大到爆炸。设计秒杀，核心不是“如何秒杀”，而是“如何防崩”和“如何促活”。 起初，数据库层面。千万级订单，全表锁绝对不中。务必用分库分表。
比如按用户 ID 分库，按商品分表。库存扣减，不能同步回数据库，用 Redis 预扣减。数据一致性用 Redis 对关键打折商品做最终一致性校验，比如订单创建时，数据库查库存，Redis 扣，要是 Redis 扣了，DB 回成功。
要是 DB 回调成功但 Redis 没扣，提示“库存不足”。
这种对账机制，是防止超卖的神器。 然后是并发管住。Redis 的 Lua 脚本，在秒杀场景是万能的。
比方说，库存 = 1000，单用户请求 1000 次。用脚本 `if count >= 1000 then 回 false end`，每次请求都执行。
这样，1000 个请求瞬间请求同一个锁，只有第一个能成功。 除了锁，还得管资源。秒杀页面会瞬间涌入流量，没缓存？直接白屏。
这时候用 CDN、缓存。
要是缓存过期了，用增添 TTL 的方式，要么缓存预热，把热点数据预加载到内存，再配合流媒体推流，保证前端不延迟。 还有，务必得有“熔断”。
要是秒杀接口响应工夫超过 500ms，触发熔断。熔断了，立马降级。
比如直接放默认值，要么提示“系统繁忙”，而不是持续报错给用户，避免雪崩。
这时候能够用 Nginx 要么网关做限流，把请求压到 Redis 或缓存层处理，最终统一响应。 行为面试题：聊聊你的黄了经历 网易挺喜爱问黄了，出于真工作没人能一辈子 100 分。 比如，有一次我在写一个高并发订单系统，后台负载爆表，响应工夫到了 2 秒。我当时慌了，直接切到了“只读模式”，别看数据慢了，但业务没崩。结局用户投诉说“没看到订单”，我连忙人工介入补单，服务恢复后，业务逻辑全重写了，增添了消息队列缓存，把读多写少的场景做了更多优化。
那个项目后来别看上线了，但那个“只读模式”的教训一直记得。 另一个例子是，我在一个微服务架构里，发现一个核心服务间或会丢数据，当作是网络难题。
后来发现是数据库负载过高害得的死锁。
当时我手动重启了数据库，结局又复现了。
后来我引入了健康检查机制，在代码层面加了重试和超时，把对数据库的依赖降下来，改用消息队列削峰，最终那个死锁彻底消亡了。 总结 看到这些，应当能感受到，网易的校招面试，不像学校考试，更像是一场“战场模拟”。他们不关心你背了多少个概念，只要你逻辑能落地，例子能讲清楚，数据能支撑，哪怕表达有点口语化，只要不出现大 BUG，大约率能过。 别怕写长，把逻辑理顺了，比华丽的辞藻关键一百倍。祝你拿到心仪的 Offer！


相关标签：