余額寶的技術(shù)架構(gòu)課件

余額寶的技術(shù)架構(gòu)樊振華1234600天600天12.3112.311）運行時長≥1.5萬小時2）累計交易≥15億筆3）基金規(guī)?！?700億4）用戶數(shù)≥1.5億余額寶驚人的數(shù)字技術(shù)創(chuàng)新嵌入式直銷技術(shù)跨越新型云直銷嵌入式、清算整合、每日結(jié)轉(zhuǎn)T0交易、一鍵開戶IOE架構(gòu)，壓力已行業(yè)最大值支持交易>=3億，賬戶數(shù)>=800萬去IOE,選擇云計算，跨越式邁進面向未來，支持雙十一指標(biāo)實現(xiàn)行業(yè)第一，插上業(yè)務(wù)騰飛的翅膀雙十一清算輕松完成，小收益快體驗余額寶系統(tǒng)技術(shù)創(chuàng)新之路技術(shù)創(chuàng)新的飛躍一期架構(gòu)下的瓶頸網(wǎng)絡(luò)鏈路長，對天弘端的基礎(chǔ)環(huán)境要求極高；擴展性不夠，部分核心業(yè)務(wù)邏輯寫到了DB層，非常依賴ORACLE的處理能力；未做分布式處理，單點的資源壓力極大；單位建設(shè)成本高，IOE的購置和維護成本很大；基于阿里云的架構(gòu)上云前的難點內(nèi)憂外患，一期系統(tǒng)僅上線試運行一周，功能仍需完善；系統(tǒng)設(shè)計是否能通過監(jiān)管要求，仍心存忐忑；超高指標(biāo)，交易并發(fā)數(shù)從一期400指標(biāo)突越至4000以上，幾乎沒任何心理準(zhǔn)備和技術(shù)可行方案；全面短缺，時間、資源、人力都嚴(yán)重不足，從技術(shù)方案評估到研發(fā)完成只有2個月；研發(fā)團隊完全沒有云計算的工作經(jīng)歷，幾乎沒人熟悉mysql；分庫分表和文件處理如何分？數(shù)輪討論后，敲定按賬戶來分，根據(jù)簽約協(xié)議號的后三位來均等分配。哪些表分？賬戶、交易、份額、份額明細、份額變動；歷史表怎么辦？合并數(shù)據(jù)導(dǎo)入數(shù)據(jù)倉庫，再按時間來分；交互文件如何處理？每日須實時交易和文件逐筆對賬，每小時一個文件，每天24個文件，再合并拆分成1000個節(jié)點導(dǎo)入對應(yīng)的數(shù)據(jù)庫；資產(chǎn)收益文件做導(dǎo)出合并；清算指標(biāo)對比上云前上云后步驟時間（秒）步驟時間（秒）日初3994.77日初57.84數(shù)據(jù)導(dǎo)入996.53處理前備份94.27處理前備份543.3清算批檢查11.92生成清算預(yù)檢列表60清算批處理59.45清算預(yù)檢116.08清算批處理數(shù)據(jù)同步60生成清算處理列表90快贖前備份106.88清算處理3905.73快贖導(dǎo)入7.34清算后提示信息60快贖批檢查11.5支付匯總10.8快贖批處理26.3支付導(dǎo)出396.53快贖批處理數(shù)據(jù)同步1數(shù)據(jù)匯總2686.2支付處理40.7數(shù)據(jù)導(dǎo)出4162.26支付處理數(shù)據(jù)同步120日終11099.27支付導(dǎo)出7.94

批后處理12.89

批后統(tǒng)計27.75

批后統(tǒng)計數(shù)據(jù)同步90

數(shù)據(jù)導(dǎo)出4.13

日終246.98

份額同步12.61總計28121.47總計999.5清算效率提升近30倍二期架構(gòu)下的問題多節(jié)點下的數(shù)據(jù)呈現(xiàn)還有點改進；應(yīng)用狀態(tài)監(jiān)控還未能做到事前預(yù)警；程序調(diào)試和發(fā)布比較繁瑣；清算過程和文件交互處理仍需要技術(shù)配合；余額寶的數(shù)據(jù)架構(gòu)實時離線算法建模分類/聚類/回歸/神經(jīng)網(wǎng)絡(luò)/…云數(shù)據(jù)中心業(yè)務(wù)數(shù)據(jù)日志數(shù)據(jù)外部數(shù)據(jù)其他數(shù)據(jù)數(shù)據(jù)接入RDS/ADSODPS/OSS數(shù)據(jù)倉庫數(shù)據(jù)實驗室自主開發(fā)數(shù)據(jù)工具采云間（DPC）外部開發(fā)行為監(jiān)督權(quán)限管理安全審計隱私保護業(yè)務(wù)支持生產(chǎn)分析數(shù)據(jù)監(jiān)控資金預(yù)測運營支持合規(guī)風(fēng)