System Design Interview

主流流式传输协议

1. HTTP 自适应流（点播 / 直播主流）
   1. HLS（HTTP Live Streaming）
      1. 苹果主导，基于 HTTP/TCP，将视频切为ts 分片（2–10 秒），用m3u8索引管理
      2. 支持自适应码率（ABR）、跨终端、CDN 友好、兼容性极强
      3. 延迟：普通版10–30 秒，低延迟版（LL-HLS）可至3–5 秒
   2. DASH（Dynamic Adaptive Streaming over HTTP）
      1. MPEG 标准，通用型自适应协议，切片为 MP4/TS，索引为MPD
      2. 比 HLS 更灵活，适配更多编码 / 加密 / 码率策略，被视为下一代通用协议
      3. 延迟：普通版10–30 秒，低延迟版（LL-DASH）可至3–5 秒
   3. HTTP-FLV
      1. 基于 HTTP 封装 FLV，延迟3–5 秒，适合直播拉流，浏览器需插件 / 播放器支持
2. 实时 / 推流协议（直播专用）
   1. RTMP/RTMPS
      1. Adobe 开发，基于 TCP，低延迟（1–3 秒），主要用于主播推流到服务器
      2. 浏览器原生不支持，需 Flash / 播放器，现多用于推流而非分发
   2. WebRTC
      1. 浏览器原生实时通信，延迟 <400ms，适合视频会议、低延迟互动直播
   3. SRT
      1. 低延迟、抗丢包，适合专业直播 / 广电传输，延迟 <1 秒
   4. RTSP/RTP
      1. 控制 + 传输分离，多用于监控、IPTV，需专用服务器，防火墙穿透差

常见视频网站技术方案

1. YouTube
   1. 点播 / 直播分发（观众端）：HLS 为主，DASH 为辅，适配 HTML5 播放器与多终端
   2. 直播推流（主播端）：RTMP/RTMPS为主，也支持 HLS、DASH 推流
2. Bilibili
   1. 点播 / 直播分发（观众端）：DASH 为主，HLS 兼容，适配多终端与自适应码率
   2. 直播推流（主播端）：RTMP为主，部分场景用 HTTP-FLV 拉流
3. 行业主流协议现状
   1. 点播 / 大规模直播分发：HLS 与 DASH 双主流，HLS 兼容性更强、DASH 更灵活
   2. 直播推流：RTMP/RTMPS仍是事实标准，WebRTC、SRT 在低延迟场景快速崛起
   3. 低延迟互动直播：WebRTC、LL-HLS、LL-DASH成为趋势

直播流媒体与点播的异同

1. 相同点
   1. 核心分发协议通用：HLS/DASH均可用于直播与点播，均支持ABR、CDN 分发、多终端兼容
   2. 均需视频转码、切片、元数据管理、缓存 / CDN等基础架构
2. 不同点

   维度	点播（VOD）	直播（Live）
   内容源	预录制、存储在服务器	实时采集、边录边传
   延迟要求	高（10–30 秒可接受）	中 / 低（普通 1–30 秒，互动 < 1 秒）
   用户控制	完整（暂停、快进、后退）	有限（仅暂停 / 播放，无快进）
   协议侧重	分发优先（HLS/DASH）	推流 + 分发并重（RTMP 推流 + HLS/DASH 分发）
   架构差异	转码后永久存储、按需拉取	实时转码、实时分发、无永久存储
   错误处理	可重试、容错空间大	低延迟、快速恢复、不可长时间重试

1. DAG 就是一套 “有先后顺序、没有循环、可并行” 的任务依赖关系图
2. DAG 任务调度 = 根据 DAG 定义的依赖关系，自动按顺序 / 并行执行一批任务，并处理：依赖、重试、失败、超时、资源分配、状态流转
3. 它解决的核心问题：一堆任务之间有复杂依赖，我不想手动一个个跑，也不想写一堆 if/else，让调度器自动帮我安排。

1. 任务依赖管理
2. 分布式执行
3. 容错与重试
4. 资源调度
5. 可视化与监控
6. 事件触发

1. 定义 DAG：用代码 / 界面画出任务和依赖
2. 提交 DAG：交给调度系统
3. 调度器解析：计算哪些任务可运行（依赖满足）
4. 放入任务队列
5. Executor / Worker 拉取执行
6. 更新状态
7. 触发下游任务
8. 全部完成 → DAG 结束
9. 失败 → 重试 / 告警 / 终止下游

1. 视频 / 音频媒体处理（YouTube、B 站、抖音）：典型 DAG 密集型场景，任务多、依赖复杂、必须并行
2. 大数据 ETL / 数据仓库：每天几万个任务，必须 DAG 调度
3. 机器学习流水线 MLOps：一步错，全流程作废，必须强依赖
4. CI/CD 构建发布：Argo Workflows / Tekton 都是 K8s 上的 DAG 调度
5. 批量计算、离线任务

1. Apache Airflow（最主流、行业标准）：Python 定义 DAG，灵活、生态极强、支持几乎所有系统
2. Apache DolphinScheduler（国产、易用、可视化）：拖拽式 DAG、中文友好、企业级稳定
3. Argo Workflows（K8s 原生）：适合 CI/CD、微服务任务、云转码
4. Taier（大数据专用、分布式）：分布式 DAG 调度系统，专注大数据任务管理
5. Goflow（轻量级、Go 语言）：轻量级 DAG 调度与监控平台，Go 编写、部署极简

1. 消息数据量爆炸，读写压力极大：社交聊天日消息可达百亿级，关系型数据库（MySQL）扛不住这种并发写入 + 海量存储，索引会急剧膨胀，查询长尾旧消息性能暴跌。
2. 访问模式极度适配键值存储：聊天只高频读最近消息，偶尔随机查历史（搜索、跳转），键值存储天然支持高吞吐写入、低延迟随机读、水平扩容，关系库做不到。
3. 一对一聊天读写比是一比一：发消息 = 写，看消息 = 读，纯键值读写性能远超关系型数据库的事务、联表开销。
4. 工业界已验证：Facebook Messenger（HBase）、Discord（Cassandra）、微信聊天记录均用键值存储，是行业标准方案。

1. 不会丢，反而比普通 MySQL 更可靠，键值存储本身就是分布式持久化存储，不是内存缓存：
   1. 消息写入先落盘，不是存在内存里；
   2. 集群默认多副本（如 3 副本），单节点挂了不丢数据；
   3. 支持 WAL 预写日志、故障自动容错、数据自愈；
   4. 配合聊天系统的消息确认机制（客户端 ACK + 服务器重试），进一步杜绝丢失。
2. 所谓的 “丢失”，是把键值存储当成 Redis 内存缓存了，而这里用的是持久化键值存储（HBase/Cassandra/LevelDB 系列），和数据库一样可靠。

1. 分布式键值存储天生支持跨区域多活部署：数据分片 + 跨区域副本、最终一致性、异地多活、就近写入与读取。

1. 优点：极快、微秒级、支持复杂结构
2. 缺点：
   1. 内存贵，存不了海量冷数据
   2. 持久化只是附加功能（AOF/RDB），不是设计核心
   3. 分布式扩容麻烦，不适合存几十 TB 的聊天历史
   4. 适合：缓存、在线状态、会话、限流、排行榜

1. 天生分布式、可水平扩容到几百台机器
2. 设计目标就是：海量存储 + 高写入吞吐 + 数据不丢 + 长期保存
3. 代表产品：
   1. HBase（Facebook Messenger 用）：分布式、可扩展、列式 KV 数据库；基于 Hadoop 生态，强持久化；海量存储，稳定性极强；支持按范围 scan（拉取最近 100 条消息）；部署重，依赖 Hadoop
   2. Cassandra（Discord 用）：去中心化分布式 KV，高可用之王；没有主节点，全部节点对等；写入性能在所有 KV 里第一梯队；一致性是最终一致（聊天完全够用）
   3. RocksDB / LevelDB（嵌入式高性能 KV）：本地高性能嵌入式 KV 存储引擎；常用来存：用户收件箱、本地消息队列、离线消息；微信的很多聊天组件就基于它
   4. TiKV（国产新一代分布式 KV）

      维度	Redis（内存 KV）	HBase/Cassandra（持久化分布式 KV）
      数据位置	内存为主	磁盘为主，内存缓存
      存储容量	小（GB 级）	极大（PB 级）
      持久化	附加能力	核心设计目标
      数据可靠性	一般，丢盘风险	极高，多副本 + WAL
      分布式扩容	复杂	简单，线性扩展
      跨区域支持	弱	极强
      适合场景	缓存、在线状态、热点数据	永久聊天历史、海量消息
      成本	极高（内存贵）	低（用普通硬盘）

1. 存储在线状态（user_id → online/offline）
2. 存储用户会话、连接信息
3. 缓存最近 N 条消息（提升读取速度）
4. 存储心跳、服务发现元数据
5. 做简单的消息暂存

1. 解耦发送方与接收方
2. 实现离线消息暂存
3. 支撑多设备消息同步
4. 群聊消息分发

1. 属于聊天服务层内部的中间组件
2. 介于聊天服务器、存储、推送服务之间

1. 不一定是重型 MQ，分两种实现，文档里是 “逻辑队列”：
2. 小型群聊（≤100 人）→ 逻辑队列（轻量实现）
   1. 不用独立部署 Kafka/RabbitMQ，直接在键值存储里用 “用户收件箱” 模拟队列
   2. 比如给每个用户建一个user_inbox列表，消息 ID 追加进去，本质就是 KV 里的一个列表结构，不是独立 MQ 服务。
3. 超大规模群聊 → 重型 MQ（Kafka）
   1. 万人以上大群才会用专业消息队列做分发。

1. 消息仅文本，体积极小：单条文本消息几百字节，百万消息也就几百 MB，存储 / 传输开销可以忽略。
2. 小群复制成本极低：群上限 100 人，一条消息复制 100 份，对现代服务器无压力。
3. 异步处理，不阻塞主线程：队列是异步消费，不会造成聊天服务器阻塞。
4. 只存消息 ID，不存全量消息：队列里只存message_id，真正消息体存在 KV 里，进一步降低开销。
5. 离线用户才排队，在线用户直接推送：不会无意义堆积消息。