上海品茶

您的当前位置:上海品茶 > 报告分类 > PDF报告下载

2019年全民K歌UGC架构高可用实现.pdf

编号:97337 PDF 23页 4.72MB 下载积分:VIP专享
下载报告请您先登录!

2019年全民K歌UGC架构高可用实现.pdf

1、全民K歌ugc架构高可用实现全民K歌UGC系统l读操作 4百亿/天l写操作 4亿/天l每天新增数千万作品l60P存储,3亿播放,每月数百万成本l更多拉取能力及不同类型的列表作品详情主客人态作品列表全局列表UGC数据的挑战 发表时间、置顶时间、公开私密状态、作品类型 全局索引 按需拉取列表过滤排序 列表长度多变,活跃用户列表30万条ugc,普通用户只有几条灵活多变大列表 PB级文件存储、TB级元数据存储、百亿日请求量 热点问题,单key的突发读写流量海量数据及流量 热点集中、长尾效应 优化流媒体质量的同时、平衡成本和容灾能力播放调度元数据存储选型存储优点风险点腾讯云TDSQL 金融级分布式数据库

2、 Raft多副本强一致 异地多活、多地多中心 copy+drop方式修改表结构,不够灵活Mysql+Redis 存储成本低 读取热点数据性能高 SQL查询方便 异步或者半同步半异步复制,主从不一致 分库分表、部署扩容运维困难腾讯云mongodb 分布式文档数据库,bson结构、多个索引 丰富查询,支持类SQL,按需拉取,支持TTL索引 高性能读写,原子操作,单分片30wQPS,热key 支持请求级别的一致性配置,根据业务定制一致性需求 线上定位问题速度1.过滤排序2.简单3.热点4.扩展内核优化列表1.geoNear优化(相比原生性能提升10倍以上)2.MongoRocks优化3.从库snap

3、shot读(业界领先,官方到4.0版本才支持该特性)4.基于checkpoint的物理拷贝5.大量短连接情况下随机数生成算法优化6.动态resize oplog(代码已被MongoDB官方接受)7.TTL索引删除优化(删除速度可控)8.Mongos连接池优化9.分片集群的skip+limit优化10.整体架构腾讯云MongoDB服务数据引擎 索引B树,非叶子节点加载到内存 每个表、索引是一个文件 适用 主要场景是列表查询空查询比较少 不适用 表和索引数量比较多,引起随机io经 验 LSM-Tree 布隆过滤器 所有数据在Column Family中 适用 写量比较大、sata盘、空查询比较多、

4、热点集中在新数据,老数据很少访问 不适用 单条记录太大,写放大cachesize太小经 验WiredTigerRocksdb索引及数据一致分片选择及索引设计集群部署及片键的选择如何支持按需拉取、字段增删?列表拉取支持复杂的过滤排序如何保证同一个文档的多个操作的并发安全原值:A:1,B:1 -线程A:A:1,B:2 -线程B:A:2,B:1加锁?cas?如何保证多个数据表之间数据一致?作品表、计数表、事务?查询某个用户的所有作品查询某个用户的所有作品查询参与了某个活动的所有作品查询参与了某个活动的所有作品分片及索引设计公开ugcid类型置顶时间大赛id半成品id伴奏iduid封面vid列表内容其

5、他详情内容作品描述索引独立字段列表其他详情字段作品数据分片1查询某个用户的作品 集群模式副本集 vs 分片集群 片键选择Hash分片 vs 范围分片直接影响一个集群的容量上限和性能上限用户uid还是作品id如何查询参与了某个活动的所有作品?全局索引问题uid是片键,创建活动id的索引通过活动id 查询有请求放大的问题增加全局数据表,活动id作为片键 索引设计索引字段,写和读性能索引比数据还大?最少匹配,最左匹配,合并索引explain(executionStats)、hint作品数据分片2作品数据分片3全局索引表分片1查询参与了某个活动的作品全局索引表分片2全局索引表分片3作品数据分片1作品数

6、据分片2作品数据分片3根据作品id查询写入时带上版本号并发控制及最终一致会话list(最多20个)作品id1+版本号1+随机数作品id2+版本号1+随机数作品id2+版本号2+随机数uidowner_num版本号V全局唯一会话listclient_num公开ugcid类型置顶时间大赛id半成品iduid版本号V全局唯一会话list半成品作品列表Bson结构每个人的作品计数Bson结构p 并发安全 Mongodb每个写操作的原子性 版本号Vp 最终一致性 ugcid+版本号+随机数确定一个操作动作 对每次操作生成一个全局唯一会话id 保证多表之间数据一致性db.ugc.findAndModify

7、(query:ugcid:“xxx”,v:10,update:$set:A:1,B:2,$inc:v:1,upsert:true)更新时自增一读写策略ugcid+版本号+随机数生成sessionidfindAndModify原子操作writeConcern=majority,journal=true根据片键路由到对应分片Mongod主机Mongod备机Mongod备机读取计数按需拉取指定readPreferreadPrefer=primary避免链式复制readPrefer=SecondaryPrefer根据片键读取目标分片优先级读取减少流量灵活定制一致性级别 数据安全 p 通过执行w=maj

8、ority&j=true让数据写大多数节点并且安全落盘后再返回,保证一条数据不丢 主从延迟解决 p 调整mongodb的主从复制策略,禁止链式复制,减少主从延迟,写操作时延从最大1s返回减少到所有写操作均在7ms内完成p 为了避免主从延迟导致更新后立刻读取的数据错乱错乱的问题,优化主人态读操作有条件主动读主 主人态而且上海品茶、主人态而且3秒内读主机 更新操作前读主机 一定时间内的新作品读取读主机写读Mgo驱动优化sessionsessionsessionpingerMaster serverSlave Serversocket socket socketpoolShrinkerunusedSoc

9、ketssocket socket socket socket socketliveSocketsMongos/(master slave)Session.Closesocket.ReleasereadLoopreadLoopreadLoopreadLoopreadLoopreadLoopreadLoopreadLoopSlave ServersyncServersLoopLogin/QueryServerconsistencymasterSocketslaveSocketmgoClustersessioncopyclonePing/isMasterPing/isMasterPing/isMa

10、sterCluster1.解决连接数限制不住的bug 2.解决有空闲链接依然去创建新链接的bug 3.连接数不够用直接返回失败不再等待4.调大isMaster和ping的发送间隔5.一般超时不再removeServer防止把所有链接全部断开连接池限制不住心跳太频繁创建连接失败清理连接池优化效果:总体连接数下降60%;100ms-500ms慢查询减少80%总体架构外包cdn外包cdn外包cdn下载网关业务接入层上传接入无状态集群冷数据存储热数据存储状态存储网关tmpfs加速断点续传 秒传边传边存上传逻辑服务伴奏调度作品调度播放调度服务中间节点回源网关决策中心播放记录冷数据存储热数据存储业务接入层

11、获取播放链接oplog同步上海idc1上海idc2上海idc3元数据列表服务上海深圳流媒体播放挑战播放总量:30天内作品占比50%,30天以外占比50%回源总量:30天内作品占比75%,30天以外占比25%长尾播放是常态,低频播放是常态 cdn只是解决热流量的问题问题:长尾情况严重,冷热划分粗放回源次数和作品发表时间对应比例(源站)播放次数和作品发表时间对应比例(OC)75%25%0%10%20%30%40%50%60%70%80%1 mon 1mon30%20%8%4%4%4%4%24%2%0%5%10%15%20%25%30%35%3 day1 mon2 mon3 mon4 mon5 mo

12、n6 mon2 year2 year数据分析-播放次数分布0.00%10.00%20.00%30.00%40.00%50.00%60.00%70.00%80.00%12-100100以上18.30%59.82%21.88%61.19%38.63%0.19%4.31%57.42%38.28%22.50%75.00%2.50%播放次数分布作品数OC流量DC流量头部中部尾部调度策略冷热温作品预测用户历史作品30天内播放次数当前作品历史30天内播放次数该作品过去30天是否有播放基于历史作品30天内播放次数进行预测取历史作品播放次数的中位数冷作品温作品温作品次数=1002=次数100次数=1002=次数

13、100次数5M开启)互拉LRU-K温作品外包CDN465%10001M无fifo热作品客户端分片播放完成度客户端分片效果10%44%9%17%30%0%5%10%15%20%25%30%35%40%45%50%30%30%-50%50%-99%100%总体优化15%20%作品的生命周期发布播放OC中间节点DC调度策略删除短视频、mv、原曲mv分片拉取下架质量差的CDN根据CDN的特性调度不同类型的流量(冷热温)冷热温预测冷作品:DC换OC长尾集中温作品:一致性hash热作品:平均调度,确保质量主动删除oc缓存总体优化-思考冷热温调度流媒体带宽节省流媒体质量提升存储成本节省综述l 百亿级请求量UGC列表数据设计方案,节省成本,提升可用性及定制化的数据安全级别,可以推广到其他类似的大列表场景,也为后续更多复杂过滤排序的设计提供了技术参考和指导,可以应用到K歌动态改造、私信、消息、附近的人、点赞和音乐的登录数据多中心部署等复杂场景l 通过作品生命周期中各个环节的特性,利用一致性hash的优势,提升播放体验的同时,优化成本,兼顾容灾能力,推广到其他产品的成本质量优化场景。求贤若渴全民K歌后台团队全民K歌客户端团队全民K歌国际化团队

友情提示

1、下载报告失败解决办法
2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
4、本站报告下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。

本文(2019年全民K歌UGC架构高可用实现.pdf)为本站 (云闲) 主动上传,三个皮匠报告文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知三个皮匠报告文库(点击联系客服),我们立即给予删除!

温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。
会员购买
客服

专属顾问

商务合作

机构入驻、侵权投诉、商务合作

服务号

三个皮匠报告官方公众号

回到顶部