校招未知部门 / 后端开发 / 多轮

[面试日期] 2026-08-25 [面试时长] 未知

[学校背景] 北京理工大学 | 985 [学历背景] 本科

[发布人] 面试之星官方收录

<h2>分享｜4年经验面快手电商，三轮技术面全过，HR面谈崩了</h2> 先交代背景：普通本科，Java后端，4年经验，上一家是某二线互联网公司，带过5人团队，负责过电商订单系统和库存系统的重构。快手电商业务增长很快，面试三轮技术面全过了，结果HR面薪资没谈拢，又重新投了另一个部门才OC。分享整个磕磕绊绊的过程。📌 第一阶段：一面差点挂（6月）一面（60分钟）——差点挂1️⃣ 项目深挖：你负责的电商订单系统，日订单量多少？QPS多少？怎么保证库存和订单的一致性？💡 思路参考：4年经验的面试，面试官默认你负责过核心系统。日均订单200万，峰值QPS约400。库存和订单一致性靠三层保障——Redis预扣库存（decr原子操作）、本地消息表（订单创建时写本地消息表）、定时对账（每日T+1对账）。重点说你作为负责人是怎么设计的，不是只参与了。2️⃣ 追问：“如果Redis预扣库存成功了，但订单创建失败了怎么办？”💡 思路参考：Redis预扣的库存需要有超时释放机制——如果订单创建失败或超时未支付（15分钟），定时任务扫描释放预扣库存。同时配合本地消息表，订单创建失败时发送回滚消息，消费者收到后释放Redis库存。核心是最终一致性+超时兜底。4年经验要能说出回滚消息的幂等设计——用订单ID去重，防止重复释放库存。3️⃣ 追问：“如果库存服务挂了，订单系统怎么降级？”💡 思路参考：库存服务挂了走降级——先查Redis缓存（库存数据预热到Redis），Redis也挂了则走数据库直查（牺牲性能保可用），同时触发告警通知运维介入。分层兜底——Redis第一层、DB第二层、本地缓存第三层（缓存热点商品库存，过期时间30秒）。4️⃣ JVM调优：G1 GC的调优参数和适用场景💡 思路参考：G1适合大堆内存（8GB以上）、对停顿时间有要求的场景。核心参数：<code>-XX:MaxGCPauseMillis=200ms</code>、<code>-XX:G1HeapRegionSize=16m</code>、<code>-XX:InitiatingHeapOccupancyPercent=45</code>。说一个真实调优案例：电商大促期间接口RT抖动，调大MaxGCPauseMillis从200ms到300ms，减少GC频率，RT稳定了。5️⃣ 手撕：实现一个支持分布式ID生成的发号器（Snowflake变种）💡 思路参考：41位时间戳+10位机器ID+12位序列号。核心难点：时钟回拨处理（记录上次生成时间戳，如果当前时间小于上次时间，等待或抛出异常）、机器ID分配（用ZooKeeper或Redis管理）。变种：可以根据业务场景调整位数分配（如订单量大的场景增加序列号位数）。一面面完感觉一般，项目答得还行，等了三天，居然过了。📌 第二阶段：二面三面全过了（7月）二面（60分钟）——过了1️⃣ 系统设计：设计一个支持亿级SKU的电商库存系统💡 思路参考：分库分表（按sku_id取模分16库64表，4年经验要能说清楚分库分表的依据——考虑未来3-5年数据增长，单表控制在1000万以内）+冷热分离（热数据存Redis+MySQL，冷数据归档到TiDB）+缓存设计（Redis缓存库存数据，Caffeine缓存热点SKU）。核心难点：库存扣减的原子性（Redis Lua脚本保证decr和判断的原子性）、库存扣减的顺序性（先扣Redis再扣DB，保证最终一致性）。库存扣减失败的处理：失败后发送MQ回滚消息，释放已扣减的Redis库存。2️⃣ 追问：“分库分表后，跨库库存查询怎么处理？”💡 思路参考：SKU ID生成时嵌入库表路由信息（如雪花算法中嵌入分库分表位），解析后可路由到具体分片。对于批量查询（如购物车批量查库存），用ES做异构索引——库存数据通过Canal同步到ES，批量查询走ES。重点说出方案取舍——ES索引延迟在1秒以内可接受，最终一致性。3️⃣ 线上大规模故障排查💡 思路参考：说一个真实的P0级事故。某次电商大促，流量比预估高了5倍，Redis连接池被打满，大量接口超时。排查过程：看监控大盘确认故障范围→查Redis连接池状态（打满）→看慢查询（发现热Key问题，某个爆款SKU被大量请求）→紧急扩容Redis集群（增加分片）→恢复。事后复盘：热Key没有做分散处理、压测没覆盖峰值场景、应急预案不完善。三面（交叉面，70分钟）——过了1️⃣ 系统设计：设计一个电商秒杀系统💡 思路参考：流量层层削峰——CDN加速静态资源、Nginx限流（漏桶算法，单IP限制10QPS）、MQ削峰填谷（将请求先写入消息队列，消费者按能力处理）、Redis预扣库存（decr原子操作防超卖）、分布式事务保证最终一致性（TCC）。每一层都要说清楚怎么保证系统不崩。4年经验要能说出每层的瓶颈和扩容方案——Nginx层水平扩展、MQ分区扩容、Redis集群分片扩容。2️⃣ 追问：“如果秒杀库存是100，但有10000人同时抢，Redis扛得住吗？”💡 思路参考：Redis单机QPS 10万+，10000人完全扛得住。真正的瓶颈在数据库——通过MQ削峰，把写DB的请求从瞬时10000降到每秒几百。同时做热点Key分散——将库存分散到多个Redis key上（如stock_1、stock_2），随机路由，避免单个热Key打爆Redis节点。HR面（30分钟）——挂了期望薪资报了35%涨幅，HR说“这个岗位预算有限，只能给到20%涨幅”。没谈拢，挂了。📌 第三阶段：重新投递，四面终于OC（8月）挂了之后重新投了另一个部门（电商中台方向），这次HR面学乖了，先问薪资范围再报期望。最终OC。📌 声明<blockquote>以上思路参考来自 <code>"面题鸭🦆"</code> 各岗位专属考题的考点方向</blockquote>📝 复盘快手电商社招4年经验的面试，考的是三件事：<ol><li>能不能独立设计系统（库存系统、秒杀系统、分库分表）</li><li>线上出事了能不能扛住（大规模故障排查、热Key处理）</li><li>能不能讲清楚为什么（每个技术选型都有明确的理由和取舍）</li></ol>🎯 后来怎么调整的？HR面挂了之后复盘发现，技术准备没问题，但HR面完全没策略，薪资谈判一上来就报期望涨幅，没给自己留余地。后来在 <code>"面题鸭🦆"</code> 上刷了一遍电商方向的JD专属出题，发现系统设计、分布式事务、热Key处理这些方向覆盖得很全。每面一家之前针对性刷一遍，面试时心里有底很多。<a>#发面经攒人品#</a><a>#我的求职进度条#</a><a>#怎么给家人解释你的工作？#</a><a>#芯原微电子（上海）股份有限公司笔试#</a><a>#网易求职进展汇总#</a>

AI 推荐面试题

校招 未知部门 / 后端开发 / 多轮

校招未知部门 / 后端开发 / 多轮