在海康威视的视频监控系统中，如何设计一个能够处理百万级并发视频流的分布式处理架构？请从负载均衡、数据分片、容错机制、监控与扩展性等方面阐述你的设计思路。

1) 【一句话结论】
采用分层分布式架构，通过多级负载均衡（全局-区域-实例）、时间+区域混合分片（结合冷热分离）、Raft副本容错、P99延迟监控及K8s HPA自动扩展，在合理流量下实现百万级视频流的高可用与低延迟处理（极端流量下延迟可能增加，通过缓存优化缓解）。

2) 【原理/概念讲解】

• 负载均衡：构建三级负载均衡体系，从全局到区域再到实例级。全局负载均衡器（如Nginx）负责将请求分发至不同区域，区域负载均衡器（如Consul）根据区域负载动态选择区域节点，实例级负载均衡器（如HAProxy）将请求分配至具体处理实例。采用加权轮询算法，权重根据节点CPU使用率、内存占用、请求处理延迟等指标实时调整（通过心跳检测每秒收集节点状态，高负载节点权重降低，低负载节点权重提升），确保负载均匀且资源利用率最大化。
• 数据分片：采用时间（小时/天）与区域混合分片策略，结合冷热数据分离。热数据（近1小时内的视频流）存储在内存（如Redis）或SSD（如NVMe）中，利用高速存储提升处理速度；冷数据（历史数据）归档至对象存储（如MinIO），避免单节点数据量过大导致性能瓶颈。分片键设计为时间分片键-区域ID（如20240101-01表示2024年1月1日区域1），确保数据按时间与空间分布，减少热点集中。
• 容错机制：每个数据分片配置3个副本，主从异步复制。主节点（Leader）处理请求并写入日志，副本（Follower）异步同步日志。采用Raft协议保证强一致性：故障时，副本通过投票选举新Leader，继续同步日志，确保数据一致性。此外，节点故障时自动切换，不影响服务可用性。
• 监控与扩展：实时监控关键指标，包括CPU使用率、内存占用、P99请求延迟（目标≤100ms）、错误率、网络I/O延迟、存储I/O延迟。当P99延迟超过120ms或CPU使用率超过80%时，触发K8s Horizontal Pod Autoscaler（HPA），自动增加分片节点数量，实现弹性扩展。

3) 【对比与适用场景】

• 负载均衡算法对比（表格）
  | 算法 | 定义 | 特性 | 使用场景 | 注意点 | | --- | --- | --- | --- | --- | | 加权轮询 | 根据节点处理能力分配权重，按权重循环分发 | 考虑节点能力，负载均匀 | 节点处理能力差异大（如CPU/内存不同） | 需实时更新权重 | | 随机 | 随机选择节点 | 简单，负载均匀但可能过载 | 节点数量多，能力一致 | 无法考虑节点负载 | | 最少连接 | 选择当前连接数最少的节点 | 适合长连接场景 | 需要减少连接数 | 需维护连接数状态 |
• 数据分片策略对比（表格）
  | 策略 | 定义 | 特性 | 使用场景 | 注意点 | | --- | --- | --- | --- | --- | | 时间分片 | 按时间（小时/天）切分数据 | 数据量适中，支持历史分析 | 视频流处理（如按天分析历史数据） | 时间窗口内数据集中（热点） | | 区域分片 | 按地理区域切分数据 | 延迟低，适合地理分布广 | 城市级/省级监控网络 | 区域间数据跨节点传输 | | 冷热分离 | 热数据（近1小时）存储在内存/SSD，冷数据归档 | 减少单节点数据量，提升性能 | 高并发场景，需归档历史数据 | 需维护冷热数据同步 |
• 冷热数据同步机制对比（要点）
  • 日志同步：热数据更新时，通过Raft日志同步至对象存储的冷数据副本，确保冷数据与热数据一致。
  • 事件驱动：当热数据更新时，触发Kafka消息队列，将更新事件发送至对象存储的冷数据节点，实现异步同步，避免实时同步导致延迟。

4) 【示例】

• 分片键生成与冷热处理伪代码：

  def get_shard_key(timestamp: int, region_id: str) -> str:
      hour = timestamp // 3600  # 按小时分片
      return f"{hour}-{region_id}"
  
  def process_video_stream(stream_id: str, timestamp: int):
      shard_key = get_shard_key(timestamp, "region1")
      shard_node = get_node_by_shard(shard_key)  # 获取分片节点
      if timestamp > now - 3600:  # 热数据（近1小时）
          shard_node.store_hot(stream_id, timestamp)  # 存内存/SSD
      else:  # 冷数据（历史）
          shard_node.store_cold(stream_id, timestamp)  # 归档对象存储
  

• Raft副本同步流程简述：
  1. 主节点（Leader）接收请求，写入日志（如[term, index, command]）。
  2. 发送日志给所有副本（Follower），副本写入本地日志并回复ACK。
  3. Leader收到多数副本的ACK后，提交日志并更新状态机。
  4. 若Leader故障，Follower通过投票选举新Leader，继续同步日志，确保数据一致性。

5) 【面试口播版答案】
“面试官您好，处理百万级视频流的分布式架构设计，核心是通过分层解耦和弹性扩展。首先，负载均衡采用三级策略：全局负载均衡器（如Nginx）分发到区域负载均衡器（如Consul），再由区域负载均衡器分配到具体处理节点，算法用加权轮询，根据节点CPU、内存负载动态调整权重，避免处理能力弱的节点过载。然后，数据分片按时间（小时）+区域混合，同时结合冷热分离：热数据（近1小时）存储在内存/SSD，冷数据归档到对象存储，避免单节点数据量过大。容错方面，每个分片节点有3副本，主从异步复制，用Raft协议保证强一致性，故障时副本自动选举为主，接管请求。监控方面，实时收集节点负载、P99延迟（目标100ms）、网络I/O等指标，当延迟超过120ms或CPU使用率超过80%时，自动触发K8s的HPA，增加分片节点。这样在合理流量下能支撑百万级并发，保证高可用和低延迟（极端流量下延迟可能增加，通过缓存优化缓解）。”

6) 【追问清单】

• 问：负载均衡的权重动态更新机制具体如何实现？比如如何实时获取节点处理能力？
  回答要点：通过心跳检测（每秒发送心跳请求），收集节点CPU使用率、内存占用、请求处理延迟等指标，动态计算权重（如CPU负载<50%权重高，>80%权重低），实时调整负载均衡策略。
• 问：数据分片的热点问题如何解决？比如时间分片时某个时间点数据集中？
  回答要点：采用时间+区域混合分片，同时冷热分离，热数据（近1小时）按区域分片，冷数据归档，避免热点集中；若热点仍存在，可调整分片粒度（如按分钟）或增加分片节点。
• 问：冷热数据同步机制具体如何实现？比如热数据更新后如何同步至冷数据？
  回答要点：通过Kafka消息队列，热数据更新时触发消息发送至对象存储的冷数据节点，实现异步同步，确保冷数据与热数据一致，避免实时同步导致延迟。
• 问：监控指标具体有哪些？自动扩展时如何分析延迟来源？
  回答要点：监控指标包括CPU使用率、内存占用、P99延迟、错误率、网络延迟、存储I/O延迟；当延迟超过阈值时，分析指标发现是计算节点（CPU高）或网络瓶颈（I/O高），自动扩展对应类型的节点（如增加计算节点或优化网络）。
• 问：扩展性方面，新增监控点时如何快速融入系统？
  回答要点：新增监控点时，自动分配到最近的区域分片节点（通过区域负载均衡器动态分配），确保新增节点能快速处理流量，不影响现有系统。

7) 【常见坑/雷区】

• 坑1：忽略热点问题，仅按时间分片导致数据集中，单节点过载，延迟高。
• 坑2：冷热数据同步采用实时同步，导致延迟增加，甚至数据不一致。
• 坑3：监控指标仅关注负载，未监控网络I/O和延迟，系统延迟过高时无法及时扩展。
• 坑4：负载均衡权重未动态更新，固定权重导致节点负载不均，资源利用率低。
• 坑5：绝对化目标“确保高可用与低延迟”，未说明极端流量下的局限性（如可能存在延迟，需结合缓存优化）。