close
作者簡介：
陶勇，2005年底加入阿裡巴巴，先後從事過網站架構支持，PMO等工作;2010年成為技術部分佈式數據庫技術領域帶頭人，現負責海量數據領域相關技術產品的研發及推廣，為解決網站多站點服務、數據強一致性等特性提供高可用的海量數據訪問及數據消費等技術產品及架構支持，海量數據領域涵蓋分佈式數據庫、分佈式存儲、數據實時計算等多個技術方向。
海量數據增長的挑戰
阿裡巴巴網站目前來講分為中文站、國際站，還有一些國際交易和日本站之類的一些站點。我們核心表的數據量大概都是在億和十億級別，在這樣的一個數量級下面，都會涉及到一些容量方面、性能方面，以及分佈式方面的一些問題。整個網站發展到現在已經11年到12年的時間。我們的數據量也從最開始的很少一點，擴大到現在的規模，尤其是近幾年更是呈爆發式的增長。數據庫層面來講，關鍵點是兩個，一個是之前我們一直采用的Oracle數據庫，不管是中文站還是國際站，Oracle數據庫有非常多的優點，但是隨著數據量的飛速增長，無論是用小機也好，還是更高端的存儲也好，都會帶來瓶頸的問題。我們在07年末，08年初的時候意識到瞭問題，因為那時候，我們的數據量呈現急劇上升的趨勢。當時我們考慮的是將數據庫進行拆分，拆分現在對於大傢來說都已經耳熟能詳瞭，包括水平拆分和垂直拆分。如果從數據庫角度來講，就兩個階段，是99年到08年，然後08年到現在的這個階段。08年相當於是我們從單一的Oracle數據源跨越到多數據源支持的一個關鍵時間點。從08年開始，我們經歷瞭大概一到兩年的時間，將中文站最核心的表，以及和它關聯的一些表拆分到瞭MySQL上，這時我們已經通過數據庫的水平拆分，將數據均勻的拆分到瞭MySQL集群上面。不管是TPS (Transaction Per Second)也好，容量也好，都極大的緩解瞭之前Oracle遇到過的問題，包括它的邏輯讀寫非常大，CPU也一度飆升到三四十之類的問題等。從目前來講，阿裡巴巴的數據庫，相對於其它互聯網的一些網站，比如說淘寶，比如說Twitter之類的，本身還是有一些特點的，目前來講，還是會員服務的性質為主。對於會員來講，數據的一致性以及可用性要求都是非常高。與傳統互聯網企業相比，現在大多數新型的互聯網企業在數據存儲方面的要求可能有細微的差別。所以另外一點，數據要從集中式走向分佈式。還有一點就是阿裡巴巴網站相對於其他的站點而言，是少有的跨多個IDC，具備容災備份的站點。不管是中文站還是國際站都有多個站點分佈在不同的國內，甚至是國外的一些機房裡面，這樣的話，在包括數據一致性以及數據同步這一塊，都會有一些特有的解決方案，大致就是這些特性。
應對策略：分攤與存儲數據
從數據庫層面或者數據訪問層面來講無非就是兩點，第一點，是壓力如何分攤，分攤的目的就是為瞭把集中式變為分佈式，這是其一。另外，采用多種的存儲方案，不同的業務數據，它必然會有不同的特點，針對不同的特點，我們會采用例如Oracle來存儲，或是MySQL來存，使用集中式的存儲，還是分佈式的存儲，是采用傳統的RDBMS，還是采用KV Store，或者是其他的一些存儲方案。綜合以上兩點，從數據拆分來講，我們目前在B2B更多的是水平拆分，我們把一張數據量非常大的表，上億級別數據量的表，把它從Oracle裡邊搬出來，拆分到MySQL裡邊，這是一種水平拆分的方式。我們偶爾會采用一些垂直拆分的方案，但是垂直拆分方案相對而言，是一種過渡方案，最終還是為瞭達到水平拆分的目的。其實水平拆分主要為瞭解決兩個問題，一個是，底層存儲的無關性。另外一個就是隨著數據量以及訪問請求包括TPS、QPS(Query Per Second)的壓力增長，我們能夠通過線性的去增加機器就能夠滿足要求。此外還可以利用線性的這種增長方式，去支持壓力和數據量的增長。至於多存儲方案而言，其實這跟我們的業務是有緊密關系的，比如說我們非常核心的數據，目前還是選擇存儲在Oracle裡面。像一些大數據量的，壓力非常大的這種表，我們就選擇把它拆分到MySQL數據庫裡面去。還有一種，其實就是簡單的，比如說KV Store，跟目前的NoSQL的這種選型類似，就相當於把一些關系型不是特別明顯的，例如網站的一些用戶屬性以及一些Property之類的數據，我們都把它放到KV Store裡邊去，大致，就是用這些技術手段來解決，應該說，最關鍵的一些技術解決方案，大致就是這些。
數據中心處理
就目前來講，其實有三個產品來密切配合解決這樣的一些問題，這三個產品分別是Erosa、Eromanga和Otter。可能聽上去會讓人感覺有點摸不著頭腦，不知道是幹什麼的，Erosa簡單的說就是做MySQL的Bin-Log時時解析，會對MySQL也好，還是一些其他的KV Store也好，他的BIN-LOG進行時時解析，解析完瞭之後，會放到Eromanga，Eromanga是什麼東西？其實就是增量數據的發佈訂閱的產品，Erosa產生瞭時時變更的數據發佈到Eromanga。然後，這時候，不管是搜索引擎也好，還是數據倉庫也好，還是一些關聯的業務方也好，他就可以通過訂閱的方式，把這些時時變更的數據時時的通過Push或者是Pull的方式拉到他的業務端，然後進行一些業務處理。還有一塊是Otter，其實更多的是它的定位，就是跨IDC的數據同步，之前是國際站，現在是中文站，中文站我們也有容災站點，應該不光是說容災站點，應該是AA站點，這時候，我們要求我們的數據能夠及時的反映到兩邊去，我們是通過Otter來解決這方面的問題。Otter，其實就是類似於業界，比如說現在SharePlex的這種方式的數據同步的方式，雙向同步的數據解決方案，相比而言，不管是數據庫的同步，還是說SharePlex的同步也好，我們做瞭一些定制化，包括對業務數據關聯的一些文件系統同步，我們是按照事務的方式來將數據通過Otter重組應用到另外站點的數據庫裡面去，這是相對於目前業界的一些商業產品不同的地方。
另外一個，數據同步沖突這一塊，其實阿裡巴巴站點，雖然我們現在新的一些架構都極力避免同一條數據在兩IDC機房裡面的數據庫中同時被修改，但是由於一些歷史原因，的確存在有一些業務既在這個機房裡變更，與此同時，他也會在另一個機房裡面被變更，這時候怎麼解決同步沖突。這時候我們其實這是這一塊我們目前來講，是最難解決，但是目前又還急需解決的，我們目前，當然現有的版本，暫時是一種比較簡單的方式去解決問題的。其實就是以那個站點數據為優先，站點A，比如說A機房的站點的數據是優先的，不管怎麼樣，它就覆蓋到B的，今後我們會有一些包括業務相關的策略，包括變更的時間，及沖突合並之類的方式來解決到這種雙向同步，以及變更沖突這方面的一些問題。從時時效果來看，目前來講，Erosa和Otter，目前承擔瞭幾乎B2B所有的，不管是跨IDC的還是說從跨站點的，比如說我們從中文站同步到DW，還是從國際站同步到DW，同步到其他的一些數據源。那目前來講，基本上現在已經是遍地插滿旗幟，大致情況是這樣的。
系統緩存結構設計
緩存這個東西，首先在阿裡巴巴來講，它其實是分為幾個級別的，從前到後，比如說從用戶最開始發起HTTP請求，到最後訪問數據庫，目前來講，是分瞭三級緩存的，包括圖片，包括頁面的緩存。然後直到最後面的包括數據的緩存、圖片的緩存，以及靜態頁面的緩存，相對而言，都是采用熱點數據方式，包括提高他的命中率，基本上我們的命中率都非常高，前端相對而言都比較高。對於後端比如說數據緩存這一塊，目前來講，分為Local Cache和Remote Cache，應該叫Distribute Cache。就相當於說，我們會把一些不怎麼變化的比如說屬性數據，用戶屬性，或是一些其他的屬性數據，會在Server啟動的時候，將其加載到Local Cache，這時，就不需要關心一致性的問題，反正就是啟動之後就加載到Local Cache，這是一種緩存。還有一種，就是Remote Cache，相當於是分佈式的Cache。就B2B來講，目前Cache的實現策略非常多，實現的底層不管是包括Berkeley DB也好，還是Memcache DB也好，實際有很多的。同時我們在前端也做瞭一層封裝，無論底層的Cache是用哪一種存儲實現，都能根據業務場景需要，提供出一些最優推薦。對於如何提高緩存命中率，如何進行緩存的設計，我說下B2B的一些選擇。就前端圖片和頁面來講，我們會把一些動態頁面靜態化。靜態化這塊我們有相應的產品來支持動態頁面靜態化。數據緩存這塊，我們更多的是從對象緩存的角度來看，緩存命中率更關鍵的是把緩存力度劃分的越細，命中率相對會越高。另外一塊，緩存跟業務是具有相關性的，在做架構設計時，需要確定哪些是需要緩存到裡面的，因為緩存並不是無限大的。另外，緩存是有有效期的，不可能無限的讓他存在那兒，要真是如此的話，他就不叫Cache，叫Store瞭，所以這塊，大致就是這樣一些機制。第一個是註意切分力度，什麼樣的業務需要保證什麼樣的力度，有些細力度，有些粗力度。還有一塊，如何保證緩存的生命周期，他的有效期是多久，因為不可能把所有東西都緩存到Cache裡面去。
技術部=拆遷大隊？
其實在阿裡巴巴，特別是在技術部，這邊的團隊有一個比較有意思的稱謂，叫做拆遷大隊。三國殺遊戲裡有個人物叫甘寧，就是專門負責拆牌的，這個團隊其實就是把目前Oracle中大數據量的表拆成MySQL的。
目前來講，我們拆分，其實是有幾個拆分策略的，第一個是按字段拆分，這是最細力度的。比如說一張表我按某個字段Company拆掉，我就按COMPANY_ID來拆，這是一種方式，還有一種是按表來拆，我把這張表拆到MySQL，那張表拆到MySQL集群，更類似於垂直拆分。還有一種是按Schema拆分，Schema拆分就相當於說，這是跟應用相關的。比如說我B2B這樣應用，我會把它拆分到這個Schema機群裡面來。
另外W服務我會把它的數據庫拆到另外MySQL機群。但是對外提供的還是這一組，就是前面我也提到瞭，我們說的Cobar，可能還沒提到，就是說我們其實拆分負責數據拆分，我們有產品叫做Cobar，Cobar其實類似於MySQL Proxy，他解析瞭MySQL所有的協議，就相當於是說，我們是可以把它看成MySQL Server來訪問的，它前端是掛瞭很多Cobar Server的。根據Schema拆也好，按照表拆也好，在Cobar上面會根據你的需要，去定義自己的拆分策略。拆分好後，就自動會路由到MySQL不同的服務器上面去。還有一方面其實最關鍵的是，拆掉瞭之後，怎麼樣做數據的擴容，其實我們從08年發展到現在，隻能說還在路上，因為有些自動化以及自動化的配置，其實跟流動計算是相關的，我怎麼樣要讓正在運行的，讓某MySQL機器人上來，然後，把比如說這裡有一千萬數據，我把它對等的拆成各五百萬，拆到集群上面，然後再把這臺老的，MySQL上面的五百萬老數據幹掉，我們最終理想的狀況是想自動化的完成，但目我們還是更多的是純人工的方式來做，就相當於是說先把這500萬搬過去，這時候其實有拆分原則的，但是我們內部，搬過去之後，然後再把這邊的切掉，這是純人工的。就數據遷移來講，我們內部，是有嚴格的五步走的策略，要把Oracle的一張表或者是數據庫拆分到MySQL上面去，這時候我們有嚴格的五個步驟來做的，每個步驟做完瞭，第一步驟做完瞭才能做第二個，第二個步驟做完瞭，做第三個，簡單來講其實就是說第一個Oracle讀寫，MySQL寫，就是慢慢的把一些數據寫到MySQL裡面去，這時候要做過程就是要把Oracle的的數據要做一次數據搬遷，遷移到MySQL上面。後面，就是設一些閥值。
比如說產生ID以上的一些數據，就寫到MySQL，以下的數據寫到Oracle。第二步是Oracle讀寫，然後MySQL讀，再到後面的一步一步的走，都有不同的策略，這時候，當這五步完成瞭之後，整個數據就遷移完瞭，最開始的第一個是最大的表，我們才遷移拆分，花瞭漫長的將近兩年時間，有一些原因是因為業務資源的配合問題，還有一塊我們是在摸著石頭過河，我們需要吃到一些虧，然後我們要去改進，吃到一些虧我們要去改進。
但是到現在拆分基本上都是在兩三個月就能搞定。我們沒有像一些那種新興公司，他們做數據遷移就是直接通知用戶，我停一天，或者我停幾個小時，然後我把數據遷過去，你可以繼續登陸上來。基本上我們是不允許這麼幹的，所以我們通常來講，要麼就是晚上，很短的時間點，我們把數據做一次遷移。另外一塊，我們要保證應用基本上不會受到影響，也就是說他可能需要配合我們做一些Restart，但是他的相關的一些操作，盡量不會影響到我們的網站用戶。
後臺系統，目前後臺系統通常B2B是有專門的部門叫數據倉庫，就是DW部門的，他們會把我們的數據都拉過去，然後在那邊進行一些分析。目前來講，其實五花八門用的很多，比如說Oracle Rac，比如說Greenplum，當然也會用到我們的Cobar，還會用到前面提到的Erosa。其實之前來講，首先後臺基本上是一些離線數據，但是近幾年，特別是從09年開始，我們對於後臺的一些報表分析這一塊，對於數據的時時性要求也越來越高。從去年我們時時數據中心上瞭Erosa以後，我們數據時效性，從一天已經縮短到瞭五分鐘，甚至會更快。另外一方面，Hadoop應用在B2B相對而言比較少的，因為我們更多的是采用瞭Greenplum這種方式來做，就是做一些BI分析也好，還是報表分析也好，復雜SQL都是通過Greenplum來做的。但是，隨著我們的DW業務也在增長，所以他有一些時時性的查詢需求，目前我們Cobar也會提供，他們也搭建瞭一套Cobar集群，來提供這樣的在線數據服務，其實相當於現在DW我們已經搭建瞭一套相當於是分佈式數據庫的原形，隻是我們是東品西湊的把它拼起來的，但是效果不錯，但是，總感覺不是很爽。所以接下來我們要做的，就是能夠搭建一套適用於網站OLTP，也適用於DWOLAP的這樣的一套或者是說你可以認為兩個子領域的平臺，這樣的話，就能夠做到技術可控，無論是數據訪問也好，還是整體性能也好，都能夠被滿足，至少不會比現有的差，大致情況就這樣。
分庫分表都是在Cobar產品裡面的，Cobar分為兩類，分別是Cobar Client和Cobar Server，根據業務的需要進行選擇，Cobar Server是一組獨立的(Stand Alone)的Server集群，Cobar Client就是第三方的Java包，他就直接嵌入到應用上面去。然後他的拆分規則都是直接寫到應用的配置文件裡面的。這是我們自主開發的，沒有用到外面的一些開源的工具，包括我們的SQL Parser，既然要做數據拆分，必然要解析SQL，SQL，我們之前也是自己寫的。最近新的版本已經改用純手寫的，我們計劃是提升大概四到六倍甚至十倍的性能，說到這點，我們的Cobar Client還是我們的SQL Parser，今年都有計劃把它開源出去，相當於是說我們吃瞭很多我們要回饋一些出來。還有一些工具，就是我們有一組，不管是測試環境也好，還是線上的預發佈環境也好，都有一組服務器提供給業務去負責查詢一些業務數據，或者說查詢測試環境的一些數據，去檢查它的路由規則是不是正確。
軟件信息化周刊
比特軟件信息化周刊提供以數據庫、操作系統和管理軟件為重點的全面軟件信息化產業熱點、應用方案推薦、實用技巧分享等。以最新的軟件資訊，最新的軟件技巧，最新的軟件與服務業內動態來為IT用戶找到軟捷徑。
商務辦公周刊
比特商務周刊是一個及行業資訊、深度分美國商標註冊析、企業導購等為一體的綜合性周刊。其中，與中國計量科學研究院合力打造的比特實驗室可以為商業用戶提供最權威的采購指南。是企業用戶不可缺少的智選周刊！
網絡周刊服務器周刊
比特網絡周刊向企業網管員以及網絡技術和產品使用者提供關於網絡產業動態、技術熱點、組網、建網、網絡管理、網絡運維等最新技術和實用技巧，幫助網管答疑解惑，成為網管好幫手。
服務器周刊
比特服務器周刊作為比特網的重點頻道之一，主要關註x86服務器，RISC架構服務器以及高性能計算機行業的產品及發展動態。通過最獨到的編輯觀點和業界動態分析，讓您第一時間瞭解服務器行業的趨勢。
存儲周刊安全周刊
比特存儲周刊長期以來，為讀者提供企業存儲領域高質量的原創內容，及時、全面的資訊、技術、方案以及案例文章，力求成為業界領先的存儲媒體。比特存儲周刊始終致力於用戶的企業信息化建設、存儲業務、數據保護與容災構建以及數據管理部署等方面服務。
安全周刊
比特安全周刊通過專業的信息安全內容建設，為企業級用戶打造最具商業價值的信息溝通平臺，並為安全廠商提供多層面、多維度的媒體宣傳手段。與其他同類網站信息安全內容相比，比特安全周刊運作模式更加獨立，對信息安全界的動態新聞更新更快。
新聞中心熱點美國商標類別推薦雲計算周刊
新聞中心熱點推薦
新聞中心以獨特視角精選一周內最具影響力的行業重大事件或圈內精彩故事，為企業級用戶打造重點突出，可讀性強，商業價值高的信息共享平臺；同時為互聯網、IT業界及通信廠商提供一條精準快捷，滲透力強，覆蓋面廣的媒體傳播途徑。
雲計算周刊
比特雲計算周刊關註雲計算產業熱點技術應用與趨勢發展，全方位報道雲計算領域最新動態。為用戶與企業架設起溝通交流平臺。包括IaaS、PaaS、SaaS各種不同的服務類型以及相關的安全與管理內容介紹。
CIO俱樂部周刊IT專傢網
CIO俱樂部周刊美國商標登記
比特CIO俱樂部周刊以大量高端CIO沙龍或專題研討會以及對明星CIO的深入采訪為依托，匯聚中國500強CIO的集體智慧。旨為中國傑出的CIO提供一個良好的互融互通 、促進交流的平臺，並持續提供豐富的資訊和服務，探討信息化建設，推動中國信息化發展引領CIO未來職業發展。
IT專傢網
IT專傢新聞郵件長期以來，以定向、分眾、整合的商業模式，為企業IT專業人士以及IT系統采購決策者提供高質量的原創內容，包括IT新聞、評論、專傢答疑、技巧和白皮書。此外，IT專傢網還為讀者提供包括咨詢、社區、論壇、線下會議、讀者沙龍等多種服務。
X周刊
X周刊是一份IT人的技術娛樂周刊，給用戶實時傳遞I最新T資訊、IT段子、技術技巧、暢銷書籍，同時用戶還能參與我們推薦的互動遊戲，給廣大的IT技術人士忙碌工作之餘帶來輕松休閑一刻。
AUGI SPORTS｜重機車靴｜重機車靴推薦｜重機專用車靴｜重機防摔鞋｜重機防摔鞋推薦｜重機防摔鞋
AUGI SPORTS｜augisports｜racing boots｜urban boots｜motorcycle boots
文章標籤
全站熱搜
留言列表
