美团一面，有点难度。

一位粉丝朋友分享了最近参与美团民宿旅游业务线的一面的经历，全程约1小时，面试官围绕高并发、分布式事务、性能优化等高频考点展开追问，问题密集且注重落地细节。以下是完整问题整理+回答思路+扩展解析，助你避坑！

---

一、项目与高并发场景

1. “介绍一个项目中的难点，并说明QPS和用户量峰值？”

• 回答示例：
  • 项目背景：民宿节日大促活动，瞬时流量激增（如春节、国庆），用户抢购特价房源。
  • 核心数据：
    • QPS峰值：约8000（主要集中在活动开始前5分钟）；
    • 用户量峰值：单日活跃用户12万，抢购时段并发用户3万+；
  • 难点：
    • 库存超卖：多节点并发扣减库存的原子性问题；
    • 系统崩溃风险：流量洪峰导致服务雪崩；
    • 响应延迟：用户提交订单后长时间卡顿。

2. “高并发下如何设计抢购功能？异步订单处理具体做了什么？”

• 详细方案：
  • 异步削峰：
    1. 用户点击下单后，前端直接返回“排队中”状态，请求进入MQ队列（如RocketMQ）；
    2. 后端消费者分批拉取消息，通过Redis Lua脚本原子性扣减库存；
    3. 库存扣减成功则生成订单，失败则MQ重试（限制最大重试次数，避免死循环）。
  • 防超卖补充：
    • 预扣库存：活动开始前预热Redis，库存按房源ID分片存储；
    • 库存回滚：用户15分钟内未支付，系统自动释放库存（通过延迟队列实现）。

3. “如何用Lua脚本保证不超卖？限流除了令牌桶，还有其他方案吗？”

• Lua脚本示例：

  local stock = redis.call('get', KEYS[1]) -- 获取库存  
  if tonumber(stock) > 0 then  redis.call('decr', KEYS[1])          -- 扣减库存  return 1 -- 成功  
  else  return 0 -- 失败  
  end  
  

• 限流方案对比：
  • 令牌桶（Guava RateLimiter）：允许突发流量（如预热期积攒令牌），适合秒杀场景；
  • 漏桶：恒定速率处理请求，保护下游系统（如数据库）；
  • 滑动窗口（Sentinel）：实时统计时间窗口内请求量，精准控制流量。

4. “Redis集群用了多少机器？选举机制和设计模式如何应用？”

• 集群架构：
  • Redis Cluster：共6主6从，每个分片承载约1.3万QPS；
  • 选举机制：主节点故障时，从节点通过Raft协议投票选举新主；
• 设计模式实践：
  • 策略模式：根据不同活动类型（如限时折扣、拼团），动态选择库存扣减策略；
  • 观察者模式：订单状态变更时，通知营销系统（发放优惠券）、日志系统（记录行为）。

---

二、分布式事务与锁

5. “项目中分布式事务如何实现？2PC和TCC有什么区别？”

• 最终一致性方案：
  1. 下单主事务：本地事务中插入订单记录，同时写入消息表（状态为“未发送”）；
  2. MQ异步通知：事务提交后，扫描消息表发送MQ（若发送失败，定时任务补偿）；
  3. 库存服务消费：保证幂等性（通过唯一订单ID去重），扣减真实库存。
• 方案对比：
  • 2PC：
    • 优点：强一致性（如XA协议）；
    • 缺点：同步阻塞（协调者单点问题）、MySQL性能瓶颈；
    • 适用场景：银行转账、资金扣减。
  • TCC：
    • Try阶段：预留资源（如冻结库存）；
    • Confirm/Cancel阶段：确认或释放资源；
    • 缺点：业务侵入性强，需自行实现回滚逻辑。

6. “分布式锁除了Redis，还有哪些实现方式？”

• Redis分布式锁陷阱：
  • 误释放锁：A线程超时导致锁过期，B线程加锁后A完成操作误删B的锁；
  • 解决方案：value存储唯一ID（如UUID），删除时校验归属；
• ZooKeeper方案：
  • 创建临时有序节点，最小节点获得锁；
  • Watch机制监听前序节点释放，避免惊群效应；
  • 优点：无超时问题；缺点：性能低于Redis。

---

三、性能优化与问题排查

7. “慢SQL优化时，执行计划要关注哪些参数？”

• EXPLAIN关键字段：
  • type：const（主键查询） > range（索引范围扫描） > ALL（全表扫描）；
  • rows：预估扫描行数，越大性能越差；
  • Extra：
    • Using filesort：需优化排序字段索引；
    • Using temporary：用了临时表，常见于GROUP BY未走索引。
• 案例：某查询type=ALL且rows=50w，通过添加(user_id, status)联合索引，耗时从2s降至50ms。

8. “线程池参数怎么设置？拒绝策略有哪些？”

• 参数设定公式：
  • 核心线程数：CPU密集型任务 = CPU核数 + 1；IO密集型任务 = CPU核数 * 2；
  • 队列容量：根据任务特性，内存敏感场景用同步队列（如SynchronousQueue），允许丢任务；
• 拒绝策略：
  • AbortPolicy：直接抛异常（默认策略，需做好降级）；
  • CallerRunsPolicy：由提交任务的线程执行（减缓提交速度）；
  • 自定义策略：记录日志并触发告警（如钉钉通知研发）。

9. “线上突发CPU飙升，如何快速定位问题？”

• 排查流程：
  1. TOP命令：找到占用CPU最高的进程和线程；
  2. 线程转储：jstack pid > thread.log，分析线程状态（如死锁、无限循环）；
  3. Arthas工具：
     • thread -n 3：查看最忙的3个线程；
     • watch com.example.Service method '{params,returnObj}'：动态监控方法入参和返回值；
  4. 案例：某次CPU 100%因日志组件异步队列阻塞，改用Disruptor框架后解决。

---

四、算法题扩展

10. “接雨水除了双指针，还有其他解法吗？”

• 暴力解法：对每个柱子，找左右最大高度，时间复杂度O(n²)；
• 动态规划：预处理左右最大值数组，时间O(n)，空间O(n)；
• 单调栈：维护递减栈，计算凹槽面积，时间O(n)，空间O(n)；
• 面试官意图：考察对多种解法的理解和时间/空间复杂度权衡。

11. “合并回文链表时，如果链表长度差很大，如何优化？”

• 优化思路：
  • 若链表A长度远大于B，先遍历A到中间节点，再与B合并，减少反转次数；
  • 空间换时间：将链表B全部存入List，逆序后合并（需权衡内存占用）。

---

五、总结与避坑指南

1. 高频考点总结：

   • 高并发：Redis+Lua+MQ三板斧，限流算法必须手写伪代码；
   • 分布式事务：至少掌握2种方案（如最终一致性+TCC），并能对比优缺点；
   • 性能优化：从SQL到JVM调优，需结合具体数据说明优化效果。

2. 避坑建议：

   • 忌空谈理论：所有方案必须关联项目场景（如“为什么不用2PC？因为QPS要求高，事务管理器可能成为瓶颈”）；
   • 准备项目图谱：提前画好系统架构图、表结构设计，应对“集群怎么部署”类问题；
   • 算法刷题技巧：面试前手写高频题（如链表、二叉树、双指针），重点注释时间/空间复杂度。

---

最后：若你想进一步深入某个技术点（如Redis集群选举源码、TCC完整实现），欢迎留言！下期可针对性拆解🔥

欢迎关注 ❤

我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。

没准能让你能刷到自己意向公司的最新面试题呢。

感兴趣的朋友们可以加我：wangzhongyang1993，备注：面试群。