快手直播业务中，用户观看历史数据（如观看时长、互动行为）需要支持实时查询和推荐计算。分析是否采用分布式数据库（如TiDB）或缓存（如Redis）存储，解释数据分片策略（如按用户ID或时间分片）和缓存雪崩的解决方案（如热点数据预热、分布式锁控制写入）。
答案
1) 【一句话结论】针对快手直播用户观看历史数据的实时查询与推荐需求，应采用分布式数据库（如TiDB）存储原始数据，结合缓存（如Redis）缓存热点数据，数据分片按用户ID哈希分片，通过热点数据动态预热（覆盖高频用户）与分布式锁控制写入（带超时重试）解决缓存雪崩，同时结合分布式事务或双写协议保障数据一致性，以平衡查询性能与数据一致性。
2) 【原理/概念讲解】分布式数据库（如TiDB）是支持高并发读写、持久化的分布式关系型数据库，适合存储结构化数据（如用户观看时长、互动行为），数据分片策略（如按用户ID哈希分片）可将用户数据集中到特定分片，提升查询效率。缓存（如Redis）是内存数据库，用于加速热点数据访问，减少数据库压力。缓存雪崩是指大量缓存失效时，流量集中到数据库，导致性能瓶颈，解决方案包括：①热点数据动态预热（系统启动或流量高峰时加载高频用户数据到缓存）；②分布式锁控制写入（失效时用Redis的SETNX加锁，锁超时后重试，避免并发写入导致数据不一致）。数据一致性保障可通过TiDB的分布式事务（如两阶段提交）或双写协议（数据库先写，再异步写缓存，结合时间戳校验）实现。
3) 【对比与适用场景】
| 对比项 | 分布式数据库（TiDB） | 缓存（Redis） |
|---|---|---|
| 定义 | 分布式关系型数据库，支持ACID事务 | 内存数据库，用于数据缓存 |
| 特性 | 持久化存储，支持高并发读写，数据分片 | 内存存储，读写速度极快，易OOM |
| 使用场景 | 原始数据持久化（如观看时长、互动行为） | 热点数据加速（如活跃用户观看记录） |
| 注意点 | 分片后需维护数据一致性（如分布式事务） | 缓存击穿、雪崩、过期策略 |
4) 【示例】
- 数据分片：用户ID为1000的观看历史数据存储在TiDB的user_view_history分片（哈希分片，key=1000），查询时直接定位分片。
- 缓存雪崩解决方案：
- 热点数据动态预热：系统启动时，查询top100活跃用户数据（如最近30分钟观看时长最高的用户），写入Redis（key=user_view_history:用户ID，value=JSON数据，过期时间1小时）。
- 分布式锁控制写入：当缓存失效时，调用Redis的SETNX（分布式锁），参数为锁key（如cache_lock:user_view_history:用户ID）和过期时间（如5秒），成功获取锁的节点更新缓存，失败则等待锁释放后重试。
- 冷启动处理：新用户数据写入TiDB后，设置缓存过期时间为5分钟（较新用户访问频率低），后续用户活跃后动态延长过期时间（如1小时），避免冷启动时缓存占用过多内存。
5) 【面试口播版答案】面试官您好，针对快手直播用户观看历史数据的实时查询与推荐需求，我的思路是：首先，原始数据持久化存储用分布式数据库（如TiDB），因为需要支持高并发读写和持久化，数据分片按用户ID哈希分片，这样每个用户的数据集中在一个分片，查询效率高。然后，对于热点数据（如活跃用户的观看时长），用Redis缓存，加速查询。数据分片策略方面，用户ID分片更合理，因为推荐计算常按用户维度聚合，时间分片适合按时间范围查询，但用户维度更常用。缓存雪崩的解决方案，一是热点数据动态预热，系统启动时加载高频用户数据到缓存；二是分布式锁控制写入，当缓存失效时，用Redis分布式锁保证只有一个节点更新缓存，锁超时后重试，避免并发写入导致数据不一致。同时，通过TiDB的分布式事务或双写协议保障数据一致性，确保缓存与数据库数据同步。这样既能保证数据一致性与查询性能，又能应对高并发场景。
6) 【追问清单】
- 问题1：如果数据量极大（如千万级用户），分片策略如何选择？
回答要点：根据数据访问模式，用户ID分片适合按用户查询，时间分片适合按时间范围，结合业务需求（如推荐计算多按用户维度聚合），优先选择用户ID分片，并考虑分片键的均匀性（如哈希分片，避免热点分片）。 - 问题2：分布式数据库的分片键选择有什么考虑？
回答要点：分片键需均匀分布数据，避免热点分片（如用户ID哈希分片，减少单分片压力），同时考虑分片后的数据一致性维护（如TiDB的分布式事务，支持跨分片事务）。 - 问题3：缓存雪崩时，如果预热失败怎么办？
回答要点：设置缓存过期时间，并监控缓存命中率，当命中率下降时，触发重新预热；同时，可增加缓存过期时间（如延长为1小时），缓解雪崩影响。 - 问题4：推荐计算需要实时聚合数据，数据库和缓存如何配合？
回答要点：数据库存储原始数据，缓存存储聚合结果（如用户最近30分钟观看时长总和）；推荐计算时优先从缓存取，缓存失效时从数据库加载数据并更新缓存，减少数据库压力。 - 问题5：TiDB和Redis的选型依据是什么？
回答要点：TiDB适合结构化数据持久化（支持事务、ACID），适合存储原始观看数据；Redis适合缓存热点数据（高并发读写、低延迟），适合加速查询，两者结合可平衡性能与成本。
7) 【常见坑/雷区】
- 坑1：忽略数据一致性，导致缓存与数据库不一致，推荐计算结果错误。
雷区：未使用分布式事务或缓存加锁机制，导致数据不一致。 - 坑2：分片策略错误，按时间分片导致用户数据分散，查询效率低。
雷区：未考虑业务访问模式，分片键选择不当，影响查询性能。 - 坑3：缓存雪崩处理不当，未预热导致数据库压力激增。
雷区：未设置热点数据预热或分布式锁，导致缓存失效时数据库过载。 - 坑4：忘记分布式锁的作用，并发写入缓存导致数据覆盖。
雷区：缓存失效时未加锁，多个节点同时更新缓存，导致数据不一致。 - 坑5：未考虑数据冷启动，新用户数据未缓存，查询慢。
雷区：未设置缓存过期时间或预热策略，新用户数据无法快速访问。