整体架构设计 · 字节跳动面试官深度拷打

整体架构设计

字节跳动 · 资深面试官视角 · 三层模块 + 中间件全链路拆解

三模块分层读写分离链路双缓冲号段布隆过滤器多级缓存分布式限流

📂 项目概览

这是一个完整的 URL 短链接服务平台，支持长链接转短码、302 重定向、PV/UV 统计三大核心功能。系统采用 三模块分层架构（common / service / web），通过 MySQL 持久化 + Redis 多级缓存 + Redisson 分布式组件的协作，实现高性能、高可用的短链接生成与访问。

Java 21Spring Boot 3.4MyBatis-Plus 3.5MySQL 8RedisRedissonSqidsBloom FilterHyperLogLogGuava

ShortLink 整体架构 — 三层调用链路

shortlink-web (入口层)

→ ① ShortLinkController POST 创建短链接

→ ② RedirectController GET 302 重定向

→ ③ StatsController GET PV/UV 查询

→ ④ RateLimitInterceptor 分布式令牌桶限流

→ ⑤ GlobalExceptionHandler 统一异常处理

shortlink-service (业务层)

→ ① ShortLinkService 生成短码 + DB + Cache + Bloom

→ ② RedirectService Bloom → Redis → MySQL 三级查询

→ ③ StatsService INCR pv + PFADD uv (Redis)

→ ④ StatsFlushTask @Scheduled 60s 刷盘 MySQL

→ ⑤ SegmentIdGenerator 双缓冲号段 + 异步预加载

shortlink-common (工具层)

→ ① ShortCodec Sqids 编解码

→ ② RedisKeyConstant Redis 键名统一管理

→ ③ ErrorCode + ShortLinkException 错误码体系

面试题

💬 "先介绍一下你这个短链接项目的整体架构吧。"

考察意图：全局视角和架构思维 — 能否用清晰的层次结构描述系统，讲清楚每个模块的职责边界、中间件的角色、以及读写链路的差异。这是开场题，答好了后面追问会更深入。

扣分回答 ❌

"就是一个 Spring Boot 项目，用了 Redis 和 MySQL，能生成短链接也能跳转。"

🧠 面试官 OS：太模糊了，分了几个模块？每个模块干什么？中间件怎么配合的？读写流程有什么不同？完全没有架构感。

满分回答 ✅

我的短链接项目采用 三模块分层架构，从上到下分为 web、service、common 三层：

shortlink-web：入口层，包含 3 个 Controller（创建、重定向、统计）、限流拦截器、全局异常处理器，以及 Redis/布隆过滤器/线程池的配置类。

shortlink-service：核心业务层，包含短链接创建服务、重定向服务（三级查询：布隆过滤器 → Redis → MySQL）、PV/UV 统计服务、定时刷盘任务，以及号段模式的分布式 ID 生成器。

shortlink-common：公共工具层，包含 Sqids 短码编解码、Redis 键名常量、错误码枚举和自定义异常类。

中间件方面，Redis 承担五个角色：缓存（短码→URL 映射）、布隆过滤器（防穿透）、分布式锁、PV 计数（INCR）和 UV 统计（HyperLogLog）。MySQL 负责持久化短链接数据和号段分配。Redisson 提供分布式令牌桶限流。

读写比大约 100:1，所以读链路做了重点优化：布隆过滤器拦截无效请求、Redis 缓存命中后直接返回、异步记录统计数据不阻塞重定向。

追问①Level 1 · 是什么

💬 "这个项目是做什么的？解决什么问题？为什么不直接用长链接？"

💡 背景知识：短链接服务是互联网非常常见的基础设施。比如微博有 140 字限制，长 URL 会占用大量字符；短信按字数计费，每个字符都要省着用；推广链接需要统计点击量，直接用原始 URL 无法追踪。短链接服务的核心就是：把长 URL 压缩成 6~8 个字符的短码，访问短码时 302 重定向回原始 URL。

短链接 vs 长链接的核心差异：

维度	长链接	短链接
长度	几十到几百字符	域名 + 6~8 字符
可读性	包含参数，难阅读	简洁，适合分享
统计能力	无法追踪	可统计 PV/UV
安全性	暴露参数	隐藏原始 URL
典型场景	浏览器地址栏	短信/微博/二维码

我的项目解决三个核心问题：① 生成：长 URL → 6 位短码，全局唯一不碰撞；② 跳转：访问短码时毫秒级 302 重定向；③ 统计：每个短码的 PV（总点击）和 UV（独立访客）。

追问②Level 1 · 是什么

💬 "技术栈怎么选的？为什么是 Spring Boot + Redis + MySQL 这套？"

💡 背景知识：技术选型不是"我会什么就用什么"，而是要匹配业务场景。短链接服务的特点是：读多写少（读写比约 100:1）、对读延迟敏感（用户点击短链接不能等太久）、数据需要持久化（短码不能丢）。这就决定了需要一个高速缓存（Redis）+ 可靠存储（MySQL）的组合。

技术选型决策表：

组件	选择	为什么选	备选方案
框架	Spring Boot 3.4	Java 21 支持 + 生态成熟 + 自动配置	Quarkus / Micronaut
ORM	MyBatis-Plus 3.5	通用 CRUD 免写 SQL + Lambda 条件构造	JPA / 原生 MyBatis
缓存	Redis (Lettuce)	读延迟 <1ms + 支持 HyperLogLog/BloomFilter	Caffeine (单机)
分布式组件	Redisson	分布式锁 + 布隆过滤器 + 令牌桶限流一站式	手写 Lua 脚本
数据库	MySQL 8	事务强一致 + 唯一索引兜底 + 运维成熟	PostgreSQL / TiDB
短码编码	Sqids	内置混淆、零碰撞、可逆解码	手写 Base62 + BitShuffle
哈希工具	Guava Hashing	SHA-256 生成访客 ID，API 简洁	JDK MessageDigest

总结：这套技术栈的核心优势是成熟稳定 + 生态完善。对于短链接这种"小而精"的服务，不需要引入 Kafka、ES 这些重量级组件，够用就好。

追问③Level 2 · 怎么用

💬 "你这三个模块 common、service、web 是怎么划分的？为什么这样分？"

💡 背景知识：模块划分的本质是职责分离（Separation of Concerns）。好的模块划分能做到：① 每个模块可以独立编译测试；② 依赖方向单一（上层依赖下层，不能反过来）；③ 修改某一层不影响其他层。这就是经典的分层架构（Layered Architecture）。

// pom.xml — 三个子模块
<modules>
    <module>shortlink-common</module>    // 最底层，无任何依赖
    <module>shortlink-service</module>   // 中间层，依赖 common
    <module>shortlink-web</module>       // 最顶层，依赖 service + common
</modules>

三层模块职责对比：

模块	职责	核心类	依赖方向
common	工具类 + 常量 + 异常	ShortCodec, RedisKeyConstant, ErrorCode	无外部依赖
service	业务逻辑 + 数据访问	ShortLinkService, RedirectService, SegmentIdGenerator	依赖 common
web	HTTP 接口 + 配置 + 启动类	Controllers, Configs, Interceptor, Application	依赖 service + common

为什么这样分？关键原则是依赖方向单向：web → service → common，永远不会反向依赖。这样做的好处：① common 可以被其他项目复用（比如未来加一个 admin 后台）；② service 层不关心 HTTP 协议，可以被 RPC、MQ 消费者直接调用；③ 单独测试 service 不需要启动 Spring MVC。

追问④Level 2 · 怎么用

💬 "说说读流程，用户点击短链接到最终跳转，完整走一遍。"

💡 背景知识：短链接服务的读流程是最核心的性能瓶颈点。用户点击一个短链接（如 http://short.link/aBcDeF），浏览器发起 GET 请求，服务端需要在毫秒级内完成短码解析并返回 302 重定向。因此读流程的设计目标是：尽可能在 Redis 缓存层就命中，避免打到数据库。

// RedirectController.java — 入口
@GetMapping("/{shortCode}")
public ResponseEntity<Void> redirect(@PathVariable String shortCode, HttpServletRequest request) {
    String originalUrl = redirectService.resolve(shortCode);  // 🔍 三级查询
    String visitorId = generateVisitorId(request);             // SHA-256(IP+UA) 取前16位
    CompletableFuture.runAsync(() -> statsService.recordClick(shortCode, visitorId), statsExecutor);
    // 异步统计，不阻塞重定向响应。用专用线程池，DiscardPolicy 丢弃策略保护主线程
    return ResponseEntity.status(HttpStatus.FOUND)
            .header(HttpHeaders.LOCATION, originalUrl)        // 302 重定向目标
            .header(HttpHeaders.CACHE_CONTROL, "no-cache, no-store") // 禁止缓存
            .build();
}

读流程六步：

① 用户访问 GET /aBcDeF → RedirectController

② 布隆过滤器检查：bloomFilter.contains("aBcDeF")，false → 直接返回 404，拦截无效请求

③ Redis 缓存查询：GET sl:aBcDeF，命中则解析 JSON 获取 URL，检查过期时间

④ MySQL 回源（缓存 miss 时）：查询 short_link 表，找到后回填 Redis 缓存（TTL 24h + 随机偏移）

⑤ 302 重定向：响应 Location 头 + Cache-Control: no-cache（保证每次都过服务端，统计才准）

⑥ 异步统计：CompletableFuture 在 statsExecutor 线程池中异步执行 INCR pv + PFADD uv

追问⑤Level 2 · 怎么用

💬 "那写流程呢？创建一个短链接要经过哪些步骤？"

💡 背景知识：写流程和读流程相反——写是低频操作，但每一步都涉及持久化。创建短链接需要保证两件事：① 短码全局唯一（不能生成重复的）；② 写入后立即可读（创建完就能跳转）。这就需要在数据库写入的同时，把缓存和布隆过滤器也写好。

// ShortLinkService.java — 创建短链接核心逻辑
public String createShortLink(String originalUrl, LocalDateTime expiredAt) {
    long id = idGenerator.nextId();              // ① 号段ID生成器，内存 AtomicLong 原子自增
    String shortCode = ShortCodec.encode(id);   // ② Sqids 编码，内置混淆不可预测
    ShortLink entity = new ShortLink();
    entity.setShortCode(shortCode);
    entity.setOriginalUrl(originalUrl);
    entity.setCreatedAt(LocalDateTime.now());
    entity.setExpiredAt(expiredAt);
    shortLinkMapper.insert(entity);               // ③ MySQL INSERT，唯一索引兜底
    String cacheValue = buildCacheValue(originalUrl, expiredAt);
    Duration ttl = Duration.ofHours(baseTtlHours)
            .plusSeconds(ThreadLocalRandom.current().nextInt(randomOffsetSeconds));
    redisTemplate.opsForValue().set(
        RedisKeyConstant.shortLinkKey(shortCode), cacheValue, ttl); // ④ Redis 缓存
    bloomFilter.add(shortCode);                   // ⑤ 注册布隆过滤器
    return shortCode;
}

写流程五步：ID 生成 → 短码编码 → MySQL 写入 → Redis 缓存 → 布隆注册。

注意写流程是同步的——必须全部成功才能返回，因为任何一步失败（比如 DB 写入失败）就不应该返回短码给用户。

追问⑥Level 3 · 怎么实现

💬 "你提到设计模式，号段双缓冲和三级查询用了什么模式？"

💡 背景知识：设计模式不是为了用而用，而是自然而然在解决问题时"长出来的"。号段双缓冲的核心是"一个在用一个在等"——这就是生产者-消费者模式。三级查询（布隆→Redis→MySQL）每一层先过滤再传给下一层——这就是责任链模式的思想。

项目中的设计模式：

场景	设计模式	代码体现
号段双缓冲	生产者-消费者	asyncLoader 异步生产 nextBuffer，nextId() 消费 currentBuffer
三级查询	责任链 / 多级降级	Bloom → Redis → MySQL，每层可拦截或穿透到下层
统计异步化	观察者 / 事件驱动	CompletableFuture.runAsync() 异步记录不阻塞主流程
全局异常处理	模板方法	@RestControllerAdvice 统一拦截，不同异常走不同处理分支
配置类	工厂模式	@Bean 方法创建 BloomFilter / RateLimiter / ThreadPool 实例
短码编码	策略模式	ShortCodec 封装 Sqids，可替换为 Base62 或其他编码策略

面试里不用把所有模式都说一遍，挑两个讲透就够了。重点讲号段双缓冲的生产者-消费者：asyncLoader 是生产者线程，在 currentBuffer 消耗过半时异步加载 nextBuffer；nextId() 是消费者，从 currentBuffer 原子自增取 ID，耗尽后切换。两者通过 volatile + AtomicBoolean 协调。

追问⑦Level 3 · 怎么实现

💬 "你的异常处理怎么设计的？出了错怎么返回给前端？"

💡 背景知识：在 Spring MVC 中，@RestControllerAdvice + @ExceptionHandler 是全局异常处理的标准做法。它的好处是：Controller 里只管正常流程，所有异常统一在一个地方兜底处理，返回格式一致的错误响应。这比在每个 Controller 方法里 try-catch 优雅得多。

// GlobalExceptionHandler.java
@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ShortLinkException.class)
    public ResponseEntity<ErrorResponse> handleShortLinkException(ShortLinkException e) {
        return ResponseEntity.status(e.getErrorCode().getHttpStatus())
                .body(new ErrorResponse(e.getErrorCode().getHttpStatus(), e.getMessage()));
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ErrorResponse> handleValidation(MethodArgumentNotValidException e) {
        String message = e.getBindingResult().getFieldErrors().stream()
                .map(f -> f.getField() + ": " + f.getDefaultMessage())
                .reduce((a, b) -> a + "; " + b)
                .orElse("validation failed");
        return ResponseEntity.badRequest().body(new ErrorResponse(400, message));
    }
}

错误码体系：

ErrorCode	HTTP 状态码	含义	触发场景
SHORT_CODE_NOT_FOUND	404	短链接不存在	布隆过滤器判否 / DB 查无记录
SHORT_CODE_EXPIRED	410	短链接已过期	expiredAt < now()
RATE_LIMIT_EXCEEDED	429	请求过于频繁	令牌桶获取失败
ID_GENERATE_FAILED	500	ID 生成失败	号段表不存在 / 乐观锁重试超限
INVALID_URL	400	无效的 URL	@Valid 校验失败

追问⑧Level 3 · 怎么实现

💬 "你的接口返回格式是怎么定的？RESTful 规范遵循了哪些？"

💡 背景知识：RESTful 是一种 API 设计风格，核心原则包括：用 HTTP 方法表达语义（GET 读 / POST 写）、用状态码表达结果（201 创建成功 / 302 重定向 / 404 未找到）、URL 表示资源而非动作。遵循 RESTful 的好处是 API 自描述、前后端沟通成本低。

API 设计一览：

接口	方法	路径	状态码	返回体
创建短链接	POST	/api/short-link	201 Created	{"shortCode":"xxx","shortUrl":"xxx"}
短链接跳转	GET	/{shortCode}	302 Found	空 (Location 头)
查询统计	GET	/api/short-link/{code}/stats	200 OK	{"shortCode":"xxx","pv":100,"uv":80}
参数错误	-	-	400 Bad Request	{"code":400,"message":"..."}
短码不存在	-	-	404 Not Found	{"code":404,"message":"短链接不存在"}
限流触发	-	-	429 Too Many Requests	{"code":429,"message":"请求过于频繁"}

遵循的 RESTful 原则：① 资源导向：URL 是 /api/short-link 而非 /api/createShortLink；② 语义化状态码：201 = 创建成功、302 = 重定向、410 = 已过期；③ 统一错误格式：所有错误都是 {code, message} 结构。

追问⑨Level 4 · 深入原理

💬 "你用了 Redis、MySQL、Redisson 三个中间件，它们各自扮演什么角色？去掉某个会怎样？"

💡 背景知识：在分布式系统中，每个中间件都有其不可替代的角色。理解"去掉某个组件后系统会怎样退化"，是考察你对架构依赖关系的理解深度。这也是架构设计中单点分析（Single Point Analysis）的常见思路。

中间件角色矩阵：

中间件	在你项目中的角色	去掉后的影响
Redis	① 缓存 sl:{code}→URL ② PV 计数 (INCR) ③ UV 统计 (HyperLogLog) ④ 布隆过滤器存储 ⑤ 限流令牌桶状态	所有读请求打到 MySQL → DB 扛不住；统计功能完全不可用；无法防缓存穿透；限流失效
MySQL	① 持久化 short_link 数据 ② 号段分配 id_segment ③ 统计刷盘目标	数据丢失；ID 生成器无法初始化；缓存过期后无法回源
Redisson	① 分布式锁 (刷盘/布隆初始化) ② 分布式令牌桶限流 ③ 布隆过滤器 API	多实例同时刷盘造成数据不一致；限流只能降级为单机；布隆过滤器需要自己实现

核心结论：Redis 是最关键的——它承担了 5 个角色。MySQL 是数据的最终归宿。Redisson 是"锦上添花"的分布式协调层，去掉后功能降级但不至于完全不可用。

追问⑩Level 4 · 深入原理

💬 "如果 Redis 挂了，你的服务还能工作吗？"

💡 背景知识：这是典型的容灾降级（Graceful Degradation）问题。面试官想知道你有没有考虑过"基础设施故障时的应急方案"。在生产环境中，任何中间件都可能挂，系统设计时必须考虑这种情况。

Redis 宕机后各功能的影响：

功能	影响程度	原因	降级方案
创建短链接	部分可用	ID 生成走内存不受影响，但 Redis SET 和布隆 ADD 失败	catch 异常继续，等 Redis 恢复后缓存回填
短链接跳转	严重劣化	布隆过滤器不可用，缓存不可用，全部打 MySQL	直接查 MySQL，增加本地缓存 Caffeine 兜底
PV/UV 统计	完全不可用	INCR 和 PFADD 都依赖 Redis	降级为写本地日志，恢复后重放
限流	完全失效	令牌桶状态存在 Redis	降级为 Guava RateLimiter 单机限流
分布式锁	完全失效	Redisson 锁依赖 Redis	降级为 JVM ReentrantLock（单实例场景）

当前项目的不足：没有实现 Redis 宕机时的自动降级。如果要改进，可以加一个本地缓存 Caffeine 作为二级缓存，Redis 不可用时自动切换到本地缓存，牺牲一致性换取可用性。

追问⑪Level 4 · 深入原理

💬 "你的项目有哪些单点故障风险？怎么消除？"

💡 背景知识：单点故障（Single Point of Failure, SPOF）是指系统中某个组件一旦故障，整个系统就不可用。消除 SPOF 的核心思路是冗余：每个关键组件至少有 2 个副本。

当前项目的 SPOF 分析：

组件	是否单点	消除方案
应用实例	可能	多实例部署 + Nginx 负载均衡
MySQL	是	主从复制 + 读写分离 + 自动故障转移 (MHA)
Redis	是	Redis Sentinel 哨兵或 Redis Cluster 集群
号段表	间接	号段步长设大一些，内存缓冲区能撑住 DB 短暂不可用
布隆过滤器	间接	存在 Redis 中，跟 Redis 共命运；可加本地 Guava BloomFilter 兜底

当前项目是单机开发环境，生产部署时至少需要：2+ 应用实例 + MySQL 主从 + Redis Sentinel。号段双缓冲机制天然有"缓冲"作用——即使 MySQL 短暂不可用，内存里的号段还能用一阵子。

追问⑫Level 5 · 陷阱/边界

💬 "如果 QPS 从 100 涨到 10 万，你的架构要怎么改？"

💡 背景知识：QPS 从 100 到 10 万是 1000 倍的增长，这不是"加几台服务器"就能解决的。需要从接入层、应用层、缓存层、数据库层全链路优化。字节跳动的面试中经常问"如何支撑 100 万 QPS"这类问题，考察的是你的扩展性思维。

扩容方案分层规划：

层次	当前 (100 QPS)	10 万 QPS 改造
接入层	单 Nginx	LVS/F5 + Nginx 集群 + DNS 轮询
应用层	单实例	20~50 个实例 + K8s 自动扩缩容
缓存层	单 Redis	Redis Cluster 分片 + 本地 Caffeine L1 缓存
数据库	单 MySQL	主从读写分离 + 按短码分库分表
ID 生成	步长 1000	动态步长调整（参考美团 Leaf）+ 多 DB 实例
统计	Redis INCR + 60s 刷盘	Kafka 削峰 + Flink 实时聚合

关键改造点：① 加 Caffeine 作为 L1 本地缓存，读请求先查 JVM 内存再查 Redis，减少 Redis 压力；② 数据库按短码 hash 分 8~16 张表；③ 统计从"Redis 直写 MySQL"改为"Kafka 异步消费"，避免 MySQL 被统计写入拖垮。

追问⑬Level 5 · 陷阱/边界

💬 "为什么不直接用美团 Leaf 或者百度 UID？自己写有什么好处？"

💡 背景知识：美团 Leaf 是业界最成熟的分布式 ID 方案之一，支持号段模式和 Snowflake 模式。百度 UidGenerator 是基于雪花算法的优化版。这两个都是开源的，直接引入就能用。面试官问这个问题，是想看你对"自研 vs 引入"的思考。

自研 vs 引入对比：

维度	自研（你的选择）	引入 Leaf / UID
学习价值	深入理解原理	黑盒使用
代码量	~200 行核心逻辑	引入一个 SDK
定制性	完全可控	改动需要 fork 源码
生产可靠性	未经大规模验证	百亿级验证
运维成本	低（内嵌在项目中）	Leaf 需要独立部署
功能完整度	基础双缓冲	动态步长 + 监控 + 降级

坦诚回答：我选择自己实现主要是为了面试展示和深入学习。生产环境中如果团队有现成的 ID 中心就直接用，没有的话 Leaf 是首选。我的实现其实就是 Leaf-Segment 的简化版，核心逻辑是一样的，只是少了动态步长调整和监控告警。

追问⑭Level 5 · 陷阱/边界

💬 "这个项目最大的缺陷是什么？如果重新设计你会怎么改？"

💡 背景知识：面试官问缺陷不是为了否定你，而是看你有没有自我反思和迭代思维。能主动指出不足并给出改进方向，比假装完美得分更高。

项目已知缺陷和改进方案：

缺陷	影响	改进方案
无本地缓存层	Redis 压力大，无降级能力	加 Caffeine 作为 L1 缓存
写流程非事务性	MySQL 写入成功但 Redis/Bloom 失败，数据不一致	加事务补偿 / 最终一致性机制
统计刷盘不精确	覆盖式 SET 而非增量更新，宕机可能丢数据	改用 Lua 脚本做原子 GET-DELETE + 增量更新
无链接管理功能	不支持删除/禁用短链接	加 status 字段 + 管理 API
无监控告警	线上问题无法及时发现	集成 Prometheus + Grafana
号段步长固定	QPS 变化时不够灵活	参考 Leaf 的动态步长算法

如果重新设计，最先改的两件事：① 加 Caffeine 本地缓存，读链路变成 Bloom → Caffeine → Redis → MySQL 四级；② 统计改用 Kafka 异步队列，彻底解耦统计和主流程。

追问⑮Level 6 · 生产实战

💬 "你做过压测吗？QPS 多少？P99 多少？瓶颈在哪？"

💡 背景知识：P99 延迟是指 99% 的请求都在这个时间内完成。比如 P99 = 10ms 表示只有 1% 的请求超过 10ms。压测工具通常用 JMeter、wrk 或 ab。面试官问这个是看你有没有性能意识，有没有动手验证过。

压测结果估算（基于单机 + JMeter）：

场景	QPS	P99 延迟	瓶颈分析
创建短链接 (写)	~2000-3000	~15ms	MySQL INSERT 是瓶颈（磁盘 IO）
重定向-缓存命中 (读)	~8000-12000	~3ms	Redis GET 网络延迟
重定向-缓存 miss (读)	~1000-2000	~20ms	MySQL SELECT + 回填缓存

瓶颈分析：

① 写链路瓶颈在 MySQL：每次创建需要 1 次 INSERT，磁盘刷盘是硬伤。优化方向：批量写入 / 异步写入 / SSD 存储。

② 读链路瓶颈在网络：Redis GET 约 0.5ms，加上 302 响应和异步统计，整体约 2~3ms。优化方向：加 Caffeine 本地缓存，P99 可降到 <1ms。

③ ID 生成不是瓶颈：号段在内存中，AtomicLong CAS 是纳秒级操作，单线程就能达到几千万 QPS。

▶🔍 Debug 演算：一次读请求的耗时分解

📍 Debug 演算：GET /aBcDeF 读链路耗时（缓存命中场景）

断点1: 请求到达 RedirectController
  Nginx → Spring DispatcherServlet → HandlerMapping
  耗时: ~0.1ms (JVM 内部路由)

断点2: bloomFilter.contains("aBcDeF")
  Redisson 发送 BF.EXISTS 命令到 Redis
  耗时: ~0.3ms (网络 RTT)
  返回: true → 继续

断点3: redisTemplate.opsForValue().get("sl:aBcDeF")
  发送 GET sl:aBcDeF 到 Redis
  耗时: ~0.5ms (网络 RTT + Redis 查找)
  返回: {"url":"https://example.com","expiredAt":null}

断点4: extractUrlAndCheckExpiry(cached)
  Jackson 解析 JSON → 检查 expiredAt
  耗时: ~0.05ms (纯 CPU)
  返回: "https://example.com"

断点5: CompletableFuture.runAsync(统计任务)
  提交到 statsExecutor 线程池，立即返回
  耗时: ~0.01ms (任务提交)

断点6: 构建 302 响应
  ResponseEntity.status(302).header(Location, url)
  耗时: ~0.05ms

总计: 0.1 + 0.3 + 0.5 + 0.05 + 0.01 + 0.05 ≈ 1.01ms

追问⑯Level 6 · 生产实战

💬 "如果要加日志链路追踪，你会怎么设计？"

💡 背景知识：分布式链路追踪（Distributed Tracing）是在微服务架构中追踪一个请求经过所有服务的完整路径。核心概念是 TraceId（一个请求的全局唯一 ID）和 SpanId（一个服务内部的操作 ID）。常用方案有 SkyWalking、Jaeger、Zipkin。

链路追踪设计方案：

① TraceId 生成：在 Nginx 层或 Filter 中生成 TraceId（UUID），放入 MDC（Mapped Diagnostic Context），贯穿整个请求生命周期。

② 日志格式：[TraceId] [SpanId] [类名.方法] 日志内容

③ 跨线程传递：异步统计用了 CompletableFuture，MDC 不会自动传递。需要封装一个 MdcTaskDecorator，在提交任务时复制 MDC。

④ 异步线程池的 MDC 传递：

// 改造 statsExecutor，包装 Runnable 传递 MDC
CompletableFuture.runAsync(() -> {
    // 问题: 这里是新线程, MDC 为空!
    statsService.recordClick(shortCode, visitorId);
}, statsExecutor);

// 改进: 用 MDC 包装
Map<String, String> mdcContext = MDC.getCopyOfContextMap();
CompletableFuture.runAsync(() -> {
    MDC.setContextMap(mdcContext);  // 恢复主线程的 MDC
    statsService.recordClick(shortCode, visitorId);
    MDC.clear();
}, statsExecutor);

⑤ 生产方案：接入 SkyWalking 探针（Java Agent），零代码侵入，自动追踪 HTTP、Redis、MySQL 调用链，配合 Grafana 可视化。

追问⑰Level 6 · 生产实战

💬 "如果要做灰度发布，新旧版本的短码兼容性怎么处理？"

💡 背景知识：灰度发布（Gray Release / Canary Release）是指新版本先发布给一小部分用户，验证没问题后再全量推广。对短链接服务来说，最大的挑战是短码兼容性——旧版本生成的短码，新版本必须能解析；反过来也要兼容。

灰度发布兼容性方案：

① 短码编码不能改：如果新版本换了编码算法（比如从 Sqids 换成 Base62），旧短码就解不了。所以编码层必须向后兼容或者做版本标记。

② 数据库 schema 兼容：新版本加字段只能 ALTER TABLE ADD COLUMN，不能改现有字段类型。

③ 缓存格式兼容：新版本的 JSON 结构只能加字段，不能改 key name。旧版本的缓存数据新版本也要能解析。

④ 流量切分：Nginx 按权重分配流量，先 5% 流量给新版本，观察监控无异常后逐步放大。

⑤ 双写策略：过渡期新旧版本同时写同一套 Redis 和 MySQL，共享数据，确保任何版本都能正确解析。

追问⑱Level 5 · 陷阱/边界

💬 "数据库到了瓶颈，你会怎么做分库分表？短码怎么路由？"

💡 背景知识：当单表数据量超过 2000 万行或单库 QPS 超过 5000 时，就需要考虑分库分表了。短链接的分片键选择是关键——因为所有查询都是 WHERE short_code = ?，所以必须按 short_code 分片。

分库分表方案：

① 分片键：short_code（因为读写都按短码查询）

② 路由算法：hash(short_code) % 分片数

③ 推荐拓扑：4 库 x 4 表 = 16 个分片，单片 5000 万行可撑 8 亿条记录

④ 中间件选择：ShardingSphere-JDBC（应用层分片，无需代理层）

号段表的分片：id_segment 表数据量极小（每个业务只有一行），不需要分片。但多库环境下，需要确保号段表只在一个库中，或者每个库有自己独立的号段范围（通过不同的 biz_tag 区分）。

分片路由示例：

// 分片路由逻辑
String shortCode = "aBcDeF";
int shardIndex = Math.abs(shortCode.hashCode()) % 16;  // 16 个分片
int dbIndex = shardIndex / 4;     // 第几个库 (0~3)
int tableIndex = shardIndex % 4;  // 第几张表 (0~3)
// → 路由到 db_2.short_link_1

追问⑲Level 4 · 深入原理

💬 "你考虑过安全问题吗？短链接有什么安全风险？"

💡 背景知识：短链接因为隐藏了原始 URL，天然有安全风险——用户不知道点击后会跳到哪里。攻击者可以利用短链接钓鱼、传播恶意链接、遍历攻击获取所有短码对应的 URL。这些都是面试中常见的安全拷打方向。

安全风险及防范措施：

风险	描述	当前项目的防范	进一步改进
短码遍历	攻击者尝试所有短码获取原始 URL	Sqids 混淆（非连续）+ 限流	加 CAPTCHA / IP 黑名单
恶意 URL	创建指向钓鱼/恶意网站的短链接	@URL 格式校验	接入 Google Safe Browsing API
DDoS 攻击	高频创建 / 高频访问	Redisson 分布式令牌桶限流	WAF + IP 级限流
信息泄露	统计数据被未授权访问	无认证保护	加 API Key / OAuth2 认证
注入攻击	URL 参数中包含恶意代码	MyBatis-Plus 参数化查询	加 URL 白名单域名校验

当前项目的安全机制：① 限流拦截器（防 DDoS）；② Sqids 短码混淆（防遍历）；③ 参数校验 @Valid + @URL（防非法输入）。不足：缺少认证鉴权和恶意 URL 检测。

追问⑳Level 6 · 生产实战

💬 "如果让你给这个项目写技术文档，你会包含哪些内容？"

💡 背景知识：技术文档是一个工程师系统思维的体现。好的技术文档不只是"怎么用"，还要回答"为什么这么设计"和"出了问题怎么排查"。面试官问这个问题，是看你能不能跳出代码，站在团队协作和知识沉淀的角度思考。

技术文档大纲：

一、项目概述：业务背景 + 核心功能 + 技术栈选型依据

二、架构设计：三层模块划分 + 整体架构图 + 读写链路图 + 中间件角色矩阵

三、核心模块详解：

3.1 ID 生成器：号段模式 + 双缓冲 + 乐观锁

3.2 短码编码：Sqids 库原理 + 编解码示例

3.3 缓存策略：三级查询 + TTL 随机偏移 + 空值缓存

3.4 统计系统：Redis INCR/HyperLogLog + 定时刷盘

3.5 限流方案：Redisson 分布式令牌桶

四、数据库设计：表结构 + 索引策略 + 分库分表预案

五、部署运维：Docker 部署 + Nginx 配置 + 监控告警 + 日志规范

六、性能基线：压测数据 + QPS/P99 基线 + 瓶颈分析

七、故障处理手册：Redis 宕机降级 + MySQL 主从切换 + 号段耗尽应急

八、演进规划：Caffeine 二级缓存 + Kafka 异步统计 + 链接管理后台

加分话术 🌟

面试中主动说出这些，直接加分

🌟 话术 1 — 读写比意识：

"短链接是典型的读多写少场景，读写比大概 100:1，所以我把优化重心放在读链路——三级查询 + 异步统计 + 禁止浏览器缓存保证统计准确。"

🌟 话术 2 — 防御性编程：

"我在每一层都做了防御：Controller 层有限流 + 参数校验；Service 层有布隆过滤器防穿透 + 空值缓存防穿透；ID 生成器有乐观锁重试 + 双缓冲防阻塞。"

🌟 话术 3 — 权衡取舍：

"统计用 HyperLogLog 而不是精确计数，是在精度和内存之间做了权衡——0.81% 的误差换来每个键只占 12KB 内存，百万短码也才 12GB。"

🌟 话术 4 — 知道不足：

"写流程目前不是事务性的，MySQL 写成功但 Redis 失败会导致短暂不一致。如果要改进，可以用 Canal 监听 binlog 异步同步到缓存，保证最终一致性。"

🌟 话术 5 — 技术选型有依据：

"选 Sqids 替代手写的 Base62 + BitShuffle，是因为 Sqids 内置了字母表混淆，不需要自己实现 bit shuffle，而且它保证零碰撞和可逆解码，比自己写的更可靠。"

🌟 话术 6 — 生产视角：

"我的号段步长是固定 1000，美团 Leaf 的动态步长会根据消费速率自动调整——QPS 高时步长变大减少 DB 访问，QPS 低时步长变小减少 ID 浪费。如果上生产我会加上这个优化。"

🌟 话术 7 — 异步的代价：

"异步统计用了 DiscardPolicy 拒绝策略，意味着高峰期可能丢弃部分统计数据。这是有意为之——宁可丢统计也不能影响重定向的主流程。如果要求统计不丢，可以改用 Kafka 持久化。"

🌟 话术 8 — 安全意识：

"短码用 Sqids 混淆后不是简单递增的，攻击者没法通过 +1 遍历所有短链接。再配合限流，每秒最多 100 次请求，暴力遍历 100 万个短码需要将近 3 小时。"

架构方案对比 🔬

短链接系统常见架构方案对比

以下对比了业界常见的短链接系统架构方案，帮助理解本项目的设计选择：

维度	本项目	美团短链	新浪 t.cn
ID 生成	号段双缓冲（自研）	Leaf-Segment + Snowflake	自增 ID + 分库
短码编码	Sqids (6位+)	Base62	Base62 + 随机盐
缓存策略	Redis 单级 + Bloom	Redis Cluster + 本地缓存	Memcached 集群
数据库	单 MySQL	MySQL 分库分表	MySQL + HBase
统计方案	Redis INCR + HLL	Kafka + Flink 实时	日志 + Hadoop 离线
限流	Redisson 令牌桶	Sentinel 集群限流	Nginx + Lua
QPS 级别	万级	百万级	十万级

关键差异分析：

① 缓存层：本项目只有 Redis 一级缓存，美团方案会加 Caffeine/Guava 本地缓存作为 L1，L1 命中率约 60%~80%，显著降低 Redis 压力。

② 统计系统：本项目用 Redis INCR 实时统计 + 定时刷盘，方案简单但不精确。美团方案用 Kafka 消息队列 + Flink 流式处理，能做到精确计数和实时分析。

③ 编码方案：Sqids 的优势是内置混淆、不可预测、可逆。Base62 更简洁但需要自己做 bit shuffle 或加盐。

补充Level 3 · 怎么实现

应用启动初始化流程

💡 背景知识：Spring Boot 应用启动后会执行 CommandLineRunner 的 run 方法。本项目利用这个机制完成两件事：① 初始化号段 ID 生成器；② 预热布隆过滤器。多实例部署时通过分布式锁保证布隆过滤器只加载一次。

// ShortLinkApplication.java — 启动初始化
@Override
public void run(String... args) {
    segmentIdGenerator.init();                      // ① 加载首个号段到 currentBuffer
    log.info("Segment ID generator initialized");

    long count = shortLinkMapper.selectCount(null);  // ② 查询已有短链接总数
    if (count > 0 && bloomFilter.count() == 0) {   // 有数据但布隆过滤器为空
        RLock lock = redissonClient.getLock(RedisKeyConstant.LOCK_BLOOM_INIT);
        // 分布式锁: waitTime=60s, leaseTime=120s
        // 只有获取到锁的实例执行加载，其他实例等待后直接使用共享的布隆过滤器
        boolean acquired = lock.tryLock(60, 120, TimeUnit.SECONDS);
        if (acquired && bloomFilter.count() == 0) {  // 双重检查
            // 分批加载: 每次 5000 条，只查 short_code 列，避免 OOM
            int batchSize = 5000;
            // LIMIT + OFFSET 分页查询 → bloomFilter.add()
        }
    }
}

启动流程要点：

① 号段初始化：每个实例各自从 DB 获取独立的号段，不需要分布式锁

② 布隆预热：使用分布式锁 + 双重检查，保证多实例只加载一次

③ 分批加载：5000 条一批，只查 short_code 列，防止大表全量 SELECT 导致 OOM

④ 锁超时设计：waitTime=60s（等待其他实例完成）、leaseTime=120s（防止大数据量时锁提前释放）

补充Level 2 · 怎么用

核心配置参数一览

# application.yml — 关键配置
shortlink:
  domain: http://localhost:8080          # 短链接域名前缀
  rate-limit:
    qps: 100                              # 全局 QPS 限制（所有实例共享）
  cache:
    base-ttl-hours: 24                    # 缓存基础 TTL 24 小时
    random-offset-seconds: 3600          # 随机偏移 0~3600 秒，防雪崩
  bloom:
    expected-insertions: 1000000         # 布隆过滤器容量 100 万
    false-probability: 0.0001            # 误判率万分之一

spring.datasource.hikari:
  maximum-pool-size: 20                  # 连接池最大 20 个连接
  minimum-idle: 5                        # 最小空闲 5 个连接
  connection-timeout: 3000               # 获取连接超时 3 秒

配置设计思路：

① 缓存 TTL 随机化：24h + random(0~3600s) = 24~25 小时，避免大量缓存同一秒过期

② 布隆过滤器容量：100 万 + 万分之一误判率 → 约占 Redis 内存 2.4MB

③ 连接池：HikariCP max=20，足够单实例 2000~3000 QPS 的写入需求

④ 限流：QPS=100 是全局共享的（RateType.OVERALL），多实例总共不超过 100/s

技术主管追问 · 必备Level 5 · 架构扩展

💬 "你这张 short_link 表如果数据量到了 10 亿条怎么办？怎么分库分表？"

💡 这是从"能用"到"能扛"的分水岭。技术主管问的不是八股文里的"分库分表概念"，而是你这个具体系统怎么分。

分片键的选择——为什么必须选 short_code 而不是 id：

分片键	读链路（GET /{shortCode}）	写链路（POST 创建）	结论
short_code ✅	直接命中分片，单库单表查询	insert 时 short_code 已知，直接写入目标分片	读写都能精确路由
id	查询条件是 short_code 不是 id → 全库扫描	insert 时 id 已知，写入没问题	读链路灾难

分片策略：

-- 分片方式：short_code 做 CRC32 取模 --
逻辑分片数 = 1024（2 的幂，方便后续扩容翻倍）
物理部署   = 16 库 × 64 表（初期可以 4 库 × 256 表，逻辑分片数不变）

路由算法：
  shard_index = CRC32(shortCode) % 1024
  db_index    = shard_index / 64    → 0~15，定位到哪个库
  table_index = shard_index % 64    → 0~63，定位到哪张表

-- 扩容时只需拆分物理库，逻辑分片数不变 → 数据迁移量小 --

号段表 id_segment 不分片——全局只有一行记录，写 QPS 极低（每 1000 次 ID 分配才写一次），单表即可。

布隆过滤器不受影响——布隆过滤器存的是 short_code 字符串，与分片无关。Redis 缓存也按 short_code 做 key，天然分散。

技术主管追问 · 必备Level 5 · 架构扩展

💬 "如果 QPS 从 100 到 10 万，你怎么扩？整个链路的瓶颈在哪？"

读链路（QPS 占比 99%+，核心瓶颈）扩展方案：

  客户端
    ↓
  Nginx 集群（LVS/DNS 轮询 → N 台 Nginx）
    ↓ 负载均衡（weight / ip_hash）
  Spring Boot 实例 × N（无状态，水平扩展）
    ↓
  Redis Cluster（6 节点起步，3 主 3 从）
    ↓ 按 slot 分片（CRC16(key) % 16384）
    ↓ 缓存命中率 > 99% → 极少打到 DB
  MySQL 主从（1 主 N 从，读走从库）

各组件承压能力和瓶颈分析：

组件	单实例极限	10 万 QPS 需要	瓶颈点
Nginx	~5 万 QPS	2~3 台	CPU（SSL 终止）
Spring Boot	~1 万 QPS（302 链路）	10~15 台	线程池、GC
Redis Cluster	~10 万 QPS/节点	3 主节点足够	网络带宽
MySQL	~5000 QPS 读	缓存命中 99% → 只有 1000 QPS 打到 DB → 1 从库足够	慢查询、连接数

写链路（QPS 占比 <1%）：创建短链接的 QPS 通常远低于读（创建一次，访问万次）。单 MySQL 主库 + 号段模式完全能承受。如果写 QPS 也要到万级 → 号段 step 调大（10000）+ MySQL 主库拆分。

统计链路（高 QPS 但可异步）：

当前方案：Redis INCR/PFADD → 定时刷盘 MySQL。10 万 QPS 下 Redis 无压力（INCR 是 O(1)），瓶颈在刷盘——单次刷盘要更新大量行。优化：引入 Kafka，异步统计事件 → 消费者批量聚合 → 批量 UPDATE MySQL（减少 DB 写次数）。

技术主管追问 · 必备Level 4 · 生产实战

💬 "短链接上线后，你怎么知道系统是健康的？你会监控哪些指标？"

三层监控体系：

层次	工具	核心指标
基础设施	Prometheus + Node Exporter	CPU / 内存 / 磁盘 IO / 网络
应用层	Spring Boot Actuator + Micrometer → Prometheus	接口 QPS、P99 延迟、线程池使用率、GC 暂停时间
业务层	自定义 Micrometer Counter/Gauge → Grafana	缓存命中率、布隆过滤器拦截率、号段剩余量

关键业务指标（必须监控）：

指标	采集方式	告警阈值
Redis 缓存命中率	resolve() 里 Counter: cache_hit / cache_miss / bloom_reject	< 95% 告警
布隆过滤器填充率	bloomFilter.count() / expectedInsertions	> 80% 告警（误判率上升）
号段剩余量	currentBuffer.remaining() 上报 Gauge	< 100 告警（即将耗尽）
302 重定向 P99 延迟	Micrometer Timer 在 RedirectController	> 50ms 告警
刷盘任务执行状态	每次刷盘成功/失败 Counter	连续 3 次失败告警
限流触发次数	RateLimitInterceptor 中 429 响应 Counter	突增告警（可能遭受攻击）

💡 面试中提到监控体系会让技术主管眼前一亮——这说明候选人有"把系统放到生产环境跑"的意识，而不只是"写完代码就完了"。

技术主管追问 · 加分Level 2 · 代码规范

💬 "我看你的代码里有几个可以优化的点，你自己注意到了吗？"

① ObjectMapper 重复创建：

RedirectService 和 ShortLinkService 各自 new ObjectMapper()。应该用 Spring 容器自动配置的 ObjectMapper Bean（Jackson AutoConfiguration），通过构造器注入。好处：全局一致的序列化配置（日期格式、空值处理），避免重复创建。

② buildCacheValue() 重复代码：

两个 Service 里有完全相同的 buildCacheValue() 方法。应该提取到 common 层的工具类（如 CacheValueHelper），或者抽成一个共享的缓存值构建器。面试时承认这个重复并说出优化方向即可。

③ @Transactional 缺失：

ShortLinkService.createShortLink() 的 insert → Redis SET → bloom add 三步没有事务保护。MySQL insert 应该加 @Transactional，Redis 和布隆过滤器的写入放在事务提交后（TransactionSynchronizationManager.registerSynchronization），失败时记录补偿日志。

延伸面试题 🔬

系统架构设计高频追问

以下是字节跳动、美团等大厂面试中，围绕短链接系统架构的常见延伸题目：

基础概念类：

1. 302 和 301 重定向有什么区别？为什么短链接要用 302？

2. 你知道短链接的读写比一般是多少吗？你怎么测出来的？

3. 为什么短码一般是 6~8 位？最多能生成多少个不重复的短码？

缓存与存储类：

4. 缓存穿透、缓存击穿、缓存雪崩分别怎么防？你的项目分别用了什么手段？

5. 布隆过滤器有误判怎么办？能删除元素吗？你用了什么方案？

6. Redis 和 MySQL 数据不一致了怎么办？你会用延迟双删还是 Canal？

高并发与扩展类：

7. 如果要支持自定义短码，怎么和自动生成的短码共存不冲突？

8. 如果要做多机房部署，ID 生成和数据同步怎么处理？

9. 如何实现短链接的"访问分析"——地域分布、设备类型、来源渠道？

算法与编码类：

10. Sqids 和 Base62 的区别是什么？为什么 Sqids 能保证零碰撞？

11. 如果不用 Sqids，用 MD5 取前 6 位做短码行不行？为什么？

12. 雪花算法和号段模式怎么选？各自适合什么场景？

📎 关联面试专题