设计一个能够处理百万级并发音视频流的分布式架构，请从负载均衡、数据分片、缓存策略、容灾机制等方面进行阐述。

1) 【一句话结论】
针对百万级并发音视频流，采用“分层负载均衡（应用层Nginx+网络层LVS）、双维度数据分片（用户ID+时间窗口）、分布式缓存（带TTL与预热）、多活容灾（低延迟DC优先）”的分布式架构，通过智能调度与状态同步，保障低延迟、高可用，并控制跨数据中心延迟对音视频体验的影响。

2) 【原理/概念讲解】

• 负载均衡：用于分发请求，减少单点压力。应用层用Nginx（HTTP协议，支持IP哈希、权重），网络层用LVS（四层/七层，无状态，加速）。类比：餐厅服务员分桌，不同服务员负责不同区域，避免某桌人太多，且LVS像后厨直接分菜，更快。
• 数据分片：将海量音视频流分散到多个节点。按用户ID（用户专属流）+时间窗口（如按小时分片）双维度，用一致性哈希（结合虚拟节点）避免热点。每个分片节点处理部分用户流，通过消息队列同步状态变更，保障最终一致性。
• 缓存策略：用Redis集群缓存热点数据（用户信息、实时统计），设置TTL并做预热（启动时预加载），用分布式锁（如Redis SETNX）防雪崩（并发写入时锁控制）。
• 容灾机制：多数据中心部署，主DC故障时自动切换到备用DC。通过ZooKeeper/etcd同步状态，优先选择RTT（往返时间）低的DC（如用户所在区域），切换延迟控制在秒级内，影响少量请求。

3) 【对比与适用场景】

• 负载均衡方案对比：
  | 方案 | 定义 | 特性 | 使用场景 | 注意点 |
  |---|---|---|---|---|
  | Nginx（应用层） | 基于HTTP的负载均衡 | 支持多种算法（轮询、IP哈希、权重），配置灵活 | Web应用、API网关 | 需处理HTTP协议，可能增加延迟 |
  | LVS（网络层） | 四层/七层负载均衡 | 速度快，无状态，适合高并发 | 大流量、低延迟音视频流 | 配置复杂，需内核支持 |
• 缓存策略对比：
  | 策略 | 定义 | 特性 | 使用场景 | 注意点 |
  |---|---|---|---|---|
  | LRU | 最近最少使用 | 优先淘汰最久未用 | 热点数据（用户信息） | 可能淘汰重要数据 |
  | 主动预热 | 启动时预加载 | 减少首次访问延迟 | 热点数据 | 需预知热点 |
  | 分布式锁 | 控制并发写入 | 防雪崩 | 高并发写入 | 可能增加延迟 |

4) 【示例】

• 数据分片（双维度+一致性哈希）：

# 一致性哈希分片（用户ID+时间窗口）
import hashlib
from datetime import datetime

def get_shard(user_id, timestamp, num_shards=100):
    hash_val = int(hashlib.md5(f"{user_id}-{timestamp}".encode()).hexdigest(), 16)
    return hash_val % num_shards
# 用户A（123）在2024-01-01 10:00访问，分片到shard0；用户B（456）在10:01访问，分片到shard1

• 缓存预热（启动时预加载）：

# Redis缓存预热脚本（伪代码）
import redis
r = redis.Redis(host='cache1', port=6379)
hot_users = ['user1', 'user2', 'user3']  # 热点用户列表
for user in hot_users:
    r.set(f"user:{user}:info", f"info_{user}")
print("缓存预热完成")

5) 【面试口播版答案】
“针对百万级并发音视频流，我设计的架构核心是分层负载均衡、智能分片、缓存防护与容灾。首先，负载均衡分应用层（Nginx用IP哈希保持会话，网络层LVS用四层加速），确保请求快速分发。数据分片采用用户ID+时间窗口双维度，用一致性哈希避免热点，每个分片节点处理部分用户流。缓存用Redis集群，设置TTL并做预热，同时用分布式锁防雪崩。容灾部署多活数据中心，优先选择低延迟的DC（如用户所在区域），通过ZooKeeper同步状态，切换时延迟控制在秒级内，影响少量请求。整体通过水平扩展，保障低延迟、高可用，并控制跨数据中心延迟对音视频体验的影响。”

6) 【追问清单】

• 问：跨数据中心部署时，如何控制网络延迟对音视频流质量的影响？
  回答要点：优先选择与用户地理位置相近的低延迟数据中心（如通过用户IP判断，就近部署），并监控RTT（往返时间），若延迟过高（如超过100ms），触发降级策略（如切换到本地缓存或降级为标清流）。
• 问：数据分片后，如何保障音视频流的状态一致性（如用户在线状态）？
  回答要点：采用最终一致性模型，通过消息队列（如Kafka）同步状态变更，分片节点定期拉取最新状态，确保用户在线状态在分片间一致。
• 问：缓存雪崩如何解决？具体措施有哪些？
  回答要点：设置合理的TTL（如5分钟），启动时预加载热点数据（缓存预热），并发写入时用分布式锁（如Redis SETNX）控制并发，避免缓存全空导致雪崩。
• 问：容灾切换的延迟如何控制？切换时如何保证用户体验？
  回答要点：通过只读副本或熔断机制，切换时只影响少量请求（如切换到备用DC的只读节点），延迟控制在秒级内，不影响核心音视频流。
• 问：负载均衡算法选择？为什么选择IP哈希而不是轮询？
  回答要点：IP哈希用于保持用户会话一致性（同一用户请求始终到同一节点），适合音视频流（需要会话保持），而轮询可能导致用户切换节点，影响流连续性。

7) 【常见坑/雷区】

• 负载均衡只考虑轮询，未考虑音视频流的会话保持需求，导致用户流切换节点，影响体验。
• 数据分片未考虑时间维度，导致同一时间窗口内所有用户请求集中到同一分片，引发热点，性能下降。
• 缓存未做预热，导致首次访问延迟高，影响音视频流启动速度。
• 容灾切换延迟过长（如分钟级），影响用户体验，未考虑低延迟切换策略。
• 未考虑跨数据中心网络延迟，导致RTT过高（如超过200ms），音视频流卡顿。