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

acfb858c7355014e6d79d7b3ca6ae95e.gif

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

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

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

4c964b35e44e61eee80cd59f8874f12b.png

8986185196c503cc98c6bc0ca14f826f.png

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

1f5c56106f8c4b41bfd7ebd102958df2.png

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

5b5bced559f181f3f5bfcc70ca59b427.png

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

1e5f36173d6dd935a7f4abdcb5a1a63d.png

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

ca0a7d522b58f4160553c89d63de94c7.png

cdb832f64cfba6357006ee67b4f3e315.png

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

▶︎ 评论安全打击;

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

▶︎ 评论是否需要置顶;

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

▶︎ ......

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

b860781ff5eb49eba3075c80aa26fbcd.png

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

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

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

462b0fb6d89b400124b5dac37d4bd238.png

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

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

1135bb98d3d390202173302dd0023cae.png

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

▶︎ 增加写消费效率:增加 mongo 存储的存储核数,并增加消费并发度;

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

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

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

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

1f71b0a3997932bba2b3e3aa61d41238.png

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

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

读场景

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

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

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

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

写场景

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

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

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

压测

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

通过一系列流程和架构优化,评论系统可用性得到进一步提升,相信在未来运营场景能很好地保障用户体验。欢迎各位在评论区交流讨论。以上就是本篇文章的全部内容了,如果文章对你有帮助,欢迎转发分享。

你亲历过哪些考验项目高并发/高可用的场景?你有什么可以分享的高并发/高可用经验吗?欢迎留言。我们将挑选一则最有趣的答案,为其留言者送出腾讯定制毛毯。8月16日中午12点开奖。

e212a76967adc1f68c7fc2b1a655a666.png

44381bd5f0e715a37492ed19e9d4bae7.png

679112bc2225f16c6c2eeb68d3596a60.png

1b220b0a51af05bd22f5a44725d613c1.png

9b39d6b3a6772b3e6c07f65717f98f5d.png

d2e67d976d5a8399cc945420b63081d7.png

关注并星标腾讯云开发者

第一时间看鹅厂架构设计经验

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值