基于內(nèi)存的分布式計(jì)算架構(gòu)

1、基于內(nèi)存的分布式計(jì)算架構(gòu)技術(shù)創(chuàng)新 變革未來(lái)問(wèn)題我們團(tuán)隊(duì)負(fù)責(zé) 移動(dòng)運(yùn)營(yíng)平臺(tái)企業(yè) 版V3.0 及后續(xù)版本 迭代， 當(dāng)時(shí)的設(shè)計(jì) 目標(biāo)支撐500w日活， 數(shù)據(jù)庫(kù)使用MySQL 。有一天，我們的一個(gè)客 戶，他們上線了幾個(gè)日活量 較大的APP，系統(tǒng)的整體日活 達(dá)到了2000萬(wàn)，運(yùn)維人員反 映MySQL的binlog增長(zhǎng)很快， 快把剩余磁盤(pán)空間占滿了。事實(shí)證明移動(dòng)運(yùn) 營(yíng)平臺(tái)企業(yè)版V3.0 能 夠滿足絕大多數(shù)企業(yè) 客戶的需求， 能夠穩(wěn) 定地支撐他們的業(yè)務(wù)。500 W500 W2000 W企業(yè)客戶APP日活設(shè)計(jì)目標(biāo)問(wèn)題分析 1我們使用了bitmap索引 技術(shù)保證移動(dòng)運(yùn)營(yíng)各項(xiàng)指標(biāo)（如日活、留存、轉(zhuǎn)化漏斗 等） 的

2、 實(shí)時(shí) 計(jì)算， 因?yàn)?bitmap索引高效且能節(jié)省存 儲(chǔ)空間，它能很方便地做指 標(biāo)的實(shí)時(shí)排重。第1位 設(shè)備1第2位 設(shè)備2第3位 設(shè)備3第N-1位 設(shè)備N(xiāo)-1第N位 設(shè)備N(xiāo)0000001設(shè)備12設(shè)備23設(shè)備3N-1設(shè)備N(xiāo)-1N設(shè)備N(xiāo)001010bitmapbitmap當(dāng)天8：10，設(shè)備3和設(shè)備N(xiāo)-1訪問(wèn)了APP1設(shè)備12設(shè)備23設(shè)備3N-1設(shè)備N(xiāo)-1N設(shè)備N(xiāo)011010bitmap當(dāng)天9：20，設(shè)備2和設(shè)備N(xiāo)-1訪問(wèn)了APP某APP某天0：0的初始活躍狀態(tài)問(wèn)題分析 2我們使用MySQL 存儲(chǔ)bitmap 索引， 因 為MySQL穩(wěn)定且易于 運(yùn)維。我們將bitmap 對(duì)象作 為blob類型存入M

3、ySQL，對(duì) bitmap 索引的某一位更新 時(shí)需要先從DB查詢出來(lái)， 更新之后再u(mài)pdate 到DB 中。更新后 Bitmap 13MBMySQLAPP數(shù)據(jù)處理 程序但是， MySQL本身 在 業(yè) 務(wù) 上 是 不 支 持 bitmap類型的數(shù)據(jù)，不 能夠發(fā)送指令給MySQL 讓它把bitmap的某一位 設(shè)置為1或0。更新前 Bitmap 13MB1.查詢某個(gè)維度的bitmap， 比如說(shuō)今天的活躍用戶。2.設(shè)置某一位為 13.更新到DB（網(wǎng)絡(luò)IO）網(wǎng)絡(luò)IO磁盤(pán)4.寫(xiě)binlog（磁盤(pán)IO）問(wèn)題分析 3100w存量用戶，隨機(jī)60w日活，每個(gè)bitmap原始大小 130KB，壓縮后126KB200

4、0w存量用戶，隨機(jī)200w日活，每個(gè)bitmap原始大小 2.6MB，壓縮后1.5MB1億存量用戶，隨機(jī)500w日活，每個(gè)bitmap原始大小 11.5MB，壓縮后5.2MB每個(gè)bitmap對(duì) 象的大小從數(shù)百 KB到數(shù)MB不等。數(shù)據(jù)分析：頻繁地更新blob二進(jìn)制數(shù)據(jù)，導(dǎo)致binlog數(shù)據(jù)量極大，從而導(dǎo)致存儲(chǔ)空間不夠用。 這就是前面某客戶出現(xiàn)瓶頸的原因所在。問(wèn)題域大塊（1M10M）的二進(jìn)制 對(duì)象（約30w個(gè)bitmap對(duì)象）頻 繁讀寫(xiě)，導(dǎo)致網(wǎng)絡(luò)IO、磁盤(pán)IO等 資源耗費(fèi)巨大，MySQLbinlog增 長(zhǎng)過(guò)快導(dǎo)致存儲(chǔ)空間不夠與浪費(fèi)。我們需要考慮如何在分布 式內(nèi)存中計(jì)算以解決此類問(wèn)題， 解決方案需要

5、滿足：第一個(gè)，緩存?zhèn)浞莸诙€(gè)，性能高第三個(gè)，易于維護(hù)候選解決方案方案一： 替換MySQL ， 使用druid/rockdb等大數(shù)據(jù)組件方案二：在MySQL前面引入redis緩 存層，定時(shí)同步到MySQL方案三：調(diào)研使用Apache Ignite組件為什么不選用Druid/RockDB方案我們?cè)诨ヂ?lián)網(wǎng)研發(fā)線使用了此種方案，但調(diào)研下來(lái)不適合企業(yè)側(cè)產(chǎn)品研發(fā)：原來(lái)我們的系統(tǒng)運(yùn)維工作很少，整個(gè)2000萬(wàn)日活體量的系統(tǒng)，也只需要1個(gè)運(yùn)維人 員；而換了Druid/rockdb，需要有較多的運(yùn)維工作，等于放棄了我們?cè)械膬?yōu)勢(shì)， 增加了對(duì)客戶運(yùn)維人員的要求。Druid/RockDB 需要大量的服務(wù)器資源。為什么

6、不選用純Redis緩存方案Redis在高并發(fā)下不能支撐對(duì)較大bitmap索引的頻繁更新，單個(gè)bitmap索引平均能 夠達(dá)到2、3MB，而Redis的value達(dá)到1MB時(shí)吞吐量不到1000每秒，遠(yuǎn)遠(yuǎn)達(dá)不到要 求的吞吐量。另外一個(gè)重要的原因是Redis的事件機(jī)制有問(wèn)題，expired和eviction事件拿不到緩 存對(duì)象的值，這樣會(huì)導(dǎo)致一旦緩存對(duì)象過(guò)期或被驅(qū)逐，我們無(wú)法把緩存對(duì)象更新 到數(shù)據(jù)庫(kù)。對(duì)大塊bitmap索引的頻繁更新，導(dǎo)致存儲(chǔ)空間耗用巨大，而且大塊數(shù)據(jù)的復(fù)制延 遲很?chē)?yán)重，Redis變得不穩(wěn)定。為什么不選用Apache Ignite方案使用了數(shù)據(jù)備份功能，因?yàn)轭l繁更新較大的bitmap索

7、引，涉及到數(shù)據(jù)在不同節(jié)點(diǎn) 的備份，導(dǎo)致系統(tǒng)不穩(wěn)定，經(jīng)常出現(xiàn)OOM問(wèn)題。最終方案權(quán)衡下來(lái)，我們決定基于Ehcache、redis和zookeeper實(shí)現(xiàn)一套分布式緩存計(jì)算框架。分布式緩存計(jì)算框架簡(jiǎn)介代號(hào)Blade，意在像鋒利的刀鋒一樣有效解決企業(yè)產(chǎn)品的問(wèn)題它是一個(gè)bitmap索引計(jì)算的加速框架，專門(mén)針對(duì)海量bitmap索引計(jì)算時(shí)頻繁更新DB操作進(jìn)行優(yōu)化。它會(huì)把bitmap索引緩存在內(nèi)存中，數(shù)據(jù)處理程序只需要告訴Blade修改哪個(gè)bit即可， 無(wú)需把整條bitmap索引從DB拉取到本地更新后再寫(xiě)回DB，Blade會(huì)負(fù)責(zé)內(nèi)存中的 bitmap索引與MySQL的同步。更新后 Bitmap 13MBMy

8、SQLAPP數(shù)據(jù)處理 程序更新前 Bitmap 13MB1.設(shè)置某個(gè)維度的 bitmap的某一位為14.設(shè)置某些位為 15.更新到DB（網(wǎng)絡(luò)IO）Blade3.定時(shí)（如每?jī)尚r(shí)） 獲取該維度的bitmap 。2.設(shè)置某一位為1磁盤(pán)6.寫(xiě)binlog（磁盤(pán)IO）網(wǎng)絡(luò)IO為什么Blade？Blade能夠減少更新MySQL中bitmap索引數(shù)據(jù)的頻率，徹底解決大活躍客戶出現(xiàn)的問(wèn) 題，對(duì)比之前提出的三種候選解決方案，它主要有如下優(yōu)勢(shì)：基于成熟的組件（Ehcache、redis、zookeeper），易于維護(hù)；對(duì)比單純使用redis，不需要處理達(dá)2到3MB的bitmap索引數(shù)據(jù)，系統(tǒng) 穩(wěn)定，高并發(fā)有保證

9、；能夠?qū)崿F(xiàn)ApacheIgnite的Expired、Eviction等緩存功能，頻繁更新時(shí) 不會(huì)出現(xiàn)OOM問(wèn)題。那么，Blade具體是怎么做到的呢？Blade主要功能提供分布式內(nèi)存緩存，緩存對(duì)象支持Replication、 Expired、 Eviction等提供UI監(jiān)控、管理Blade主要模塊及架構(gòu)Blade Client客戶端Blade Cluster 集群Replica Group 復(fù)制組Blade Server 服務(wù)Blade Data Sync數(shù)據(jù)同步Blade Admin管理Application(數(shù)據(jù)處理程序)Blade Client客戶端Blade Server(Primary

10、)主服務(wù) Blade Server(Secondary)從服務(wù)Blade Admin管理ZooKeeper協(xié)調(diào)器Blade Data Sync主數(shù)據(jù)同步Replica Group 復(fù)制組Blade Server(Primary)主服務(wù)Replica Group 復(fù)制組Blade Cluster 集群Data Persistence（MySQL）Blade Data Sync Backup從數(shù)據(jù)同步日志模塊：Blade ClientBlade Client是一個(gè)Jar，應(yīng)用程序用這個(gè)Jar的API發(fā)起對(duì)Blade Cluster的 調(diào)用。Blade Client在啟動(dòng)時(shí)，會(huì)從ZK上獲取到整個(gè)Bl

11、ade Cluster的運(yùn)行情況。 它會(huì)監(jiān)聽(tīng)ZK事件，當(dāng)Primary Node宕機(jī)或新的Secondary Node啟動(dòng)了， 它可以立刻得到通知。Blade Client使用一致性Hash算法，把Key盡量均勻分布在整個(gè)Blade Cluster的所有ReplicaGroup上。模塊：Blade ServerBlade Server可以有三種架構(gòu)：Redis(Value)EhCache(Key)Jetty ServerRedis Node 1 (Value)EhCache(Key)Jetty ServerRedis Node 2 (Value)EhCache(Key)EhCache(Valu

12、e)Jetty Server目前，我們選擇第二種，即一個(gè)Blade Server包含一個(gè)Jetty和一個(gè)Redis。Jetty和Redis部署在一個(gè)節(jié)點(diǎn)上，能夠保證在不占用系統(tǒng)帶寬的情況下實(shí)現(xiàn)對(duì)bitmap 索引的高速存取。Redis只作為一個(gè)大緩存使用，Redis本身的分片、集群、主備等功能 全部都不使用，因?yàn)锽lade本身架構(gòu)就已經(jīng)實(shí)現(xiàn)了這些功能。模塊：Replica GroupBladeServerBladeServerBlade Client 1Bitmap (Key=a)Bitmap (Key=a)Primary NodeSecondary NodeSet bit 5 = 1 whe

13、re key = aSeq num = 198776658388Set bit 5 = 1 where key = aSeq num = 198776658388Replica Group復(fù)制組主要用于防止單節(jié)點(diǎn)Blade Server宕機(jī)后，丟失緩存對(duì)象信息， 同一個(gè)復(fù)制組中的Blade Server緩存對(duì)象會(huì)保持一致。每個(gè)復(fù)制組中可以有1到N個(gè)Blade Server。一般來(lái)說(shuō)，每個(gè)復(fù)制組中有2個(gè)BladeServer足以。需要注意的是，相同Replica Group中的Blade Server的硬件配置需要一致， 最好分別運(yùn)行在不同的主機(jī)上。模塊：Data SyncDispatcher

14、ThreadSync Thread GroupHashData Sync負(fù)責(zé)把緩存中的bitmap索引定時(shí)同步到Data Persistence中。Data Sync采用主備架構(gòu)，平時(shí)由主節(jié)點(diǎn)負(fù)責(zé)同步數(shù)據(jù)，當(dāng)主節(jié)點(diǎn)掛掉時(shí)由從節(jié)點(diǎn)負(fù)責(zé)同步 數(shù)據(jù)。Data Sync使用Dispatcher Thread遍歷Primary Node的所有Key，Dispatch Thread會(huì)根 據(jù)Key做Hash，把Key的同步操作分配給后面的Sync Thread Group中的一個(gè)線程來(lái)執(zhí)行。為了提高性能，每個(gè)Sync Thread都有一個(gè)Queue，異步處理請(qǐng)求。Dispatcher ThreadSync

15、Thread 1Sync Thread 2Sync Thread NQueue 1Queue 2Queue 3模塊：Blade AdminBlade Admin主要用于監(jiān)控整個(gè)Blade Cluster的情況：每個(gè)Blade Server的情況Replica Group的情況Blade Data Sync的同步情況Blade Admin還提供以下管理功能：?jiǎn)?dòng)某個(gè)Replica Group的Primary Node、Secondary Node之間的同步啟動(dòng)Blade Data Sync的同步壓力測(cè)試：測(cè)試場(chǎng)景模擬2000w日活用戶，每個(gè)用戶產(chǎn)生20條日志，每條日志大小約為12KB，總計(jì) 約4.8TB數(shù)據(jù)。2000w日活20 條日志/用戶12 KB/日志4.8TB 數(shù)據(jù)壓力測(cè)試：資源配置壓力測(cè)試：測(cè)試結(jié)果（不使用Blade）MySQL binlog 2TB 左右處理4.8T數(shù)據(jù)約需要70小時(shí)不能支撐2000萬(wàn)日活壓力測(cè)試：測(cè)試結(jié)果（Blade架構(gòu)）MySQL binlog 50