億在線背后的故事騰訊最新PPT.ppt

1、騰訊大講堂走進北航,2011.10.31 D,1.4億在線背后的故事,騰訊科技（深圳）有限公司 即通平臺部高級技術總監(jiān) icezhuang,QQ IM后臺架構的演化與啟示,自我介紹,2001-中國科學技術大學計算機系本科畢業(yè),2004-中國科學院計算技術研究所碩士畢業(yè),2004-進入騰訊，參與IM后臺研發(fā)運營,T4專家 即通平臺部 高級技術總監(jiān) 公司軟件開發(fā)通道分會 會長 經歷了QQ在線從千萬級到億級的過程,7億活躍賬戶,1.4億同時在線,過萬臺IM服務器,百億級的關系鏈對數(shù),每天千億級的服務請求,99.99%的可用性,團隊經歷了QQ在線從10萬到1.4億的整個過程，吸取了很多教訓,對海量服務

2、的理解是長期積累的結果,目錄,從十萬級到百萬級在線 千萬級在線 億級在線 總結,IM后臺1.0,適用情況,同時在線數(shù)較低（十萬級） 業(yè)務功能非常簡單,1.0接入服務器的核心數(shù)據結構,OnlineIndex,OnlineRecord,IM后臺1.0的典型業(yè)務流程,登錄,實時通知 定期拉取,在線狀態(tài)的獲取,IM后臺1.5,需要更好地支持業(yè)務 支持視頻、語音、傳文件等實時寬帶業(yè)務 支持更多類型的用戶資料 增加長連接服務器 為無法直連的客戶端進行實時寬帶數(shù)據中轉 對存儲服務器進行輕重分離 核心服務器保證穩(wěn)定 擴展服務器快速支持業(yè)務,第一代架構難以支持百萬級在線,達到一百萬在線時，老架構會有各方面的瓶頸

3、出現(xiàn) 以接入服務器的內存為例，單個在線用戶的存儲量約為2KB 索引和在線狀態(tài) 50字節(jié) 好友表 400個好友 * 5字節(jié)/好友 = 2000字節(jié) 大致來說，2G內存只能支持一百萬在線用戶 進一步地，還有CPU/網卡包量和流量/交換機流量等瓶頸 其他服務器也有類似情況 單臺服務器支撐不下所有在線用戶/注冊用戶,第一代架構無以為繼，必須升級！,IM后臺2.0,單臺服務器擴展成集群 增加狀態(tài)同步服務器 在接入服務器之間同步在線狀態(tài),2.0接入服務器的核心數(shù)據結構,0,1,10001,10002,10003,10004,OnlineIndex,LocalOnlineRecord,RemoteOnlin

4、eRecord,UIN 在線狀態(tài)，IP/Port 接入服務器ID,IM后臺2.0的典型業(yè)務流程,2001年，QQ同時在線突破一百萬,登錄,定期拉取 實時通知,在線狀態(tài)的獲取,（三種方式）,IM后臺2.5,支持QQ群等新業(yè)務,啟示：十萬級到百萬級在線的關鍵技術,高性能；7乘24小時連續(xù)服務,Kenny“違抗”PonyMa的故事 ARPU對比：中國移動73，騰訊2.5 PCU/Box：某著名IM數(shù)萬；QQ 數(shù)十萬 CTO：IT成本的高低決定互聯(lián)網企業(yè)的存亡 只用傳統(tǒng)IT行業(yè)1/10到1/100的IT成本 高性能 OICQ的故事 用戶忍耐度對比：信用卡系統(tǒng)維護VS用腳投票 7乘24小時連續(xù)服務,QQ

5、后臺如何實現(xiàn)高性能,絕不使用企業(yè)級解決方案 邏輯層多進程 萬有一失的無鎖設計 用戶態(tài)IPC MySQL分庫分表 好友表自寫文件存儲 ,用戶10003，好友表：10001,0 x0；10020,0 x0,用戶10003，好友表：10001,0 x0；10020,0 x1,用戶10003，好友表：10001,0 x0；10005,0 x1；10020,0 x0,QQ后臺如何實現(xiàn)高性能,絕不使用企業(yè)級解決方案 邏輯層多進程 萬有一失的無鎖設計 用戶態(tài)IPC MySQL分庫分表 好友表自寫文件存儲 ,UIN 10001,UIN 10001,FList, L2,FList, L3,UIN 10001 L

6、EVEL 1, POS 1,UIN 10004 LEVEL 1, POS 3,OnlineRecord,UIN 10004,UIN 1000？,QQ后臺如何實現(xiàn)7乘24小時連續(xù)服務,大系統(tǒng)小做 平滑重構 在高速行駛的列車上更換發(fā)動機 核心數(shù)據放入共享內存 接入層與邏輯層分離 命令分發(fā)動態(tài)配置化,目錄,從十萬級到百萬級在線 千萬級在線 億級在線 總結,第二代架構難以支持千萬級在線,同步流量太大，狀態(tài)同步服務器遇到單機瓶頸 所有在線用戶的在線狀態(tài)信息量太大，單臺接入服務器存不下 如果在線數(shù)進一步增加，則甚至單臺狀態(tài)同步服務器也存不下 單臺狀態(tài)同步服務器支撐不下所有在線用戶 單臺接入服務器支撐不下所

7、有在線用戶的在線狀態(tài)信息,第二代架構無以為繼，必須再次升級！,IM后臺3.0,狀態(tài)同步服務器改造成同步集群 其他集群也做相應的改造,2005年，QQ同時在線突破一千萬,根本來不及高興：我們再也受不了了！,手機從不敢離身 發(fā)布新代碼提心吊膽 時不時要擴容，又煩又怕 時不時要緊急恢復服務 時不時被用戶罵、被老板K 到底怎么了？,深入分析，我們發(fā)現(xiàn)了什么,后臺機器越來越多，單機死機/故障經常出現(xiàn)，IDC故障也不少，影響服務，也影響人員生活 每周有新代碼發(fā)布，BUG不斷出現(xiàn)，嚴重影響服務 監(jiān)控機制原始、報警設置不全，出事了都不知道 運維操作通過vim或者mysql進行，非常容易失誤,問題分析和解決（1

8、）,后臺機器越來越多，單機死機/故障經常出現(xiàn)，IDC故障也不少，影響服務，也影響人員生活 傳統(tǒng)行業(yè)設備少單價高，故障很少出現(xiàn) 互聯(lián)網行業(yè)設備多單價低，故障是常態(tài),IM后臺3.0的容錯/容災分析,每個集群只有一份 機器選擇全人工配置 集中在一個IDC,IDC的實際可用性只有2個9,老架構沒前途，必須進行容災改造！,租來的IDC的級別： B或C,容災改造的思路,存儲集群：半自動切換模式 主/從服務器 從服務器死機，業(yè)務不受影響 主服務器死機，多數(shù)命令不受影響，修改資料命令受影響 業(yè)務集群、接入集群、同步集群：自動切換模式 迅速應對死機等情況，基本不影響業(yè)務 分布在兩套IDC 可以應對IDC整體故障

9、,業(yè)務集群的容災改造,業(yè)務命令流,設備狀態(tài)流,接入集群,業(yè)務集群 IDC1,業(yè)務集群 IDC2,指揮中心 IDC1,指揮中心 IDC2,問題分析和解決（2）,每周有新代碼發(fā)布，BUG不斷出現(xiàn)，嚴重影響服務 大部分子系統(tǒng)每周發(fā)布一個版本的新代碼 解決方法 代碼review 灰度發(fā)布,第一周 周末,灰度發(fā)布演示,號段7-8,號段7-8,號段5-6,號段5-6,號段3-4,號段3-4,號段1-2,號段1-2,第一周 周一,第一周 周二,第一周 周三,第一周 周四,第一周 原來,周一,周二,周三,周四,問題分析和解決（3）,監(jiān)控機制原始、報警設置不全，出事了都不知道 CPU 100%的故事 解決方法 完善監(jiān)控和報警,完善監(jiān)控和報警,完善監(jiān)控和報警,完善監(jiān)控和報警,完善監(jiān)控和報警,完善監(jiān)控和報警,問題分析和解決（4）,運維操作通過vim或者mysql進行，非常容易失誤 Grandy的故事 解決方法 運維操作Web化（