2019年全民K歌UGC架構高可用實現.pdf

《2019年全民K歌UGC架構高可用實現.pdf》由會員分享，可在線閱讀，更多相關《2019年全民K歌UGC架構高可用實現.pdf（23頁珍藏版）》請在三個皮匠報告上搜索。

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歌國際化團隊