北京三快科技有限公司校招后端开发面试经验——求职精灵（finsight.work）

回答框架：先列五种基础结构，每种按「底层实现 → 典型场景 → 一个业务例子」说，再用 Bitmap、HyperLogLog、Geo 三种扩展收尾，体现知识面。

1. String：底层 SDS，适合缓存对象、计数器与分布式锁，外卖优惠券库存扣减常用 INCR 保证原子性。
2. List：quicklist，适合简单消息队列与最近 N 条记录，LPUSH + BRPOP 即可实现阻塞消费。
3. Hash：小数据量用 listpack，适合存对象字段和购物车，避免整段 JSON 反复序列化。
4. Set：listpack 或 hashtable，适合去重、共同好友与抽奖。
5. ZSet：listpack 或跳表加字典，适合排行榜与延迟队列，score 存时间戳就能做定时任务。

加分项：Bitmap 做签到，HyperLogLog 做 UV 估算，Geo 算骑手与门店距离。结尾补一句「选型先看读写模式，再看内存与一致性要求」，比单纯背诵更完整。

回答框架：七个参数 → 任务提交后的完整流转 → 两类任务的配置公式 → 拒绝策略怎么选。

1. 七个参数是 corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler，其中队列容量往往比线程数更影响实际行为。
2. 执行顺序：核心线程未满先建核心线程；满了进队列；队列满了才扩到最大线程数；再满触发拒绝策略。最容易答错的是「先扩线程再排队」。
3. 配置：CPU 密集型取核数加一；IO 密集型按「核数 ×（1 + 等待时间 / 计算时间）」估算，外卖订单推送这类等 HTTP 响应的场景可以明显放大。
4. 拒绝策略：核心链路用 CallerRunsPolicy 做反压，允许丢弃的日志和埋点用 DiscardPolicy，不要默认 AbortPolicy 把异常抛给用户。
5. 最后补一句：线程池必须命名并接入监控，队列积压和活跃线程数是第一预警指标。

回答框架：先讲清「限流 → 扣减 → 落库 → 兜底」四层，再说明每层解决什么问题，最后主动提一致性与补偿。

1. 流量控制：前端置灰防重复点击，网关按用户与 IP 限流，活动页做排队或验证码，把无效流量挡在核心链路之外。
2. 库存扣减：活动前把库存预热到 Redis，用 Lua 脚本把「判断 + 扣减」做成原子操作，避免并发超卖。

local stock = redis.call('GET', KEYS[1])
if not stock or tonumber(stock) <= 0 then return 0 end
redis.call('DECR', KEYS[1])
return 1

1. 异步落库：扣减成功后发消息到 MQ，由消费者创建领券记录，数据库唯一索引（用户 ID + 券 ID）兜住重复消费。
2. 兜底：Redis 与数据库的已发数量做对账，差值超阈值告警并暂停活动；Redis 故障时降级为「排队 + 限量放行」，不要直接打穿数据库。

面试官常追问「Redis 扣了但消息丢了怎么办」，答案是本地消息表或事务消息加定时补偿。

回答框架：用 STAR 讲，重点放在「怎么定位」而不是「我做了什么」，最后一定要给量化结果。

1. 背景：商品列表接口平均响应 800ms，高峰期超时率明显上升，影响首页转化。
2. 定位：先用压测复现，再用 Actuator 加 Micrometer 拿到慢接口分布，发现耗时集中在数据库；EXPLAIN 看到关联字段没索引，扫描行数超过十万。
3. 方案：给外键补索引，把品类、品牌这类低频变更数据放 Redis 并设 5 分钟 TTL，热点再叠一层 Caffeine 本地缓存，减少网络往返。
4. 结果：平均响应从 800ms 降到 65ms，数据库 QPS 下降约七成，CPU 从 35% 降到 12%。
5. 收尾：说明如何防止回退，比如把 P99 和慢 SQL 数量做成看板，索引变更走评审。这样面试官会认为你做过完整闭环，而不是一次性调优。

回答框架：先画链路表示你懂业务，再只挑一个点深入，最后给技术方案与收益，不要泛泛说「用大数据优化」。

1. 链路：用户下单 → 调度系统派单 → 骑手接单 → 位置上报 → 路径规划 → 送达时间预估。
2. 我选位置上报：全国骑手按秒级上报，写请求量会随骑手数线性上涨，是典型的写多读少场景。
3. 客户端做自适应频率，静止时降频、行进时恢复，减少无效上报；服务端写入 Redis Geo，再由异步任务批量落库，避免直接压 MySQL。
4. 读取侧优先读 Redis，骑手位置超过三分钟未更新时降级展示「最后已知位置」，并给用户提示。
5. 收益可以按写入量、P99 与存储成本三个维度估算。若追问调度算法，坦白说这是运筹优化问题，要从履约时长、骑手收入与商家出餐时间多目标建模，不要硬答。

先确认边界：容量 capacity ≥ 1；get 未命中返回 -1；put 的 key 已存在时要更新值并刷新为最近使用；容量满时淘汰最久未使用的节点；要求 get 与 put 都是 O(1)。
思路是「哈希表 + 双向链表」：哈希表负责 O(1) 定位节点，双向链表头部放最新访问、尾部放最久未使用，删除尾节点即可完成淘汰。用哑头哑尾可以省掉大量空指针判断。

class LRUCache {
    class Node { int k, v; Node prev, next; Node(int k, int v) { this.k = k; this.v = v; } }
    private Map<Integer, Node> map = new HashMap<>();
    private int cap;
    private Node head = new Node(0, 0), tail = new Node(0, 0);
    public LRUCache(int capacity) {
        cap = capacity; head.next = tail; tail.prev = head;
    }
    public int get(int key) {
        Node n = map.get(key);
        if (n == null) return -1;
        moveToHead(n);
        return n.v;
    }
    public void put(int key, int value) {
        Node n = map.get(key);
        if (n != null) { n.v = value; moveToHead(n); return; }
        if (map.size() == cap) {
            Node last = tail.prev;
            remove(last); map.remove(last.k);
        }
        Node node = new Node(key, value);
        map.put(key, node); addHead(node);
    }
    private void remove(Node n) { n.prev.next = n.next; n.next.prev = n.prev; }
    private void addHead(Node n) { n.next = head.next; n.prev = head; head.next.prev = n; head.next = n; }
    private void moveToHead(Node n) { remove(n); addHead(n); }
}

追问一般是「怎么保证线程安全」：可以整体加锁，或用 LinkedHashMap 的 accessOrder 配合 removeEldestEntry，但后者同样需要外部同步。

回答框架：先把 Binlog 流转讲成一条链，再区分「延迟的表现」和「延迟的原因」，最后按业务一致性要求给方案。

1. 原理：主库把写操作记入 Binlog；Dump 线程推给从库 IO 线程；IO 线程写 Relay Log；SQL 线程回放，完成同步。
2. 原因：从库回放能力不足、从库机器负载高、主库大事务或大表 DDL，都会让 Seconds_Behind_Master 变大。
3. 方案一：开启并行复制，slave_parallel_workers 配合 LOGICAL_CLOCK，让多个 worker 并发回放。
4. 方案二：读写分离加路由判断，强一致读走主库，弱一致读走从库；路由层可读取延迟水位，超过阈值就切主。
5. 方案三：拆大事务、控制批量更新大小，DDL 走工具做平滑变更。

收尾补一句：延迟不可能彻底消除，工程上做的是「让业务感知不到」，例如下单后立即读主库、列表页容忍秒级延迟。

回答框架：超时怎么定 → 重试怎么做 → 幂等怎么保证 → 什么时候必须熔断，四件事缺一不可。

1. 超时：以依赖的 P99 为基线，留 2～3 倍余量。太短会把正常慢请求判成失败，太长会占住线程拖垮调用方。
2. 重试：只对幂等操作和可恢复错误重试，采用指数退避加随机抖动，避免服务刚恢复时大量请求同时打回。

long wait = Math.min(base * (1L << attempt) + random.nextInt(100), 30000);

1. 幂等：HTTP 用 Idempotency-Key，MQ 消费端用业务唯一键或去重表，数据库层加唯一索引兜底。
2. 熔断：连续失败率达到阈值就打开断路器，后续请求直接走降级；半开状态只放少量探测流量。
3. 还要设重试上限与总预算，比如整条链路最多 3 次、总耗时不超过 2 秒，否则重试会放大故障。

回答框架：先讲模式与价值，再讲技术挑战，最后落到「我来了能做什么」，不要背公司简介。

1. 模式：美团优选是预售加次日自提，用户当天 23:59 前下单，供应商次日送到网格仓，再由团长配送到自提点。低价来自预售降低损耗，便利来自家门口提货。
2. 挑战一：需求预测。生鲜保质期短，备多了损耗、备少了缺货，需要把历史销量、天气、节假日、促销计划一起建模。
3. 挑战二：库存与补货。SKU 多、每个网格仓都备货，靠人工设安全库存不可行，需要单品级的智能补货。
4. 挑战三：履约时效。从供应商到网格仓再到团长只有十几小时，分拣、装车、路线都要卡时间窗。
5. 结合点：后端可以做库存扣减与预占、履约状态机、库存对账；偏数据方向可以做预测特征与补货策略。

回答框架：先给最常用的 Cache Aside，再解释「为什么删而不是改」，接着主动暴露并发脏数据问题并给方案，最后按业务一致性要求选型。

1. 读：先查缓存，未命中查库并回填；写：先写库，再删缓存。
2. 删除而不是更新，是因为更新缓存可能覆盖其他线程刚写入的新值；删除后下次读会自然回源，具备自愈能力。
3. 并发问题：读线程查库拿到旧值，写线程更新库并删缓存，读线程再把旧值写回，缓存就脏了。
4. 缓解：延迟双删（写完删一次，隔 100～300ms 再删一次）、给缓存设 TTL、用消息队列异步补偿删除。
5. 强一致场景（余额、库存）不要依赖缓存一致性方案，直接读主库或用分布式锁串行化；弱一致场景（商品描述、头像）Cache Aside 加短 TTL 足够。

追问「先删缓存再写库行不行」：并发下同样会脏，且命中率更低，一般不推荐。