4. 业务降级（二）：读降级策略与写降级策略

上一节我们讨论了业务降级的基本分类与触发条件。本节将深入剖析读降级与写降级的具体工程实现。读降级的目标是“在数据不可达或延迟过高时，仍能返回可接受的结果”；写降级的目标是“在写入压力超过阈值时，保证系统不崩溃且数据最终一致”。

4.1 读降级策略

读降级的核心思路是：用预先准备好的、或降级后的数据，替代实时查询。根据数据来源和实时性要求，读降级可分为缓存降级与静态化降级。

4.1.1 缓存降级

缓存降级是最常见的读降级手段。当数据库或下游服务不可用时，系统自动切换至缓存层提供数据。缓存降级分为三个层级：

4.1.2 静态化降级

静态化降级是将动态页面或数据预渲染为静态 HTML/JSON 文件，在动态服务不可用时直接返回静态内容。它适用于内容变化不频繁、但访问量巨大的场景（如首页、活动页、商品详情页）。

• 全量静态化：定时任务生成所有页面的静态文件，CDN 加速分发。降级时直接返回 CDN 缓存。
• 增量静态化：仅对热点页面或核心页面做静态化，非热点页面仍走动态渲染。降级时热点页面返回静态版本，非热点页面返回“服务繁忙”提示。
• 混合模式：动态渲染与静态文件共存，通过流量比例控制。降级时逐步增加静态文件返回比例。

4.2 写降级策略

写降级的目标是：在写入流量超过系统处理能力时，通过异步化、队列削峰等手段，将同步写入转换为异步处理，保证系统稳定性和数据最终一致性。写降级通常不直接丢弃数据，而是将写入请求暂存或降级处理。

4.2.1 异步化

异步化写降级将同步写入操作拆分为“接收请求”与“处理请求”两个阶段。接收阶段快速返回“已受理”，处理阶段在后台异步完成。

• 线程池异步：使用独立线程池处理写请求，主线程快速返回。适用于内部服务间调用。
• 消息队列异步：将写请求封装为消息发送至 MQ，消费者异步处理。适用于跨服务、跨系统的写操作。
• 事件驱动异步：通过事件总线发布写事件，多个订阅者并行处理。适用于复杂业务流程。

4.2.2 队列削峰

队列削峰是写降级中最常用的工程手段。它通过引入缓冲队列，将瞬时高峰流量平摊到更长的时间窗口内处理。

4.3 读/写降级策略对比

4.4 降级策略组合示例

以一个电商商品详情页为例，展示读/写降级的组合应用：

# 伪代码：商品详情页降级策略
def get_product_detail(product_id):
    # 1. 尝试实时数据
    if not is_degraded('product_detail'):
        try:
            data = db.query_product(product_id)
            cache.set(product_id, data, ttl=60)
            return data
        except (TimeoutError, ConnectionError):
            trigger_degradation('product_detail')
    
    # 2. 读降级：尝试缓存
    cached = cache.get(product_id)
    if cached:
        return cached
    
    # 3. 读降级：尝试静态化
    static = static_file.get(f'product_{product_id}.html')
    if static:
        return static
    
    # 4. 兜底：返回降级提示
    return fallback_template(product_id)

def create_order(order_data):
    # 1. 写降级判断
    if queue_depth() > THRESHOLD:
        # 2. 降级为异步写入
        mq.send('order_queue', order_data)
        return {'status': 'accepted', 'message': '订单已受理，请稍后查询'}
    
    # 3. 正常同步写入
    return db.insert_order(order_data)