短链接系统开发：302重定向与Redis缓存优化实践

1. 短链接系统开发日记：第六天核心实现与优化

今天是我开发短链接系统的第六天，主要完成了短链跳转的核心逻辑实现和性能优化。作为一个日更开发系列，我想记录下这个阶段遇到的技术挑战和解决方案，特别是302重定向的实现细节和Redis缓存策略的调整。

2. 短链跳转核心逻辑实现

2.1 302重定向机制设计

短链接系统的核心功能就是实现原始长链接到短链接的映射和跳转。我选择了302临时重定向而非301永久重定向，主要基于以下考虑：

1. 数据分析需求：302允许每次跳转都经过服务器，可以收集点击数据
2. 灵活修改：如果目标链接需要变更，302可以随时更新
3. SEO友好：避免权重分散到短链接

实现代码示例（基于Spring Boot）：

java复制@GetMapping("/{shortCode}")
public ResponseEntity<Void> redirect(@PathVariable String shortCode) {
    String originalUrl = urlService.getOriginalUrl(shortCode);
    if (originalUrl == null) {
        return ResponseEntity.notFound().build();
    }
    
    // 记录访问日志
    accessLogService.recordAccess(shortCode);
    
    return ResponseEntity.status(HttpStatus.FOUND)
            .location(URI.create(originalUrl))
            .build();
}

2.2 短码校验与异常处理

在实现跳转逻辑时，我增加了严格的短码校验：

1. 长度限制：固定6位字符（a-zA-Z0-9）
2. 格式校验：正则表达式^[a-zA-Z0-9]{6}$
3. 存在性检查：查询数据库前先做缓存检查

异常处理策略：

• 无效短码：返回404
• 已过期链接：返回410 Gone
• 服务不可用：503+重试机制

3. 性能优化实践

3.1 多级缓存架构

为了应对高并发访问，我设计了三级缓存：

1. 本地缓存（Caffeine）：<100ms的极速响应
2. Redis集群：分布式缓存，TTL=24h
3. 数据库（MySQL）：最终数据源

缓存更新策略：

java复制@Cacheable(value = "urlMapping", key = "#shortCode")
public String getOriginalUrl(String shortCode) {
    // 先查Redis
    String url = redisTemplate.opsForValue().get(shortCode);
    if (url != null) return url;
    
    // 再查数据库
    UrlMapping mapping = repository.findByShortCode(shortCode);
    if (mapping == null) return null;
    
    // 回填Redis
    redisTemplate.opsForValue().set(
        shortCode, 
        mapping.getOriginalUrl(),
        24, TimeUnit.HOURS);
    
    return mapping.getOriginalUrl();
}

3.2 连接池优化

发现Tomcat默认连接池在高并发下表现不佳，调整为HikariCP配置：

yaml复制spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000
      idle-timeout: 600000
      max-lifetime: 1800000

4. 监控与日志系统

4.1 访问统计实现

使用Redis的HyperLogLog统计UV，INCR统计PV：

java复制// UV统计（基于IP去重）
String uvKey = "shortcode:uv:" + shortCode;
redisTemplate.opsForHyperLogLog().add(uvKey, clientIp);

// PV统计
String pvKey = "shortcode:pv:" + shortCode;
redisTemplate.opsForValue().increment(pvKey);

4.2 日志收集优化

将访问日志异步写入Kafka再批量入库，避免直接写MySQL：

1. 日志格式：JSON包含时间戳、短码、UserAgent、Referer等
2. 分区策略：按短码hash分配分区
3. 消费组：2个实例并行消费

5. 踩坑记录与解决方案

5.1 缓存雪崩问题

现象：批量key同时过期导致数据库瞬时压力暴增

解决方案：

1. 基础TTL设置为24h
2. 对每个key添加随机120分钟偏移量
3. 永不过期的热点数据特殊处理

5.2 短码冲突处理

虽然62^6的组合很大，但仍需处理冲突：

1. 数据库唯一索引约束
2. 插入失败时自动重试3次
3. 每次重试生成新短码

java复制@Retryable(maxAttempts = 3, backoff = @Backoff(delay = 100))
public String createShortUrl(String originalUrl) {
    String shortCode = generateCode();
    UrlMapping mapping = new UrlMapping(shortCode, originalUrl);
    repository.save(mapping);
    return shortCode;
}

6. 明日开发计划

1. 实现API限流（Guava RateLimiter + Redis Lua）
2. 开发管理后台的基础框架
3. 研究基于地理位置的分析功能
4. 压力测试方案设计（JMeter场景）

今天的开发让我深刻体会到，短链接系统虽然看似简单，但要保证高并发下的稳定性和数据一致性，需要在架构设计上考虑很多细节。特别是缓存策略的选择和异常情况的处理，往往决定了系统的最终体验。