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

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

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

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

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

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

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

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

9、；能夠?qū)崿F(xiàn)ApacheIgnite的Expired、Eviction等緩存功能，頻繁更新時 不會出現(xiàn)OOM問題。那么，Blade具體是怎么做到的呢？Blade主要功能提供分布式內(nèi)存緩存，緩存對象支持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是一個Jar，應(yīng)用程序用這個Jar的API發(fā)起對Blade Cluster的 調(diào)用。Blade Client在啟動時，會從ZK上獲取到整個Bl

11、ade Cluster的運行情況。 它會監(jiān)聽ZK事件，當(dāng)Primary Node宕機或新的Secondary Node啟動了， 它可以立刻得到通知。Blade Client使用一致性Hash算法，把Key盡量均勻分布在整個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目前，我們選擇第二種，即一個Blade Server包含一個Jetty和一個Redis。Jetty和Redis部署在一個節(jié)點上，能夠保證在不占用系統(tǒng)帶寬的情況下實現(xiàn)對bitmap 索引的高速存取。Redis只作為一個大緩存使用，Redis本身的分片、集群、主備等功能 全部都不使用，因為Blade本身架構(gòu)就已經(jīng)實現(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é)點Blade Server宕機后，丟失緩存對象信息， 同一個復(fù)制組中的Blade Server緩存對象會保持一致。每個復(fù)制組中可以有1到N個Blade Server。一般來說，每個復(fù)制組中有2個BladeServer足以。需要注意的是，相同Replica Group中的Blade Server的硬件配置需要一致， 最好分別運行在不同的主機上。模塊：Data SyncDispatcher

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

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