《QQ音乐体验为中心的性能优化》 曾义

2020-03-01 208浏览

  • 1.QQ音乐体验为中心的性能优化 曾义 腾讯音乐集团QQ音乐后台团队负责人
  • 2.
  • 3.QQ音乐体验为中心的性能优化 大纲 曾义 第一部分 体验为中心的性能优化四步法则 第二部分 流媒体架构与具体优化策略 第三部分 双中心提升后台服务可用性
  • 4.QQ音乐体验为中心的性能优化 曾义 自我介绍 个人经历 ■ 2007.3-2008.9 IBM中国芯片中心系统组 ■ 2008.10-2012.11 摩根士丹利(上海) 技术部门 ■ 2012.11-今 腾讯QQ音乐 工作职责 ■ 负责QQ音乐的后台团队，包括后台开发与运维 ■ 主要专注后台服务的性能成本优化及可用性提升 ■ 曾带领团队以流媒体优化和可用性优化项目获得腾讯卓越运营奖金奖 (运营类第一名)
  • 5.QQ音乐概况 QQ音乐体验为中心的性能优化 曾义 产品形态 ■ 多客户端: PC, iPhone, android, Mac, iPad, TV, 微信小程序(内测中) ■ PC native与PC web结合(音乐馆内容), 移动终端native与H5结合 ■ 与三大唱片公司(Sony/ 环球/华纳)合作，独家签约周杰伦Bigbang等著名艺人 ■ 与双酷合并后占据约90%以上互联网音乐市场规模 用户规模 ■ DAU(日活跃用户数)超过一亿，其中PC 2000万，手机8000万 ■ 每日听歌次数约20亿次,其中在线听歌超过8亿次 ■ 每日搜索QV 1.5亿，UV 3000万 曲库相关规模 ■ 曲库歌曲数超过1500万 ■ 文件数量超过1亿，数据格式包括不同码率的mp3, aac, ogg文件 ■ CDN使用自建CDN加三家外包CDN，每日带宽峰值均值约700G ■ 后台服务并发请求量约20万qps, 后台服务器(不含CDN)超过4000台
  • 6.体验为中心的性能优化四步法则 QQ音乐体验为中心的性能优化 ■ 设定优化目标与指标 ■ 真实全面准确地收集用户体验数据 ■ 集思广益,从后端到前端的“一篮子”优化策略集 ■ 灰度发布，A/B测试，动态运营 流媒体架构与具体优化策略 ■ QQ音乐流媒体架构 ■ 流媒体性能优化策略 双中心提升后台服务可用性 ■ QQ音乐后台服务的典型架构 ■ 存在的问题 ■ 双中心改造 ■ 客户端调度策略 ■ 改造前后效果对比 曾义
  • 7.设定优化目标与指标 QQ音乐体验为中心的性能优化 曾义 用“千百十”准则寻找用户痛点 ■ 一千条反馈，一百条回复，十个用户 ■ 听歌等待时间长，听歌卡，听不了歌，下载慢 将用户痛点转化为指标 ■ 以用户的感知为标准定义指标 ■ 如: 首次缓冲时间的定义----从点击播放到听见声音的时间 ■ 本地歌曲是否应该计算在统计范围内: 系统自动为用户缓存且用户不可感知的 才统计 将指标量化，赋予权重，计算得分 ■ 参照腾讯管家和360的思路: 计算得分让优化成绩更易于可视化，更易于向老 板汇报 ■ 各项体验之间可能会有冲突，需要仔细设定优化优先级
  • 8.QQ音乐体验为中心的性能优化 得分示例 曾义
  • 9.QQ音乐体验为中心的性能优化 真实全面准确地收集用户体验数据 真实 ■ 收集外网用户数据而不是测试数据 全面 ■ 收集全量用户数据；或者1/2-1/3采样数据 准确 ■ 多地域多运营商接入；抓包分析，仔细分析上报数据的准确性 曾义
  • 10.QQ音乐体验为中心的性能优化 数据查询与展示平台 曾义
  • 11.QQ音乐体验为中心的性能优化 曾义 集思广益,从后端到前端的“一篮子”优化策略集 研究竞品优化策略 研究兄弟部门产品优化策略 与合作部门头脑风暴；向专家请教 团队内部头脑风暴 为用户解决问题过程中产生灵感
  • 12.QQ音乐体验为中心的性能优化 动态运营 灰度发布 观察数据，仔细分析问题，解决问题 A/B测试 快速迭代 搜集用户反馈 跟踪竞品动态 曾义
  • 13.体验为中心的性能优化四步法则 QQ音乐体验为中心的性能优化 ■ 设定优化目标与指标 ■ 真实全面准确地收集用户体验数据 ■ 集思广益,从后端到前端的“一篮子”优化策略集 ■ 灰度发布，A/B测试，动态运营 流媒体架构与具体优化策略 ■ QQ音乐流媒体架构 ■ 流媒体性能优化策略 双中心提升后台服务可用性 ■ QQ音乐后台服务的典型架构 ■ 存在的问题 ■ 双中心改造 ■ 客户端调度策略 ■ 改造前后效果对比 曾义
  • 14.QQ音乐体验为中心的性能优化 曾义 上传 QQ音乐流媒体架构 编辑/转码上传 源站/统一存储 回源 直通车调度中心 3.根据App出口IP 返回最佳调度节点 IP(运营商/省份) 2.传入App出口IP 请求最佳调度节点 回源 竞速CGI CDN 直通车CDN 一级中间层 5.测速 二级中间层 4. 返回两个CDN域 名，一个IP，以及 vkey 1.请求CDN地址 以及vkey 回源 6. http请求数据 边缘节点 App CDN 测速 7. 返回数据
  • 15.QQ音乐体验为中心的性能优化 曾义 用户体验三原则: 别让我等; 别让我想; 别让我烦 听歌等待时间长 ■ 痛点: 点击播放后转菊花，很长时间后才听到声音 ■ 建模: 建立首次缓冲时长指标: 从用户点击播放到听到声音的耗时 听歌中出现卡顿 ■ 痛点: 听歌中途出现卡顿，听歌过程被打断，体验受损 ■ 建模: 如果一首歌听歌过程出现两次或以上等待，算作出现二次缓冲。 下载速度慢 ■ 痛点: 出去旅游准备出发了，急着临时批量下载歌曲到手机中，但是下载速度 慢等待时间太长 ■ 建模: 建立下载速度指标 听歌下载出现错误 ■ 痛点: 点击下载/播放按钮后显示网络错误无法下载/播放 ■ 建模: 建立错误率指标，出现错误的下载/播放次数除以总下载/播放次数
  • 16.流媒体性能优化策略 QQ音乐体验为中心的性能优化 CDN竞速接入，让生态"失控" ■ CDN接入点覆盖面最大化 ■ 供应商形成竞争关系，四两拨千斤 ■ 某个CDN波动/故障时，无缝切换 IP直通车--直接用IP代替域名进行访问 ■ 防止域名劫持以及域名解析服务器失效 ■ 节省DNS解析时间 ■ 防止用户DNS配置错误: 如8.8.8.8 TCP参数优化 ■ 根据首片数据大小决定起始拥塞窗口大小 ■ 在丢包时快速恢复拥塞窗口大小 曾义
  • 17.案例 ■ QQ音乐体验为中心的性能优化 曾义 2015年8月8日自建CDN调度中心整体故障，音乐带宽平滑转移到其他三家CDN
  • 18.案例 ■ QQ音乐体验为中心的性能优化 2014年1月3日广东移动IDC出口故障 曾义
  • 19.流媒体性能优化策略 QQ音乐体验为中心的性能优化 预取 ■ 预取下一首歌的首片数据 ■ 根据历史网速推测下一首歌的首片数据大小 ■ 主动推送页面可见歌曲到CDN边缘节点 ■ 非高峰期预取热门歌曲 ■ 非高峰期预取用户歌单歌曲 ■ 大数据统计学习预测用户最有可能听到的歌曲并进行非高峰期预取 ■ 个性化: 根据用户的网络与机型决定听歌参数(歌曲码率等) 缓存 ■ 缓存是内容分发最重要的加速手段 ■ 离用户越近效果越好: 本地 > 边缘节点 > 区域中心 > 源站 ■ 缓存歌曲首片数据: 节省空间，带来更高的缓存率 曾义
  • 20.案例 ■ QQ音乐体验为中心的性能优化 预取首片数据 曾义
  • 21.案例 QQ音乐体验为中心的性能优化 ■ 根据历史网速决定首片数据大小 ■ 原因:首次缓冲时间和二次缓冲概率存在一个权衡 ■ 隐马尔可夫模型预测首片大小 曾义
  • 22.案例 QQ音乐体验为中心的性能优化 曾义 ■ 定制化用户参数 ■ 为2G和3G用户设定不同的默认码率 ■ 建立用户的数据库，为用户计算得分，并根据得分设定不同的默认听歌参数
  • 23.优化效果 QQ音乐体验为中心的性能优化 曾义
  • 24.
  • 25.体验为中心的性能优化四步法则 QQ音乐体验为中心的性能优化 ■ 设定优化目标与指标 ■ 真实全面准确地收集用户体验数据 ■ 集思广益,从后端到前端的“一篮子”优化策略集 ■ 灰度发布，A/B测试，动态运营 流媒体架构与具体优化策略 ■ QQ音乐流媒体架构 ■ 流媒体性能优化策略 双中心提升后台服务可用性 ■ QQ音乐后台服务的典型架构 ■ 存在的问题 ■ 双中心改造 ■ 客户端调度策略 ■ 改造前后效果对比 曾义
  • 26.QQ音乐体验为中心的性能优化 曾义 非UGC业务典型架构 ■ 主要包括听歌识曲，搜索，精选，排行榜，歌单广场，电台MV，好友热播等 ■ 所有关键路径数据不由用户侧生成, 而是由后台编辑人工生成或者定时任务生成 ■ 用户对数据生成延迟不敏感，写入时序可控
  • 27.QQ音乐体验为中心的性能优化 UGC业务典型架构 ■ 主要包括用户歌单，猜你喜欢，好友和歌手关注，点歌，弹幕，评论等 ■ 关键路径数据由用户侧生成 ■ 用户对数据生成延迟较敏感,不能保证写入时序 曾义
  • 28.QQ音乐体验为中心的性能优化 曾义 已知的问题 ■ 业务发展过于迅猛，新特性多，技术债务多 ■ 历史代码质量不高，短期内通过优化代码提升服务质量人力资源不足 ■ 深圳IDC机房接近饱和，众多老旧机房来不及裁撤，导致机房故障频发 ■ 深圳同城专线故障发生频率处于上升趋势 ■ 机房/专线故障直接传导至用户侧，影响用户体验
  • 29.双中心改造 QQ音乐体验为中心的性能优化 曾义 除深圳外，在上海部署一套完全对等的双中心 用户可以在深圳上海两个中心任意切换 非UGC业务 ■ 一旦深圳/上海IDC机房出现故障或全国专线出现故障，数据将暂时停止更新 ■ 用户继续使用已生成数据，读数据不穿越全国专线，保证用户无感知 ■ 当机房/专线故障修复后继续更新数据 UGC业务 ■ 将UGC业务进行读写分离 ■ 建立深圳上海对等的接入、逻辑、存储模块，读操作可以在两地任意切换 ■ 写操作服务部署在深圳，通过同步中心的代理对深圳和上海的两地存储进行双写 ■ 同步中心保证两地写入的时序。 ■ 如果IDC机房或者全国专线故障导致对一地/两地的写失败，同步中心会将流水保 存在本地，待故障恢复后继续按时序写入流水
  • 30.QQ音乐体验为中心的性能优化 非UGC业务双中心架构(蓝色深圳，黄色上海) 曾义
  • 31.QQ音乐体验为中心的性能优化 UGC业务双中心架构(蓝色深圳，黄色上海) 曾义
  • 32.QQ音乐体验为中心的性能优化 曾义 客户端调度策略 三个域名进行接入 ■ 客户端对所有域名都进行解析获取IP后，通过IP直接进行请求 ■ acc.music.qq.com通过GSLB分别就近解析50%的用户到深圳和上海 ■ szacc.music.qq.com解析到深圳的接入VIP ■ shacc.music.qq.com解析到上海的接入VIP 客户端获取IP的途径 ■ 通过gethostbyname直接对域名进行DNS解析 ■ 通过后台CGI服务请求域名对应的IP ■ 客户端写死每个域名对应的IP,通过发版本更新
  • 33.QQ音乐体验为中心的性能优化 曾义 客户端调度策略 接入IP的使用方式 ■ ip分别放到每个域名对应的IP集合中 ■ 每个IP给一个初始的优先级权重，其中1,2,3种途径获取的IP优先级分别从高 到低 ■ 客户端会对这些IP集合中的IP进行连通性测试，无法连通的IP将会设置最低 权重 ■ 每次取出一个最优先的IP进行请求，如果请求失败则使用另一个中心的IP进 行重试一次 ■ 请求成功会则提升IP优先级，请求失败则降低IP优先级 ■ 偶尔失败不会切换接入中心，避免颠簸，但是连续请求失败会切换
  • 34.双中心调度防过载 QQ音乐体验为中心的性能优化 曾义 负载控制 ■ 确保单中心的模块负载严格控制在50%以下，保证单中心理论上可以扛住全 量的请求 ■ iOS+android请求量占总请求量的70%左右，PC+其他平台占30%. ■ 移动终端负载控制在35%,PC侧负载控制在15% 有损切换 ■ 优先保证移动端体验，对iOS和android的请求进行自动切换 ■ 对于PC以及其他平台仍然使用手动切换 ■ 如果发生移动终端全量自动切换，单个中心的负载最高不会超过85%，负载 仍然处于安全阈值以内 ■ PC和其他平台根据各中心负载情况，经过评估后人工切换
  • 35.QQ音乐体验为中心的性能优化 双中心改造前成功率 曾义
  • 36.QQ音乐体验为中心的性能优化 双中心改造后成功率 曾义
  • 37.