美团校招后端面经：Redis、线程池与缓存策略深度解析

Redis的数据结构有哪些？各自适用场景是什么？

回答思路

Redis数据结构是美团后端必考题，美团业务（外卖调度/优惠券/排行榜）大量依赖Redis，结合业务场景回答更加分。

1. 列出5种基础结构：String/List/Hash/Set/ZSet。
2. 每种说清楚：底层实现 + 适用场景 + 美团业务案例（如能结合）。
3. 加分项：提及HyperLogLog（UV统计）、Bitmap（签到）、Geo（配送距离）。

回答示例

Redis有5种核心数据结构：

• String（字符串）：底层是SDS（简单动态字符串）。
  • 适用场景：缓存对象（用户信息JSON序列化后存储）、计数器（点击量、库存扣减，利用INCR原子性）、分布式锁（SET NX EX）。
  • 美团业务案例：美团外卖中的优惠券库存扣减就是典型的String+INCR应用。
• List（列表）：底层是quicklist。
  • 适用场景：消息队列（LPUSH + BRPOP阻塞消费）、最近N条数据（LRANGE + LTRIM控制长度）。
• Hash（哈希）：底层是listpack（小数据量）或hashtable。
  • 适用场景：存储对象字段（用户信息，避免JSON频繁序列化反序列化）、购物车（HSET user:cart item_id quantity）。
• Set（集合）：底层是listpack或hashtable，支持交集/并集操作。
  • 适用场景：去重（已消费用户ID集合）、共同好友（SINTER）、抽奖（SRANDMEMBER随机取）。
• ZSet（有序集合）：底层是listpack或skiplist+hashtable。
  • 适用场景：排行榜（ZADD + ZREVRANGE）、延迟队列（score=执行时间戳，定时ZRANGEBYSCORE轮询）。
  • 美团业务案例：美团的商家评分榜、用户积分排行榜都是ZSet的典型应用。

加分项：

• Bitmap：用于签到打卡，1亿用户的全年签到数据只需约4.5MB。
• HyperLogLog：UV（独立访客）统计，误差率约0.81%，内存占用极低。
• Geo：存储地理坐标，支持GEODIST计算两点距离，用于外卖骑手配送范围计算。

线程池的核心参数有哪些？如何合理配置？

回答思路

美团高并发业务场景下线程池是重要知识点，要说清楚参数含义 + 拒绝策略 + 配置方法论。

1. 7个核心参数：corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。
2. 执行流程：核心线程 → 队列 → 最大线程 → 拒绝策略。
3. 配置原则：CPU密集型 vs IO密集型。

回答示例

线程池的7个核心参数：

参数	说明
corePoolSize	核心线程数，长期保留不销毁
maximumPoolSize	最大线程数
keepAliveTime	非核心线程的空闲存活时间
unit	keepAliveTime的时间单位
workQueue	任务等待队列（ArrayBlockingQueue/LinkedBlockingQueue/SynchronousQueue）
threadFactory	线程工厂，可自定义线程名（便于排查问题）
handler	拒绝策略（AbortPolicy/CallerRunsPolicy/DiscardPolicy/DiscardOldestPolicy）

执行流程：提交任务 → 核心线程未满则新建核心线程 → 核心线程满了则入队列 → 队列满了则新建非核心线程（不超过max）→ 超过max则触发拒绝策略。

配置原则：

• CPU密集型（计算、加密）：核心线程数 = CPU核心数 + 1，避免过多线程上下文切换。
• IO密集型（数据库、HTTP调用）：核心线程数 = CPU核心数 × 2，或根据线程数 = CPU核心数 / (1 - IO等待时间占比)计算。

美团业务案例：美团外卖订单推送业务属于IO密集型，大量时间等待HTTP响应，因此线程池配置较大。

如何设计一个高并发下的优惠券秒杀系统？

回答思路

这是美团最高频的系统设计题，直接关联业务。要从限流 → 库存设计 → 防超卖三个层面展开。

1. 前端限流：按钮置灰、验证码、排队队列。
2. 后端限流：网关层限流（令牌桶）、接口幂等性。
3. 库存设计：Redis预扣库存，异步落库。
4. 防超卖：Redis Lua脚本原子扣减，避免并发竞争。
5. 最终一致性：MQ异步处理订单，失败补偿机制。

回答示例

整体设计分三层：

第一层：流量控制

• 前端按钮点击后置灰（防重复点击）、滑块验证码（防机器人）。
• Nginx限制单IP请求频率（令牌桶算法，如每秒最多5次）。
• 网关层对接口进行QPS限流（Sentinel/Hystrix）。

第二层：库存扣减（核心）

• 活动开始前，将优惠券库存量预加载到Redis：SET coupon:1001:stock 1000。
• 用户点击领券时，使用Lua脚本原子执行：

  -- 先判断库存，再扣减，保证原子性
  local stock = redis.call('GET', KEYS[1])
  if tonumber(stock) <= 0 then
      return 0
  end
  redis.call('DECR', KEYS[1])
  return 1
  

  • 优点：保证了检查库存和扣减库存的原子性，避免超卖。
• 扣减成功后，将用户ID和优惠券ID发送到消息队列（Kafka/RocketMQ）。

第三层：异步处理与最终一致性

• 消息队列：MQ消费者异步处理消息，进行数据库落库（记录用户领券信息）。
• 幂等性：消费者处理消息时，通过订单号或唯一请求ID保证幂等性，防止重复发券。
• 失败补偿：如果MQ消费失败或数据库写入失败，进行重试机制。若重试仍失败，则记录日志并触发告警，人工介入处理，或通过定时任务扫描未处理订单进行补偿。
• 库存回补：如果用户在规定时间内未支付或取消订单，通过定时任务或MQ消息回补Redis库存。

LRU缓存淘汰算法的实现原理？

回答思路

LRU是面试高频题，需要说清楚数据结构的选择（哈希表+双向链表）以及核心操作（get/put）的实现。

1. 数据结构：HashMap + DoubleLinkedList。
2. 核心操作：
   • get(key)：如果存在，将节点移到链表头部；如果不存在，返回-1。
   • put(key, value)：
     • 如果key已存在，更新value，并将节点移到链表头部。
     • 如果key不存在：
       • 如果缓存已满，淘汰链表尾部节点。
       • 创建新节点，添加到链表头部。

回答示例

LRU（Least Recently Used）缓存淘汰算法的核心思想是：如果一个数据在最近一段时间没有被访问，那么在将来它被访问的可能性也很小。因此，当缓存空间不足时，优先淘汰最久未被使用的数据。

实现原理：

LRU算法通常通过结合哈希表（HashMap）和双向链表（DoubleLinkedList）来实现。

1. 哈希表（HashMap）：
   • 存储key到链表节点Node的映射。
   • 作用：实现O(1)时间复杂度的查找操作，快速定位缓存中的数据。
2. 双向链表（DoubleLinkedList）：
   • 链表中的每个节点存储key和value。
   • 链表头部（head）表示最近使用的元素，链表尾部（tail）表示最久未使用的元素。
   • 作用：
     • 当数据被访问时，可以O(1)时间将其从链表中移除并移动到头部。
     • 当缓存满时，可以O(1)时间淘汰尾部节点。

核心操作实现：

• get(key)操作：

  1. 通过HashMap查找key对应的节点。
  2. 如果节点不存在，返回-1。
  3. 如果节点存在，说明该数据被访问了，需要将其从当前位置移除，并移动到双向链表的头部（表示最新使用）。然后返回节点的值。

• put(key, value)操作：

  1. 通过HashMap查找key对应的节点。
  2. 如果节点已存在：更新节点的值，并将其移动到双向链表的头部。
  3. 如果节点不存在：
     • 检查缓存容量：如果当前缓存大小已达到容量上限，需要淘汰最久未使用的元素。即移除双向链表尾部的节点，并从HashMap中删除对应的映射。
     • 添加新节点：创建一个新的节点，将其添加到双向链表的头部，并在HashMap中建立key到新节点的映射。

Java代码示例：

import java.util.HashMap;
import java.util.Map;

public class LRUCache {

    private Map<Integer, Node> cache;
    private DoubleLinkedList list;
    private int capacity;

    public LRUCache(int capacity) {
        this.capacity = capacity;
        this.cache = new HashMap<>();
        this.list = new DoubleLinkedList();
    }

    public int get(int key) {
        if (!cache.containsKey(key)) {
            return -1;
        }
        Node node = cache.get(key);
        list.moveToHead(node); // 访问后移到表头
        return node.value;
    }

    public void put(int key, int value) {
        if (cache.containsKey(key)) {
            Node node = cache.get(key);
            node.value = value;
            list.moveToHead(node); // 更新后移到表头
        } else {
            if (cache.size() >= capacity) {
                Node tail = list.removeTail(); // 淘汰最久未使用的（表尾）
                cache.remove(tail.key);
            }
            Node newNode = new Node(key, value);
            cache.put(key, newNode);
            list.addToHead(newNode); // 新增节点添加到表头
        }
    }

    // 内部类：双向链表节点
    private static class Node {
        int key, value;
        Node prev, next;

        Node(int k, int v) {
            this.key = k;
            this.value = v;
        }
    }

    // 内部类：双向链表
    private static class DoubleLinkedList {
        Node head, tail; // 哑头和哑尾，表头=最新，表尾=最旧

        DoubleLinkedList() {
            head = new Node(0, 0); // 哑头节点
            tail = new Node(0, 0); // 哑尾节点
            head.next = tail;
            tail.prev = head;
        }

        // 将节点添加到链表头部
        void addToHead(Node node) {
            node.next = head.next;
            node.prev = head;
            head.next.prev = node;
            head.next = node;
        }

        // 移除指定节点
        void remove(Node node) {
            node.prev.next = node.next;
            node.next.prev = node.prev;
        }

        // 移除链表尾部节点（最久未使用的）
        Node removeTail() {
            Node node = tail.prev;
            remove(node);
            return node;
        }

        // 将节点移动到链表头部
        void moveToHead(Node node) {
            remove(node);
            addToHead(node);
        }
    }
}

MySQL主从同步原理是什么？如何解决主从延迟问题？

回答思路

美团数据库高可用必备知识，主从延迟是大规模读多写少场景的核心问题。

1. 主从同步原理：Binlog → Dump线程 → IO线程 → RelayLog → SQL线程回放。
2. 主从延迟原因：从库单线程回放慢、从库机器负载高、大事务导致从库延迟。
3. 解决方案：并行复制（GTID/MTS）、读写分离+延迟路由、应用层判断延迟。

回答示例

MySQL主从同步原理（基于Binlog）：

1. 主库记录Binlog：主库的所有写操作（增、删、改）都会以事件的形式记录到二进制日志（Binlog）中。Binlog有statement、row、mixed三种格式。
2. 主库Dump线程：当从库连接到主库时，主库会创建一个Dump线程，负责将Binlog内容发送给从库。
3. 从库IO线程：从库会启动一个IO线程，连接到主库的Dump线程，接收主库发送过来的Binlog事件，并将其写入到本地的中继日志（Relay Log）中。
4. 从库SQL线程：从库会启动一个SQL线程，负责读取Relay Log中的事件，并在从库上逐一执行这些SQL语句，从而实现数据同步。

主从延迟的原因：

1. 从库回放慢（单线程瓶颈）：在MySQL 5.6及以前版本，从库的SQL线程是单线程的，它会顺序执行Relay Log中的所有事件。当主库并发写入很高，或者有大事务（如批量更新10万行数据）时，从库的SQL线程可能需要很长时间才能追平主库，导致延迟。
2. 从库机器负载高：如果从库机器的硬件配置（CPU、内存、IO）低于主库，或者从库上运行了其他高负载任务（如复杂的报表查询），可能导致从库的SQL线程执行变慢，从而产生延迟。
3. 大事务：如果主库上执行了一个耗时很长的大事务（例如5分钟），那么从库在回放这个事务时也需要同样长的时间，在此期间，从库的数据会一直落后于主库。
4. 网络延迟：主从库之间的网络传输延迟也会导致数据同步的滞后。

解决方案：

1. 并行复制（MySQL 5.7+）：
   • MySQL 5.7及更高版本引入了多线程从库（MTS - Multi-Threaded Slave），允许从库的SQL线程并行回放Binlog事件。
   • 通过配置slave_parallel_workers参数（设置并行工作线程数）和slave_parallel_type（如LOGICAL_CLOCK或DATABASE），可以显著提高从库

弹性设计题：超时、重试、幂等、熔断

回答思路

分布式系统弹性设计题，美团外卖业务对超时容忍度极低，要展示完整的容错设计思路。

1. 超时设置：接口超时 = P99响应时间 + buffer，不可设太长（浪费资源）或太短（误判正常响应为超时）。
2. 重试策略：指数退避（Exponential Backoff）+ jitter，避免惊群效应。
3. 幂等性：重试必须配合幂等，否则会引发重复下单等问题。
4. 熔断降级：重试超过阈值后熔断，避免雪崩。

回答示例

超时设计：

超时不是随意设的，要基于实际 P99 数据设置。比如接口的 P99 响应时间是 200ms，那么超时时间可设为 500ms（留 2.5 倍 buffer）。过短的超时（如 100ms）会导致大量"伪超时"——请求实际上处理成功了但被提前中断；过长的超时（如 10s）会让真正的故障长时间占用资源，无法及时切换到备用方案。

重试策略——指数退避 + Jitter：

// 通用指数退避公式：wait = base * 2^attempt + random_jitter
public long getWaitTime(int attempt) {
    long base = 100; // 基础等待100ms
    long wait = base * (1L << attempt); // 指数增长
    long jitter = new Random().nextLong(wait); // 随机抖动，打散重试峰值
    return Math.min(wait + jitter, 30000); // 上限30秒
}

加入 Jitter（随机抖动）的目的是避免大量请求在同一时刻重试（比如服务恢复的瞬间，1 万个请求同时重试造成二次雪崩）。

幂等性要求：重试前必须确认上一次请求是否真的失败了。如果使用 HTTP 协议，可通过 Idempotency-Key 请求头去重；如果使用 MQ，消费端必须自己实现幂等。

熔断兜底：设置最大重试次数（如 3 次），超过后不再重试，直接降级或返回友好提示。

你对美团优选（社区电商）有什么了解？技术挑战有哪些？

回答思路

这是美团特色题，考察你对美团核心业务的了解深度，以及能否将技术与业务场景结合。

1. 业务理解：美团优选是社区团购模式，次日达，以低价生鲜为核心。
2. 技术挑战：供应链库存管理、需求预测、损耗控制、物流调度。
3. 个人结合点：如果你是技术岗，说明你能贡献的具体方向。

回答示例

美团优选采用的是预售+次日自提的社区电商模式：用户在当天 23:59 前下单，供应商次日送货到团长自提点，用户自提。核心价值是低价（预售降低库存损耗）和便利（下沉市场的家门口提货点）。

技术挑战我认为有三个方面：

1. 需求预测：由于是预售模式，次日就要供货，供应商需要提前备货。如果预测不准——多备了卖不掉就是损耗（生鲜保质期短），少备了用户买不到就是缺货。要精准预测次日某个社区某个 SKU 的销量，需要结合历史数据、天气、节假日、促销计划等多维特征，是典型的时序预测问题。
2. 库存精细化管理：SKU 数量庞大（数千个），每个 SKU 在每个网格仓都有库存，需要做到单品级的库存控制。如果用简单的人工设置安全库存，每个 SKU 每天都要人工调整，根本不可行，需要建设智能补货系统。
3. 配送调度优化：次日达意味着从供应商到网格仓再到团长的链路只有 12-18 小时可用，配送路径优化和时间窗口管理（团长什么时候方便接货）是核心挑战。

如何保证 MySQL 和 Redis 的数据一致性？

回答思路

这是美团高频题，也是分布式系统中最经典的一致性问题之一。要给出多个方案的对比分析。

1. Cache Aside（最常用）：读时先 Cache 后 DB，写时先 DB 后删 Cache。
2. 问题点：并发情况下可能产生脏数据，延迟双删/设置 TTL 可以缓解。
3. Read Through / Write Through：旁白介绍，不常用。
4. 延迟双删：写 DB 后延迟一段时间再删除 Cache，缓解并发导致的脏读。

回答示例

Cache Aside（旁路缓存）是最常用的模式：

读操作：Cache 命中则直接返回，未命中则查 DB 并写入 Cache。

read(key):
    value = redis.get(key)
    if value == null:
        value = mysql.get(key)
        redis.set(key, value)
    return value

写操作：先写 DB，删除 Cache（注意是删除不是更新）。

write(key, value):
    mysql.set(key, value)
    redis.del(key) // 删除而非更新，避免脏数据

为什么删除而不是更新？ 因为更新 Cache 时，如果 DB 写入成功但 Cache 更新失败，就会出现 Cache 和 DB 不一致；而删除 Cache 后，下次读请求会从 DB 读取到最新数据再写入 Cache，天然自愈。

并发问题：并发场景下可能发生：

1. 线程 A 读 Cache 未命中，查 DB（得到旧值 V1）；
2. 线程 B 更新 DB 为新值 V2，删除 Cache；
3. 线程 A 把旧值 V1 写回 Cache → Cache 出现脏数据。

解决方案：延迟双删

write(key, value):
    mysql.set(key, value)
    redis.del(key) // 第一次删除
    sleep(100ms) // 延迟100-300ms（覆盖读请求的完成时间）
    redis.del(key) // 第二次删除

最终方案：业务对一致性要求极高的场景（如余额、库存），不建议用 Cache Aside，建议直接读 DB 或用分布式锁串行读写。对于一致性要求不那么高的场景（用户头像、商品描述），Cache Aside + TTL 即可。