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