如何设计一个短链接生成系统？

Question

如何在高并发场景下保证短链接生成的唯一性和高性能？系统需支持每秒数万次请求，传统数据库自增ID易暴露数量且性能受限，而分布式ID生成方案（如Snowflake）又不便于反向查询。同时，哈希冲突、缓存击穿、键值存储选型等问题也影响系统的稳定性与响应延迟。

Answer 1

一、短链接系统的核心挑战与设计目标

在高并发场景下，短链接服务需支持每秒数万次请求，其核心挑战包括：唯一性保证、高性能生成、低延迟访问以及可扩展性。传统数据库自增ID虽能保证唯一性，但存在暴露业务量、性能瓶颈（如锁竞争、写入延迟）等问题；而Snowflake等分布式ID方案虽具备高性能和时序性，但生成的ID较长且不利于反向解析原始URL。

此外，短链接通常通过哈希算法映射长链，可能引发哈希冲突；大量热点链接易导致缓存击穿；存储层选型不当则影响读写吞吐与持久化效率。因此，系统需综合考虑ID生成策略、冲突处理机制、缓存架构与底层存储技术。

二、从基础到进阶：短链接生成的技术演进路径

• 阶段1：数据库自增 + Base62编码 —— 简单直观，但暴露数据规模，写入成为瓶颈。
• 阶段2：MD5/SHA1哈希截取 —— 快速生成短码，但存在哈希碰撞风险，需二次校验。
• 阶段3：布隆过滤器预检 + Redis去重 —— 提前拦截已存在哈希，降低数据库压力。
• 阶段4：双Buffer异步发号机制 —— 预生成短码池，实现毫秒级响应。
• 阶段5：混合ID策略（Snowflake + 映射表） —— 利用Snowflake高效生成全局唯一ID，再通过映射表支持反向查询。

三、分布式环境下唯一性保障的关键技术方案

方案	优点	缺点	适用场景
数据库自增ID	绝对唯一，简单可靠	性能差，易暴露数量	低频短链服务
Snowflake ID	高性能，分布式无锁	长度固定，难反向解析	需快速发号的中台系统
Hash(Base64(MD5))	可逆性好，便于比对	有冲突概率	内容去重类平台
Redis INCR + 缓存穿透防护	原子操作，速度快	单点风险，需持久化	中小规模集群
号段模式（Segment ID）	批量获取，减少DB交互	需维护号段分配服务	大型互联网应用

四、高性能架构设计：缓存与存储协同优化

为应对每秒数万请求，必须引入多级缓存体系：

1. 使用Redis作为一级缓存，存储“短码 → 原始URL”映射，TTL设置合理过期时间。
2. 采用本地缓存（Caffeine/Ehcache）缓存热点链接，减少网络开销。
3. 针对缓存击穿问题，实施如下策略：
   • 设置互斥锁（Mutex Key），仅允许一个线程回源加载。
   • 对高频短码设置永不过期或后台异步刷新。
   • 使用布隆过滤器拦截非法请求，防止恶意刷量。
4. 持久层推荐使用Key-Value数据库如TiKV或Amazon DynamoDB，支持水平扩展与强一致性读写。

五、代码示例：基于号段模式的短码预生成服务

@Component
public class ShortLinkSegmentService {
    private Queue<String> codePool = new ConcurrentLinkedQueue<>();
    private final int POOL_THRESHOLD = 1000;
    private final String SEGMENT_LOCK = "segment:lock";

    @Scheduled(fixedDelay = 1000)
    public void refillPool() {
        if (codePool.size() < POOL_THRESHOLD) {
            try {
                RLock lock = redissonClient.getLock(SEGMENT_LOCK);
                if (lock.tryLock()) {
                    List<String> newCodes = generateBatchCodes(5000); // 批量生成Base62短码
                    codePool.addAll(newCodes);
                }
            } finally {
                lock.unlock();
            }
        }
    }

    public String getNextCode() {
        return codePool.poll();
    }
}

六、系统流程图：短链接生成与解析全流程

graph TD A[用户提交长链接] --> B{是否已存在?} B -- 是 --> C[返回已有短码] B -- 否 --> D[获取唯一短码] D --> E[写入Redis缓存] E --> F[异步持久化到KV存储] F --> G[返回短链接] H[用户访问短链接] --> I{缓存是否存在?} I -- 存在 --> J[重定向至原URL] I -- 不存在 --> K[查数据库] K -- 找到 --> L[回填缓存] L --> J K -- 未找到 --> M[返回404]