当前位置：首页 > news >正文

100万QPS短链系统如何设计？

news 2025/8/2 4:45:54

前言

凌晨两点，监控大屏突然飙红——短链服务QPS突破80万！数据库连接池告急，Redis集群响应延迟突破500ms。

这不是演习，而是某电商平台大促的真实场景。

当每秒百万级请求涌向你的短链服务，你该如何设计系统？

今天这篇文章跟大家一起聊聊100万QPS短链系统要如何设计？

希望对你会有所帮助。

1 短链系统的核心挑战

首先我们一起看看设计一个高并发的短链系统，会遇到哪些核心的挑战。

如下图所示：

百万QPS下的三大生死关：

ID生成瓶颈：传统数据库自增ID撑不住百万并发
跳转性能黑洞：302重定向的TCP连接成本
缓存雪崩风险：热点短链瞬间击穿Redis

2 短链生成

2.1 发号器的设计

发号器是短链系统的发动机。

方案对比：

分段发号器实现（Java版）：

public class SegmentIDGen {private final AtomicLong currentId = new AtomicLong(0);private volatile long maxId;private final ExecutorService loader = Executors.newSingleThreadExecutor();public void init() {loadSegment();loader.submit(this::daemonLoad);}private void loadSegment() {// 从DB获取号段：SELECT max_id FROM alloc WHERE biz_tag='short_url'this.maxId = dbMaxId + 10000; // 每次取1万个号currentId.set(dbMaxId);}private void daemonLoad() {while (currentId.get() > maxId * 0.8) {loadSegment(); // 号段使用80%时异步加载}}public long nextId() {if (currentId.get() >= maxId) throw new BusyException();return currentId.incrementAndGet();}
}

关键优化：

双Buffer异步加载（避免加载阻塞）
监控号段使用率（动态调整步长）
多实例分段隔离（biz_tag区分业务）

2.2 短链映射算法

短码映射将长ID转换成62进制的字符串。

转换原理：

2000000000 = 2×62^4 + 17×62^3 + 35×62^2 + 10×62 + 8 = "Cdz9a"

原始ID: 2000000000，转换为62进制的值为Cdz9a。

// Base62编码（0-9a-zA-Z）
public class Base62Encoder {private static final String BASE62 = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";public static String encode(long id) {StringBuilder sb = new StringBuilder();while (id > 0) {sb.append(BASE62.charAt((int)(id % 62)));id /= 62;}return sb.reverse().toString();}// 测试：生成8位短码public static void main(String[] args) {long id = 1_000_000_000L;System.out.println(encode(id)); // 输出：BFp3qQ}
}

编码优势：

6位短码可表示 62^6 ≈ 568亿种组合
8位短码可表示 62^8 ≈ 218万亿种组合
无意义字符串避免被猜测

3 存储架构

3.1 数据存储模型设计

3.2 缓存层级设计

3.3 缓存击穿解决方案

// Redis缓存击穿防护
public String getLongUrl(String shortCode) {// 1. 布隆过滤器预检if (!bloomFilter.mightContain(shortCode)) {return null;}// 2. 查RedisString cacheKey = "url:" + shortCode;String longUrl = redis.get(cacheKey);if (longUrl != null) {return longUrl;}// 3. 获取分布式锁String lockKey = "lock:" + shortCode;if (redis.setnx(lockKey, "1", 10)) { // 10秒超时try {// 4. 二次检查缓存longUrl = redis.get(cacheKey);if (longUrl != null) return longUrl;// 5. 查数据库longUrl = db.queryLongUrl(shortCode);if (longUrl != null) {// 6. 回填Redisredis.setex(cacheKey, 3600, longUrl);}return longUrl;} finally {redis.del(lockKey);}} else {// 7. 等待重试Thread.sleep(50);return getLongUrl(shortCode);}
}

防护要点：

布隆过滤器拦截非法短码
分布式锁防止缓存击穿
双重检查减少DB压力
指数退避重试策略

4 跳转优化

4.1 Nginx层直接跳转

server {listen 80;server_name s.domain.com;location ~ ^/([a-zA-Z0-9]{6,8})$ {set $short_code $1;# 查询Redisredis_pass redis_cluster;redis_query GET url:$short_code;# 命中则直接302跳转if ($redis_value != "") {add_header Cache-Control "private, max-age=86400";return 302 $redis_value;}# 未命中转发到后端proxy_pass http://backend;}
}

性能收益：

跳转延迟从100ms降至5ms
节省后端服务器资源
支持百万级并发连接

4.2 连接池优化

连接池优化可以用Netty实现：

// Netty HTTP连接池配置
public class HttpConnectionPool {private final EventLoopGroup group = new NioEventLoopGroup();private final Bootstrap bootstrap = new Bootstrap();public HttpConnectionPool() {bootstrap.group(group).channel(NioSocketChannel.class).option(ChannelOption.SO_KEEPALIVE, true).handler(new HttpClientInitializer());}public Channel getChannel(String host, int port) throws InterruptedException {return bootstrap.connect(host, port).sync().channel();}// 使用示例public void redirect(ChannelHandlerContext ctx, String longUrl) {Channel channel = getChannel("target.com", 80);channel.writeAndFlush(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, longUrl));// 处理响应...}
}

优化效果：

TCP连接复用率提升10倍
减少80%的TCP握手开销
QPS承载能力提升3倍

5 百万QPS整体架构

百万QPS整体架构如下图所示：

核心组件解析：

1、接入层

CDN：缓存静态资源

Nginx：处理302跳转，本地缓存热点数据

2、缓存层

Redis集群：缓存短链映射

布隆过滤器：拦截非法请求

3、服务层

短链生成：分布式ID服务

映射查询：高并发查询服务

4、存储层

MySQL：分库分表存储映射关系

TiKV：分布式KV存储ID生成状态

6 容灾设计

6.1 限流熔断策略

基于Sentinel的熔断降级：

public class RedirectController {@GetMapping("/{shortCode}")@SentinelResource(value = "redirectService", fallback = "fallbackRedirect",blockHandler = "blockRedirect")public ResponseEntity redirect(@PathVariable String shortCode) {// 跳转逻辑...}// 熔断降级方法public ResponseEntity fallbackRedirect(String shortCode, Throwable ex) {return ResponseEntity.status(503).body("服务暂时不可用");}// 限流处理方法public ResponseEntity blockRedirect(String shortCode, BlockException ex) {return ResponseEntity.status(429).body("请求过于频繁");}
}

6.2 多级降级方案

使用多级降级方案：

保证服务的高可用。

6.3 数据分片策略

基于短码分库分表：

public int determineDbShard(String shortCode) {// 取短码首字母的ASCII值int ascii = (int) shortCode.charAt(0);// 分16个库return ascii % 16;
}public int determineTableShard(String shortCode) {// 取短码的CRC32值CRC32 crc32 = new CRC32();crc32.update(shortCode.getBytes());// 每库1024张表return (int) (crc32.getValue() % 1024);
}

这里成了16个库，每个库有1024张表。