设计一个音视频存储与CDN分发系统，请从存储介质、数据分片、缓存策略、分发规则等方面进行设计。

快手音视频SDK开发工程师 📦 工程类难度：中等

答案

1) 【一句话结论】
设计音视频存储与CDN分发系统时，核心是通过分层存储（本地SSD缓存热数据+分布式对象存储存储冷数据）、动态数据分片（根据网络环境调整分片大小）、智能缓存策略（热点预热+负载均衡的边缘缓存）以及负载感知的分发规则，实现低延迟、高可用且成本优化的音视频分发。

2) 【原理/概念讲解】
老师口吻解释关键概念：

存储介质：本地SSD（企业级高速SSD，读写延迟低至ms级，适合高频访问的热数据，如最近7天访问量超过1000次的视频，因SSD随机读写性能好，能快速响应大量请求）；分布式对象存储（如MinIO，基于对象存储，支持高可用、容错，弹性扩展，适合冷数据，如历史视频，因冷数据访问频率低，用对象存储按需付费，成本更低）。
数据分片：将视频文件按固定大小（如1MB）切分为多个分片，用户下载时并行请求分片，提升大文件下载速度（类比：把大包裹拆成小包裹，用户可同时取多个小包裹，减少总等待时间）。分片大小需权衡并行效率与请求开销，1MB分片在典型4G网络（带宽10Mbps）下，并行下载10MB视频约1秒（比单线程快8倍），且分片数量（约10个）不会导致请求过多。
缓存策略：边缘CDN缓存（靠近用户，延迟低）+ 本地客户端缓存，采用24小时TTL+LRU淘汰旧数据；同时基于用户行为预测（时间衰减因子，权重随时间递减）进行热点数据预热，提前拉取热门视频到边缘，降低首次访问延迟。
分发规则：CDN智能路由（根据用户地理位置、网络状况选择最近边缘节点，优先返回缓存内容；网络波动时切换负载较低的节点，保证可用性）。

3) 【对比与适用场景】

对比项	本地SSD（企业级）	分布式对象存储（如MinIO）
定义	集中式高速存储设备，通过SAS/SATA接口连接	分布式架构，多节点存储，通过API访问，支持高可用
特性	读写延迟低（ms级），随机读写性能好，容量有限（几十TB）	弹性扩展，高可用（多副本），容量大（PB级），容错（节点故障不影响数据）
使用场景	热数据（高频访问，如7天内热门视频，访问量高，需快速响应）	冷数据（历史视频，访问频率低，如超过30天的视频，存储成本更低）
注意点	成本高（SSD价格贵），扩容需更换硬件，维护复杂	需管理节点（如MinIO集群），数据一致性依赖副本同步，冷数据访问时网络延迟可能影响性能

4) 【示例】
伪代码（分片存储与缓存预热及一致性检查）：

# 1. 视频分片存储与元数据记录（记录分片顺序和哈希）
def store_video_with_metadata(file_path, chunk_size=1*1024*1024):
    chunks = []
    metadata = {
        "hash": generate_file_hash(file_path),
        "chunks": [],
        "size": 0
    }
    with open(file_path, 'rb') as f:
        while True:
            chunk = f.read(chunk_size)
            if not chunk: break
            chunk_id = len(chunks) + 1
            store_to_minio(chunk_id, chunk)  # 存储到MinIO
            chunks.append(chunk_id)
            metadata["size"] += len(chunk)
    store_metadata(metadata)  # 存储元数据到Redis（包含分片顺序和哈希）
    return metadata

# 2. 热点视频缓存预热（基于用户行为预测，时间衰减因子）
def preheat_cache(video_id, user_history):
    hot_score = calculate_hot_score(user_history, video_id)  # 计算热度（权重随时间递减）
    if hot_score > THRESHOLD:  # 超过阈值视为热点
        chunks = get_video_chunks(video_id)  # 从MinIO获取分片
        for chunk in chunks:
            edge_cache.set(chunk, chunk, ttl=24*3600)  # 边缘缓存预热

# 3. 分发时一致性检查（验证分片顺序和内容哈希）
def fetch_video(video_id):
    chunks = []
    for chunk_id in get_chunk_ids(video_id):
        chunk = edge_cache.get(chunk_id)
        if not chunk:
            chunk = get_from_minio(chunk_id)  # 回源
            edge_cache.set(chunk_id, chunk, ttl=24*3600)
        chunks.append(chunk)
    metadata = get_metadata(video_id)  # 获取元数据（分片顺序和哈希）
    if sorted(chunks) != metadata["chunks"]:
        raise ConsistencyError("分片顺序不一致，播放断片")
    if generate_chunk_hash(chunk) != metadata["hash"]:
        raise ConsistencyError("分片内容校验失败，数据损坏")
    return chunks

# 4. 分发规则：负载感知路由（选择负载低的CDN节点）
def route_to_cdn(user_ip, video_id):
    cdn_nodes = get_cdn_nodes()  # 获取所有CDN节点信息（负载状态）
    available_nodes = [node for node in cdn_nodes if node['queue'] < 10 and node['cpu'] < 50]
    if available_nodes:
        return min(available_nodes, key=lambda x: x['distance'])  # 优先距离近的
    else:
        return max(cdn_nodes, key=lambda x: x['queue'])  # 选择队列最少的节点

5) 【面试口播版答案】
“面试官您好，针对音视频存储与CDN分发系统，我的核心设计思路是构建分层存储架构（本地SSD缓存热数据+分布式对象存储存储冷数据）、动态数据分片（根据网络环境调整分片大小）、智能缓存策略（热点预热+负载均衡的边缘缓存）以及负载感知的分发规则，实现低延迟、高可用且成本优化的音视频分发。具体来说：存储介质上，热数据（如7天内访问量超过1000次的视频）存企业级SSD，因为SSD读写延迟低（ms级），能快速响应高频请求；冷数据（历史视频）存分布式对象存储（如MinIO），弹性扩展，按需付费，成本更低。数据分片方面，视频按1MB大小切分，用户可并行下载分片，提升下载速度（比如10MB视频并行下载比单线程快约8倍），同时根据用户网络带宽动态调整分片大小，4G用户用1MB分片，5G用户用2MB分片，平衡并行效率与请求开销。缓存策略上，边缘CDN缓存+本地客户端缓存，采用24小时TTL+LRU淘汰旧数据；基于用户行为预测（时间衰减因子，权重随时间递减）预热热点视频，提前拉取到边缘，降低首次访问延迟。分发规则用CDN智能路由，结合用户地理位置和网络状况，优先返回缓存内容；同时检查CDN节点负载（如请求队列<10、CPU<50%），选择负载低的节点，避免高负载节点导致延迟。此外，通过元数据记录分片顺序和内容哈希，确保播放时无断片；用分布式锁（锁key=视频ID+版本号）应对缓存击穿，避免热点数据失效时大量请求冲击后端；CDN缓存刷新通过ETag或版本号，版本更新时更新哈希值，确保旧版本被正确清理，避免缓存污染。这样整体能实现低延迟、高可用的音视频分发。”

6) 【追问清单】

问题1：视频版本更新后，旧版本如何清理？
回答要点：通过版本号或哈希值标记，更新时生成新版本并更新哈希，旧版本标记为过期，CDN根据版本号判断是否回源，避免缓存污染。
问题2：数据分片大小如何确定？为什么选择1MB？
回答要点：分片大小需平衡并行下载效率与存储开销，1MB是经验值，在典型4G网络（带宽10Mbps）下，并行下载提升效率，且分片数量（约10个）不会导致请求过多；若分片过小（如100KB），分片数量多（100个），请求次数增加，可能增加CDN负载；过大（如2MB），并行效率降低。
问题3：缓存击穿或雪崩如何应对？
回答要点：缓存击穿用Redis分布式锁或令牌桶限流，避免热点数据失效时大量请求冲击后端；缓存雪崩用随机TTL（如1-24小时随机），避免大量数据同时失效。
问题4：如何保证数据一致性？
回答要点：分片存储时记录分片顺序元数据，CDN缓存时验证顺序，播放时按顺序组装，确保无断片；分布式存储用3副本，确保数据冗余。
问题5：存储成本如何控制？
回答要点：冷数据用对象存储（按需付费），热数据用SSD（固定成本），结合数据生命周期管理（如冷数据归档到 cheaper 存储），优化分片大小减少冗余。

7) 【常见坑/雷区】

坑1：忽略分片顺序导致播放断片，未验证分片列表的哈希或顺序。
雷区：未区分热冷数据，用单一存储介质（如HDD存储高频视频，延迟高）。
坑2：缓存策略单一，未结合热点预热，导致首次访问延迟高。
雷区：分发规则仅按地理位置选择，未考虑网络状况（如用户实际网络差时延迟仍高）。
坑3：未考虑缓存击穿/雪崩，导致系统过载。
雷区：分片存储时未处理网络包大小限制，导致分片过多或过少，影响下载效率。