空降流量危机？QQ音乐升级架构应对高并发

news2025/1/4 20:15:34

# 关注并星标腾讯云开发者

# 每周3 | 谈谈我在腾讯的架构设计经验

# 第2期 | 赵威：QQ音乐评论系统如何实现高可用？

QQ 音乐自诞生以来，已有多个版本的评论业务系统。最新版本是19年再次全新迭代，基于 tlist 存储，按照发表时间顺序展示。后续为了更好的用户体验，产品形态调整为评论盖楼模式，为了实现该功能，存储迁移到 mongo。

目前评论作为用户社交重要场景以及艺粉互动（明星空降）重要场地，经常会有突发流量。为了更好地保障空降场景评论体验，我们对评论系统进行充分的设计。

评论系统设计核心挑战点在于艺人空降时需要扛住突增的读写压力，包括评论数量、评论列表等读场景，以及发表评论，艺人评论置顶等写场景。

如果直接读 mongo，需要用非常高的存储成本来抗住读压力。对于高并发热 key，常规使用缓存方案，在缓存使用中注意做好防穿透以及限流策略，防止存储高负载雪崩。

评论写涉及比较复杂的业务逻辑，整体流程包含：

▶︎ 评论安全打击；

▶︎ 评论发布属地信息查询并记录；

▶︎ 评论是否需要置顶；

▶︎ 评论是否乐评人评论。

▶︎ ......

它涉及多个操作，部分处理失败会造成比较严重的体验问题。需要保障数据处理的一致性。为了保障一致性，一种是使用事务处理，强一致，但吞吐量稍微差些。另一种是使用可重入保障最终一致性，为了保障更高的吞吐量，写场景采用了最终一致方案。

通过消息队列解耦将评论写入高速 cache，异步写入 mongo。同时也能通过重试，确保比较核心数据最终写入 mongo。

通过上面两种设计，能在正常情况下很好满足日常评论的吞吐量，那是否真正做到高可用呢？随着业务迭代，在 add 消费场景再次增加了业务逻辑，比如增加上报，如果业务延时增加比较大或前置属地查询失败比较多时，整体 add 流程处理时延严重增加，导致消费效率下降、消息堆积，最后导致大盘全部评论全部延迟消费，用户体验出现发布后没有外显丢评论的体验问题。

评论系统引入热门消息队列，将全局评论和热门评论的消息队列做拆分。当热门消息过多时，最多只影响局部热门消息队列的堆积，对全局评论体验不影响。

上面没有在生成时直接写两个消息队列 topic，而采用对已有的消息队列再消费写入到热门消息队列，是由于下游还有很多场景在消费原有的消息队列，比如各种任务系统等，为了减少开发成本，采用了目前的方案。

采用上面的读写设计，基本能满足日常空降场景评论系统的可用性。随着空降参与艺人粉丝越来越多，业务遇到新的挑战。

艺人空降评论区艺粉互动效果不错，越来越多艺人空降评论区。粉丝参与热情高涨，读写流量节节高升，空降活动导致评论系统挑战越来越大，需要系统优化保障服务质量。我们通过如下方式来处理挑战：

▶︎ 增加写消费效率：增加 mongo 存储的存储核数，并增加消费并发度；

▶︎ 读服务平行扩容，并拆分缓存到更多的 key（uin%10等），防止热 key 太集中，增加读服务吞吐量；

▶︎ 拆分读服务和写服务部署，防止读写互相影响；

▶︎ 非关键场景限流，保障核心路径的可用性。

通过上述手段，保障空降活动大致稳定可靠，虽然遇到消费瓶颈，导致写场景有轻微堆积，但用户感知没有那么强烈。

其中一次大牌艺人活动中评论系统整体稳定可靠，但还是遇到了消费瓶颈，且中间出现了依赖存储 ckv 由于设置了降冷，在访问量非常高且空查询比较多的情况下，大量请求降到降冷存储 tssd。由于 tssd 降低成本设计未充分业务隔离，导致全平台 tssd 告警的问题。虽然通过限流紧急处理，但还是需要有系统性优化。

近期通过以下方面完成了相关的优化：

读场景

▶︎拆分评论数、点赞数存储从 ckv 迁移到 ckv+，不降冷，尽可能保障这两个数据可用性；

▶︎评论数增加本地缓存，增加版本号，保障用户体验无异常且评论数的高吞吐量；

▶︎前端保护后端，合理化请求时机，并在前端有数据情况下，遇到评论数或列表拉取异常时，前端不弹异常，减少异常感知；

▶︎前端优化页面体验，提升秒开率，提升用户体验。

写场景

▶︎ 拆分评论写场景逻辑，保障核心路径简化，优先保障写 mongo 速度和吞吐量，减少消息堆积概率；

▶︎ 增加优先级队列，保障艺人核心体验无阻塞；

▶︎ 完善相关工具建设，随时可以跟进相关数据或运营诉求，提升运营效率。

压测

▶︎读写场景常规压测，确保压测出业务瓶颈在运营场景需要情况下，能快速通过平行扩容，保障系统可用性。