301 vs 302 的抉择

大客户的”特殊要求”

Redis 缓存上线后,系统的响应时间稳定在 5ms 左右。我正准备庆祝,一个电商大客户找上门来。

“你们的短链接服务不错,“他们的技术负责人在电话里说,“但我们有个要求——必须使用 301 永久重定向。”

我愣了一下:“301?但我们现在用的是 302……”

“我们做 SEO 优化,需要把权重传递给目标页面。“他的语气很坚定,“如果用 302,搜索引擎不会传递权重,这对我们很重要。”

挂了电话,我陷入沉思。301 vs 302,这个看似简单的选择,背后是性能、SEO、统计准确性的复杂权衡。

在缓存环境下重新审视

之前我选择 302 的理由很简单：需要统计点击,需要灵活修改目标 URL。但现在有了 Redis 缓存,情况变得复杂了。

301 + 浏览器缓存

第一次访问:
客户端 → 短链接服务 → 301 → 目标 URL
浏览器缓存: short.url/abc → target.com (永久)

第二次访问:
客户端 → 浏览器缓存 → 目标 URL (不经过服务器)
速度: 0ms

优势:

• 极快:浏览器缓存后,不再请求服务器
• SEO 友好:搜索引擎会把权重传递给目标页面

劣势:

• 统计缺失:无法统计缓存后的点击
• 无法修改:即使修改数据库,浏览器仍然跳到旧地址

302 + Redis 缓存

每次访问:
客户端 → Nginx → Redis (5ms) → 302 → 目标 URL
同时: 异步写入统计

速度: ~5ms
统计: 准确记录每次点击

优势:

• 准确统计:每次请求都经过服务器
• 灵活可变:随时修改目标 URL

劣势:

• 比 301 慢:每次都要访问服务器
• SEO 不友好:权重不传递

性能对比表

我画了张对比表:

关键发现: 302 + Redis 的性能已经足够好(5ms),虽然不如 301 的二次访问(0ms),但对于短链接场景,5ms 完全可以接受。

SEO 权重到底多重要?

为了搞清楚 SEO 的影响,我专门咨询了做 SEO 的朋友老张。

“短链接场景下,SEO 权重传递不是核心需求。“他看了我的架构图后说。

“为什么?”

“你想,用户在什么场景下会点击短链接?”他反问。

“社交媒体、邮件、广告……”

“对,这些都是外链。“他解释道,“搜索引擎对外链的权重传递本来就很谨慎。而且,短链接服务本身就是一个中转层,真正的价值在于统计和追踪,而不是 SEO。”

他给我展示了 Google 的官方文档:

Google 对重定向的态度:
- 301: 传递大部分权重(约 90-99%)
- 302: 不传递权重,但也不会惩罚

对于短链接:
- 搜索引擎知道这是跳转服务
- 不会因为使用 302 而惩罚
- 关键是目标页面本身的质量

“那是不是说,我用 302 也没问题?”

“对。除非你的客户是做内容网站的,需要通过社交媒体分享来积累 SEO 权重。但大多数情况下,短链接的价值在于数据,不在 SEO。“

电商客户的需求分析

我回到大客户的需求。他们做电商,分享链接主要在:

• 社交媒体活动
• KOL 推广
• 邮件营销

“这些场景,SEO 权重传递真的重要吗?”我自问。

仔细一想:

• 社交媒体链接: 大部分是 nofollow,本来就不传递权重
• 广告链接: 也不传递权重
• 邮件链接: 更不存在 SEO 问题

结论: 这个客户对 SEO 的需求,可能是误解。

我的最终决策

经过深思熟虑,我做了决定:坚持默认使用 302,但给大客户提供可选的 301 模式。

数据库改造

首先,在数据库中增加重定向类型字段:

# 数据库迁移
ALTER TABLE url_mapping 
ADD COLUMN redirect_type ENUM('301', '302') DEFAULT '302';

# 索引优化
CREATE INDEX idx_redirect_type ON url_mapping(redirect_type);

配置驱动的重定向

修改重定向逻辑,支持可配置:

from flask import Flask, redirect, request
from enum import Enum

class RedirectType(Enum):
    PERMANENT = 301
    TEMPORARY = 302

def redirect_handler(short_code):
    """
    根据配置选择重定向类型
    """
    # 从 Redis 缓存中查询
    cache_key = f"url:{short_code}"
    cached = redis.hgetall(cache_key)
    
    if cached:
        long_url = cached['long_url']
        redirect_code = int(cached.get('redirect_type', 302))
    else:
        # 从数据库查询
        record = db.query(
            "SELECT long_url, redirect_type FROM url_mapping WHERE short_code = %s",
            (short_code,)
        )
        
        if not record:
            return "Not Found", 404
        
        long_url = record['long_url']
        redirect_code = record['redirect_type']
        
        # 写入缓存,TTL 根据重定向类型设置
        ttl = 86400 * 30 if redirect_code == 301 else 3600  # 301 缓存 30 天
        redis.hset(cache_key, mapping={
            'long_url': long_url,
            'redirect_type': redirect_code
        })
        redis.expire(cache_key, ttl)
    
    # 记录统计(仅 302 需要)
    if redirect_code == 302:
        record_click_async(short_code, request)
    
    # 执行重定向
    return redirect(long_url, code=redirect_code)

用户 API

创建短链接时,允许指定重定向类型:

from pydantic import BaseModel, validator

class CreateLinkRequest(BaseModel):
    long_url: str
    redirect_type: str = '302'  # 默认 302
    
    @validator('redirect_type')
    def validate_redirect_type(cls, v):
        if v not in ['301', '302']:
            raise ValueError('redirect_type must be 301 or 302')
        return v

@app.route('/api/v1/shorten', methods=['POST'])
def create_short_link():
    data = request.json
    req = CreateLinkRequest(**data)
    
    short_code = generate_short_code(req.long_url)
    
    # 存入数据库
    db.execute(
        """INSERT INTO url_mapping 
           (short_code, long_url, redirect_type, created_at)
           VALUES (%s, %s, %s, NOW())""",
        (short_code, req.long_url, req.redirect_type)
    )
    
    # 如果是 301,预热缓存
    if req.redirect_type == '301':
        redis.hset(f"url:{short_code}", mapping={
            'long_url': req.long_url,
            'redirect_type': 301
        })
    
    return jsonify({
        'short_url': f'https://short.url/{short_code}',
        'redirect_type': req.redirect_type,
        'message': get_redirect_message(req.redirect_type)
    }), 201

def get_redirect_message(redirect_type):
    messages = {
        '301': '永久重定向。浏览器会缓存,性能最佳,但无法统计后续点击。',
        '302': '临时重定向。每次访问都会统计,支持随时修改目标 URL。'
    }
    return messages.get(redirect_type, '')

管理界面

给用户提供选择界面:

// 前端组件
function CreateLinkForm() {
  const [redirectType, setRedirectType] = useState('302');
  
  return (
    <form>
      <input type="url" placeholder="长链接" />
      
      <div className="redirect-type-selector">
        <label>
          <input 
            type="radio" 
            value="302" 
            checked={redirectType === '302'}
            onChange={e => setRedirectType(e.target.value)}
          />
          <strong>临时重定向 (302)</strong>
          <small>推荐。支持统计和修改。</small>
        </label>
        
        <label>
          <input 
            type="radio" 
            value="301" 
            checked={redirectType === '301'}
            onChange={e => setRedirectType(e.target.value)}
          />
          <strong>永久重定向 (301)</strong>
          <small>适合 SEO 优化。浏览器会缓存。</small>
        </label>
      </div>
      
      <button type="submit">创建短链接</button>
    </form>
  );
}

统计准确性的价值

302 的最大优势是统计准确性。这为后续的数据分析打下了基础。

点击追踪

每次重定向,我都能记录:

def record_click_async(short_code, request):
    """
    异步记录点击数据
    """
    click_data = {
        'short_code': short_code,
        'timestamp': time.time(),
        'ip': request.remote_addr,
        'user_agent': request.headers.get('User-Agent'),
        'referer': request.headers.get('Referer', ''),
        'country': get_country_from_ip(request.remote_addr),
        'device': parse_device(request.headers.get('User-Agent'))
    }
    
    # 写入消息队列
    mq.publish('click_events', json.dumps(click_data))

数据分析

有了这些数据,我能提供:

实时统计:
- 过去 1 小时点击量
- 过去 24 小时点击量
- 过去 7 天点击量

用户画像:
- 地理分布: 中国 60%, 美国 20%, 日本 10%
- 设备类型: 移动端 70%, 桌面端 30%
- 来源分析: 微信 40%, 微博 30%, 直接访问 20%

趋势分析:
- 点击高峰时段
- 周期性规律
- 异常流量检测

这些数据,是短链接服务的核心价值。

如果用 301,浏览器缓存后,这些数据都会丢失。

给客户的解释

我给电商客户发了一封邮件:

主题: 关于 301 重定向的建议

您好,

关于使用 301 永久重定向的需求,我做了详细的技术分析。

301 的优势是 SEO 权重传递,但有以下限制:
1. 浏览器会永久缓存,无法修改目标 URL
2. 无法统计缓存后的点击数据
3. 对社交媒体链接,SEO 效果有限(大部分是 nofollow)

对于您的电商场景,我建议:
- 营销活动链接: 使用 302,便于统计和修改
- 官方固定链接: 可以使用 301

我们支持两种模式,您可以根据需要选择。

附件是详细的技术对比文档。

Best,
短链接团队

客户很快回复了:“理解了,我们用 302。数据统计对我们更重要。“

性能与功能的平衡

最终,我的架构是这样的:

双层缓存策略

def smart_redirect(short_code):
    """
    智能重定向:根据配置选择最优策略
    """
    # 1. 查询缓存
    cache_key = f"url:{short_code}"
    cached = redis.hgetall(cache_key)
    
    if cached:
        long_url = cached['long_url']
        redirect_code = int(cached['redirect_type'])
    else:
        # 2. 查询数据库
        record = db.query_one(
            "SELECT long_url, redirect_type FROM url_mapping WHERE short_code = %s",
            (short_code,)
        )
        
        if not record:
            return "Not Found", 404
        
        long_url = record['long_url']
        redirect_code = record['redirect_type']
        
        # 3. 写入缓存
        # 301 缓存更久,因为不会改变
        ttl = 86400 * 30 if redirect_code == 301 else 3600
        redis.hset(cache_key, mapping={
            'long_url': long_url,
            'redirect_type': redirect_code
        })
        redis.expire(cache_key, ttl)
    
    # 4. 统计(仅 302)
    if redirect_code == 302:
        record_click_async(short_code)
    
    # 5. 重定向
    return redirect(long_url, code=redirect_code)

性能监控

@app.route('/<short_code>')
def redirect_endpoint(short_code):
    start_time = time.time()
    
    try:
        result = smart_redirect(short_code)
        
        # 记录响应时间
        duration = (time.time() - start_time) * 1000
        metrics.histogram('redirect.duration', duration, tags=[
            f'redirect_type:{result[1]}'
        ])
        
        return result
    except Exception as e:
        logger.error(f"Redirect error: {e}")
        return "Internal Server Error", 500

监控面板

实时监控:
├─ 总请求数: 10,234,567
├─ 301 重定向: 1,234,567 (12%)
├─ 302 重定向: 8,999,900 (88%)
└─ 平均响应时间: 4.2ms

缓存命中率:
├─ Redis 缓存: 98.5%
└─ 数据库查询: 1.5%

错误率: 0.01%

本章小结

301 vs 302 的权衡:

最终方案:

• 默认 302: 满足统计需求和灵活性
• 支持 301: 作为高级功能,给有 SEO 需求的客户
• Redis 缓存: 优化 302 的性能,达到可接受的响应时间
• 用户选择: 提供清晰的文档,让用户根据场景选择

核心认知:

• 短链接服务的价值在于数据,不在 SEO
• 性能优化可以用缓存解决,不必牺牲功能
• 给用户选择权,而不是替用户做决定

练习题

练习 1

如果你的短链接服务主要服务于社交媒体分享(用户分享文章、视频等),应该选择 301 还是 302? 为什么?

场景: 用户分享了一篇博客文章
- 使用 301 重定向到 blog.example.com/article-1
- 后来文章 URL 改为 blog.example.com/article-1-updated
- 由于浏览器缓存了 301,用户仍然跳到旧 URL
- 用户体验差,且无法统计

- 可以随时修改目标 URL
- 准确统计每次点击
- 通过 Redis 缓存,性能不输 301
- SEO 权重虽然不是最优,但社交媒体本身权重高,影响有限

练习 2

设计一个 API,让用户可以选择重定向类型,并说明每种类型的适用场景。

from flask import Flask, request, jsonify
from enum import Enum

class RedirectType(str, Enum):
    TEMPORARY = "temporary"
    PERMANENT = "permanent"
    SMART = "smart"

@app.route('/api/v1/shorten', methods=['POST'])
def create_short_link():
    data = request.json
    
    long_url = data.get('url')
    redirect_type = data.get('redirect_type', 'temporary')
    domain = data.get('domain', 'short.url')
    
    # 参数验证
    if redirect_type not in [t.value for t in RedirectType]:
        return jsonify({
            'error': 'Invalid redirect_type',
            'valid_options': ['temporary', 'permanent', 'smart']
        }), 400
    
    # 生成短链接
    short_code = generate_short_code(long_url)
    
    # 存储
    db.execute(
        """INSERT INTO url_mapping
           (short_code, long_url, redirect_type, created_at)
           VALUES (%s, %s, %s, NOW())""",
        (short_code, long_url, redirect_type)
    )
    
    return jsonify({
        'short_url': f'{domain}/{short_code}',
        'redirect_type': redirect_type,
        'redirect_type_info': get_redirect_info(redirect_type)
    }), 201

def get_redirect_info(redirect_type):
    """返回重定向类型的说明"""
    info = {
        'temporary': {
            'http_code': 302,
            'description': '临时重定向,每次访问都会请求服务器',
            'use_cases': [
                '需要统计点击',
                '可能修改目标 URL',
                'A/B 测试',
                '临时活动页面'
            ],
            'pros': ['灵活', '统计准确', '可修改'],
            'cons': ['SEO 权重不传递', '需要服务器请求']
        },
        'permanent': {
            'http_code': 301,
            'description': '永久重定向,浏览器会缓存',
            'use_cases': [
                '永久不变的链接',
                '需要 SEO 权重传递',
                '域名迁移',
                '官方固定链接'
            ],
            'pros': ['SEO 友好', '性能更好', '浏览器缓存'],
            'cons': ['无法修改目标', '统计不准确']
        },
        'smart': {
            'http_code': '301/302',
            'description': '智能选择,系统自动判断',
            'use_cases': ['不确定选什么时使用'],
            'logic': [
                '新链接默认 302',
                '90 天未修改自动升级为 301',
                '用户可编辑的保持 302'
            ]
        }
    }
    return info.get(redirect_type, {})

# 创建临时重定向(默认)
curl -X POST https://api.short.url/api/v1/shorten \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/page"}'

# 创建永久重定向
curl -X POST https://api.short.url/api/v1/shorten \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/page",
    "redirect_type": "permanent"
  }'

# 智能模式
curl -X POST https://api.short.url/api/v1/shorten \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/page",
    "redirect_type": "smart"
  }'

流量洪峰的隐患

性能优化完成了,301 vs 302 的权衡也解决了。系统运行得越来越稳定,用户增长迅速。

直到有一天,一个热门短链接在社交媒体上爆了。

“某明星在微博发了一条短链接,瞬间带来了数万请求。“值班同事在群里喊道,“服务器负载飙升到 80%!”

我看着监控面板,心跳加速。虽然 Redis 缓存扛住了大部分请求,但单一热门链接的瞬间流量,仍然可能压垮系统。

单个短链接的流量集中,比分散的流量更可怕。

我需要更激进的优化策略……