设计一个支持百万级用户同时在线的在线直播课系统，需要考虑哪些核心组件和技术选型？请从高并发处理、实时通信、容错机制等方面展开说明。

好未来基础平台难度：困难

答案

1) 【一句话结论】
核心是构建基于微服务+分布式架构的直播系统，通过负载均衡、缓存、数据库分库分表处理高并发，采用WebRTC/RTMP保障低延迟实时通信，并设计熔断、降级等容错机制，确保百万级用户稳定运行。

2) 【原理/概念讲解】

高并发处理：
负载均衡（如Nginx/HAProxy）分发请求，避免单点压力；Redis缓存热点数据（如用户信息、直播状态），减少数据库压力；数据库分库分表（按用户ID哈希分表）水平扩展；消息队列（如Kafka/RabbitMQ）解耦服务，异步处理非实时任务（如日志、统计）。
类比：高并发像高峰期地铁，负载均衡是调度员分配列车，缓存是提前准备餐食，分库分表是建多个车站，消息队列是快递驿站，解耦服务间依赖。
实时通信：
核心是低延迟传输，常用协议WebRTC（端到端加密，低延迟约100ms，适合1v1/小组互动）和RTMP（中心化流媒体协议，延迟约200-500ms，适合大规模公开直播）。
类比：WebRTC像点对点通话（直接连接），RTMP像广播电台（中心服务器广播）。
容错机制：
熔断（服务超时率超阈值时暂时拒绝请求，防雪崩）；降级（非核心功能关闭，保核心业务）；重试（非关键请求重试，如日志）；监控告警（Prometheus+Grafana监控QPS、延迟，超阈值告警）。
类比：熔断像电路保险丝，降级像关闭非必要电器，重试像重发快递，监控像烟雾报警器。

3) 【对比与适用场景】

组件/协议	定义	特性	使用场景	注意点
WebRTC	基于Web的实时通信技术	端到端加密，低延迟（约100ms），无需插件	小范围互动直播（1v1辅导、小组讨论）	需信令服务器（STUN/TURN）协调连接，对网络敏感
RTMP	流媒体传输协议	中心化控制，支持百万级直播，延迟200-500ms	大规模公开直播（公开课、演唱会）	需专用流媒体服务器（如腾讯云直播），成本高
熔断	服务超时率超阈值时暂时拒绝请求	防雪崩，保护系统稳定	高并发服务调用（如用户服务调用直播服务）	阈值需合理，避免误判
降级	非核心功能暂时关闭/降级	保障核心业务	系统压力过大（如数据库压力过大，关闭非核心统计）	需明确核心功能边界

4) 【示例】
以用户加入直播为例，流程：

用户请求加入直播（HTTP请求到用户服务）；
用户服务验证权限（Redis缓存用户信息，减少数据库查询）；
用户服务调用直播服务（通过消息队列异步通知）；
直播服务分配流ID，通过RTMP协议推流到流媒体服务器；
流媒体服务器分发流到用户端（WebRTC拉流）。

伪代码（用户服务）：

def join_live(user_id, live_id):
    # 验证权限（Redis缓存）
    if not check_user_permission(user_id):
        return "权限不足"
    # 异步调用直播服务
    send_message_to_kafka("live_service", {"user_id": user_id, "live_id": live_id})
    return "加入直播成功"

5) 【面试口播版答案】
“面试官您好，设计百万级用户在线直播课系统，核心是构建分布式微服务架构，通过负载均衡、缓存、数据库分库分表处理高并发，采用WebRTC/RTMP保障低延迟实时通信，并设计熔断、降级等容错机制。具体来说，高并发处理方面，用Nginx做负载均衡分发请求，Redis缓存热点数据（如用户信息、直播状态），数据库分库分表（按用户ID哈希分表）水平扩展；实时通信用WebRTC（端到端低延迟）和RTMP（中心化大规模直播），WebRTC处理1v1/小组互动，RTMP处理公开课；容错机制有熔断（服务超时率超过50%时拒绝请求）、降级（关闭非核心统计）、重试（日志写入失败重试3次），监控用Prometheus+Grafana实时监控QPS、延迟等指标。这样能确保系统在高并发下稳定运行。”

6) 【追问清单】

问题：关于实时通信协议的选择，为什么选择WebRTC和RTMP组合？
回答要点：WebRTC适合小范围互动（低延迟、端到端），RTMP适合大规模公开直播（中心化控制、高并发），组合满足不同场景需求。
问题：容错机制中，熔断的阈值如何设置？如何避免误判？
回答要点：阈值根据历史数据设置（如超时率超过50%时触发），并设置半开状态（每秒放1个请求测试），避免误判。
问题：高并发下，数据库分库分表后，如何保证数据一致性？比如用户加入直播时，数据库和缓存数据同步？
回答要点：使用分布式事务（如两阶段提交）或最终一致性（缓存+数据库异步同步，如Redis缓存用户信息，数据库更新后异步刷入缓存）。

7) 【常见坑/雷区】

忽略网络延迟：只关注服务器性能，而忽略实时通信的延迟问题，导致用户体验差。
容错机制不完善：没有考虑雪崩效应，比如熔断阈值设置不合理，导致服务彻底不可用。
技术选型过于复杂：比如用复杂的分布式事务处理所有场景，而简单场景用最终一致性，增加系统复杂度。
缺少监控告警：没有实时监控QPS、延迟等指标，无法及时发现系统问题。
没有考虑数据一致性：比如用户加入直播时，数据库和缓存数据不同步，导致用户状态不一致。