空降流量危机？QQ音乐升级架构应对高并发
# 关注并星标腾讯云开发者
【资料图】
# 每周3 | 谈谈我在腾讯的架构设计经验
#第2期|赵威：QQ音乐评论系统如何实现高可用？
QQ 音乐自诞生以来，已有多个版本的评论业务系统。最新版本是19年再次全新迭代，基于 tlist 存储，按照发表时间顺序展示。后续为了更好的用户体验，产品形态调整为评论盖楼模式，为了实现该功能，存储迁移到 mongo。
目前评论作为用户社交重要场景以及艺粉互动（明星空降）重要场地，经常会有突发流量。为了更好地保障空降场景评论体验，我们对评论系统进行充分的设计。
评论系统设计核心挑战点在于艺人空降时需要扛住突增的读写压力，包括评论数量、评论列表等读场景，以及发表评论，艺人评论置顶等写场景。
如果直接读 mongo，需要用非常高的存储成本来抗住读压力。对于高并发热 key，常规使用缓存方案，在缓存使用中注意做好防穿透以及限流策略，防止存储高负载雪崩。
评论写涉及比较复杂的业务逻辑，整体流程包含： ▶︎ 评论安全打击； ▶︎ 评论发布属地信息查询并记录； ▶︎ 评论是否需要置顶； ▶︎ 评论是否乐评人评论。 ▶︎ ......
它涉及多个操作，部分处理失败会造成比较严重的体验问题。需要保障数据处理的一致性。为了保障一致性，一种是使用事务处理，强一致，但吞吐量稍微差些。另一种是使用可重入保障最终一致性，为了保障更高的吞吐量，写场景采用了最终一致方案。
通过消息队列解耦将评论写入高速 cache，异步写入 mongo。同时也能通过重试，确保比较核心数据最终写入 mongo。
通过上面两种设计，能在正常情况下很好满足日常评论的吞吐量，那是否真正做到高可用呢？随着业务迭代，在 add 消费场景再次增加了业务逻辑，比如增加上报，如果业务延时增加比较大或前置属地查询失败比较多时，整体 add 流程处理时延严重增加，导致消费效率下降、消息堆积，最后导致大盘全部评论全部延迟消费，用户体验出现发布后没有外显丢评论的体验问题。
评论系统引入热门消息队列，将全局评论和热门评论的消息队列做拆分。当热门消息过多时，最多只影响局部热门消息队列的堆积，对全局评论体验不影响。
上面没有在生成时直接写两个消息队列 topic，而采用对已有的消息队列再消费写入到热门消息队列，是由于下游还有很多场景在消费原有的消息队列，比如各种任务系统等，为了减少开发成本，采用了目前的方案。
采用上面的读写设计，基本能满足日常空降场景评论系统的可用性。随着空降参与艺人粉丝越来越多，业务遇到新的挑战。
艺人空降评论区艺粉互动效果不错，越来越多艺人空降评论区。粉丝参与热情高涨，读写流量节节高升，空降活动导致评论系统挑战越来越大，需要系统优化保障服务质量。我们通过如下方式来处理挑战：
▶︎ 增加写消费效率：增加 mongo 存储的存储核数，并增加消费并发度； ▶︎ 读服务平行扩容，并拆分缓存到更多的 key（uin%10等），防止热 key 太集中，增加读服务吞吐量； ▶︎ 拆分读服务和写服务部署，防止读写互相影响； ▶︎ 非关键场景限流，保障核心路径的可用性。
通过上述手段，保障空降活动大致稳定可靠，虽然遇到消费瓶颈，导致写场景有轻微堆积，但用户感知没有那么强烈。
近期通过以下方面完成了相关的优化：
读场景 ▶︎拆分评论数、点赞数存储从 ckv 迁移到 ckv+，不降冷，尽可能保障这两个数据可用性； ▶︎评论数增加本地缓存，增加版本号，保障用户体验无异常且评论数的高吞吐量； ▶︎前端保护后端，合理化请求时机，并在前端有数据情况下，遇到评论数或列表拉取异常时，前端不弹异常，减少异常感知； ▶︎前端优化页面体验，提升秒开率，提升用户体验。
写场景
▶︎ 拆分评论写场景逻辑，保障核心路径简化，优先保障写 mongo 速度和吞吐量，减少消息堆积概率； ▶︎ 增加优先级队列，保障艺人核心体验无阻塞； ▶︎ 完善相关工具建设，随时可以跟进相关数据或运营诉求，提升运营效率。
压测
▶︎读写场景常规压测，确保压测出业务瓶颈在运营场景需要情况下，能快速通过平行扩容，保障系统可用性。
通过一系列流程和架构优化，评论系统可用性得到进一步提升，相信在未来运营场景能很好地保障用户体验。欢迎各位在评论区交流讨论。以上就是本篇文章的全部内容了，如果文章对你有帮助，欢迎转发分享。
你亲历过哪些考验项目高并发/高可用的场景？你有什么可以分享的高并发/高可用经验吗？欢迎留言。我们将挑选一则最有趣的答案，为其留言者送出腾讯定制毛毯。8月16日中午12点开奖。
第一时间看鹅厂架构设计经验
标签：
为您推荐
-
人民网杭州9月17日电 （记者孙博洋）9月16日至17日，中国质量（杭州）大会在浙江杭州举行。在16日举行...
2021-09-18