支付寶數(shù)據(jù)平臺(tái)架構(gòu)師代志遠(yuǎn)為大家?guī)砹祟}為“HBase系統(tǒng)故障恢復(fù)的優(yōu)化實(shí)踐分享"的精彩演講，他分析了支付寶海量數(shù)據(jù)在線處理的現(xiàn)狀，以HBase解決方案取代傳統(tǒng)MySQL解決方案的技術(shù)歷程，并詳盡分享了RegionServer的宕機(jī)恢復(fù)流程?！綜SDN現(xiàn)場(chǎng)報(bào)道】第四屆中國(guó)云計(jì)算大會(huì)將于2012年5月23-25日在北京國(guó)家會(huì)議中心隆重舉行。本次大會(huì)由中國(guó)電子學(xué)會(huì)主辦，北京市經(jīng)濟(jì)和信息化委員會(huì)協(xié)辦，中國(guó)云計(jì)算技術(shù)與產(chǎn)業(yè)聯(lián)盟、中國(guó)電子學(xué)會(huì)云計(jì)算專家委員會(huì)承辦，CSDN與《程序員》雜志協(xié)辦。在2012國(guó)內(nèi)公共云全面開花、云計(jì)算實(shí)踐元年之際，本次大會(huì)云集云計(jì)算核心專家，就國(guó)內(nèi)外云計(jì)算核心技術(shù)以及行業(yè)應(yīng)用創(chuàng)新實(shí)踐進(jìn)行了深入探討。支付寶數(shù)據(jù)平臺(tái)架構(gòu)師代志遠(yuǎn)為大家?guī)砹祟}為"HBase系統(tǒng)故障恢復(fù)的優(yōu)化實(shí)踐分享"的精彩演講，他分析了支付寶海量數(shù)據(jù)在線處理的現(xiàn)狀，以HBase解決方案取代傳統(tǒng)MySQL解決方案的技術(shù)歷程，并詳盡分享了RegionServer的宕機(jī)恢復(fù)流程。支付寶數(shù)據(jù)平臺(tái)架構(gòu)師代志遠(yuǎn)以下為文字實(shí)錄：非常高興來到這個(gè)平臺(tái)能和大家一起分享我們自己所做過技術(shù)上的研究和優(yōu)化。剛才聽過各位架構(gòu)師和經(jīng)理的演講，大部分提到了是來自離線方面的計(jì)算和存儲(chǔ)，我們公司的業(yè)務(wù)價(jià)值最直接的體現(xiàn)其實(shí)來自于在線方面，我們海量數(shù)據(jù)它的存儲(chǔ)和計(jì)算能力，如果能夠體現(xiàn)在在線平臺(tái)當(dāng)中，將會(huì)給公司業(yè)務(wù)價(jià)值帶來非常大的提升。在Hadoop的體系當(dāng)中，支持實(shí)時(shí)的一條線，HBase，支持海量數(shù)據(jù)庫初衷的時(shí)候，設(shè)計(jì)為了設(shè)計(jì)萬一級(jí)實(shí)時(shí)數(shù)據(jù)庫，HBase這個(gè)東西經(jīng)過這幾年的發(fā)展，已經(jīng)逐漸成為現(xiàn)在業(yè)界當(dāng)中主要的實(shí)時(shí)數(shù)據(jù)庫，分布式數(shù)據(jù)庫，像我們公司一樣做一些系統(tǒng)，直接上HBase等系統(tǒng)，考慮到HBase它的先進(jìn)架構(gòu)，能夠幫助我們完成現(xiàn)在很多的海量數(shù)據(jù)的存儲(chǔ)在線隨機(jī)讀寫高性能的訪問和存儲(chǔ)。像HBase這種當(dāng)前發(fā)展試圖正使勁得系統(tǒng)，Hadoop作為技術(shù)體系在每一個(gè)階段，數(shù)據(jù)大小階段有各種不同的問題，從幾十臺(tái)到幾百臺(tái)，到上萬臺(tái)，每個(gè)階段碰到一些問題，從幾臺(tái)到上百臺(tái)，包括數(shù)據(jù)量的增長(zhǎng)，都會(huì)碰到這樣的問題，我們今天的分享主要介紹HBase在支付寶的系統(tǒng)當(dāng)中的故障恢復(fù)，這方面我們所做的優(yōu)化實(shí)踐。在HBase的系統(tǒng)當(dāng)中,體現(xiàn)它的可用性有幾個(gè)風(fēng)險(xiǎn)。第一個(gè)是HBase本身在底層依賴的HDFS，加載了唯一塊數(shù)據(jù)，單臺(tái)機(jī)器保證一致性，HDFS保持了冗余。第二點(diǎn)，恢復(fù)過程當(dāng)中，F(xiàn)ailover過程非常復(fù)雜，這個(gè)時(shí)間消耗越長(zhǎng)，作為在線系統(tǒng)，這種時(shí)間越長(zhǎng)可能會(huì)影響到在線訪問用戶體驗(yàn)。第三點(diǎn)它依賴的HDFS，HBase作為在線數(shù)據(jù)庫依賴HDFS有故障的，經(jīng)過幾小時(shí)恢復(fù)提供生產(chǎn)業(yè)務(wù)，對(duì)業(yè)務(wù)方?jīng)]有直接感受，作為在線系統(tǒng)如果掛掉，我們經(jīng)過近小時(shí)恢復(fù)恐怕直接來自于支付寶夕陪陽勺用戶投訴支付寶了。HBase目前它自己的監(jiān)控體系尚不完善，目前的監(jiān)控力度非常得粗，只能監(jiān)控到單臺(tái)的RegionServer的情況，看不到當(dāng)前用戶表有多少讀寫比例，看不到當(dāng)前服務(wù)結(jié)點(diǎn)寫作量多少，讀出量多少。今天演講主題大綱是這樣幾塊內(nèi)容，支付寶這邊消費(fèi)記錄這個(gè)項(xiàng)目作為一個(gè)背景，切入到所做的優(yōu)化過程。第二個(gè)，提到RegionServer恢復(fù)過程中有哪些關(guān)鍵流程。第三個(gè)，優(yōu)化架構(gòu)怎么樣。第四對(duì)監(jiān)控方面做了哪些共享？支付寶消費(fèi)記錄在2011年規(guī)劃上線選擇HBase的版本0.90X版本開始出現(xiàn)了0.92、0.94、0.96，每個(gè)版本推出了自己不同的特性，作為穩(wěn)定的版本來說0.90X系列，初中選擇了0.090X相對(duì)穩(wěn)定的版本，我們目前計(jì)劃當(dāng)中消費(fèi)記錄這個(gè)項(xiàng)目還可以打算使用HBase0.92，它的新的特性Coprocessors。我們支付寶消費(fèi)記錄這張表，數(shù)據(jù)量非常龐大，保留了所有用戶使用支付寶的記錄，這張表具有數(shù)百億條，存儲(chǔ)空間不算在HDFS的冗余，有近百T還是經(jīng)過壓縮之后，如果不壓縮存儲(chǔ)空間是非常可怕的，我們索引表就已經(jīng)達(dá)到數(shù)千億條，這恐怕也是業(yè)內(nèi)很難碰到的大表，這種是真正意義上的大表。到目前來說，支付寶業(yè)務(wù)隨著電子支付這塊行業(yè)的高速膨脹，它的業(yè)務(wù)增長(zhǎng)量非常大增長(zhǎng)速度非常得高，增長(zhǎng)速度直接體現(xiàn)在整個(gè)系統(tǒng)存儲(chǔ)，每年翻番的增長(zhǎng)量增加存儲(chǔ)，我們?cè)械南到y(tǒng)很難支持海量數(shù)據(jù)的增長(zhǎng)，因?yàn)橥卣鼓芰]有辦法非常動(dòng)態(tài)自主進(jìn)行擴(kuò)張，我們HBase恰恰滿足了這種情況。當(dāng)我們?cè)诨貞浿Ц秾毑樵冞^程當(dāng)中查詢記錄都是時(shí)間段的查詢，時(shí)間的特性可以看出來，我們時(shí)間為排序的都是業(yè)務(wù)的要求，我們作為在線用戶查詢，想要自己的消費(fèi)記錄，肯定要有一點(diǎn)響應(yīng)非常高，肯定不是離線，幾秒鐘，幾分鐘之后查出來，對(duì)用戶來說這種要求是不可接受的。我們作為在線數(shù)據(jù)必須滿足高效的響應(yīng)。在HBase替掉之前的解決方案選擇了MySQL數(shù)據(jù)方案，需要非常多的人為分庫分表。分庫過程中銷量磁盤的IO、網(wǎng)絡(luò)各方面的硬件的資源，這對(duì)于在線數(shù)據(jù)訪問來說就是一種沖擊，資源的消耗必然會(huì)延時(shí)用戶正常需求。那么不是很適合我們當(dāng)前的所需要的分布式數(shù)據(jù)庫。第二個(gè)特點(diǎn)，我們HBase當(dāng)前的水平拓展能力非常強(qiáng)，HBase底層以來是Hadoop，Hadoop現(xiàn)行拓展能力大家很清楚，很多人在這方面鉆研很久，使用很長(zhǎng)時(shí)間，現(xiàn)行拓展能力反映在HBase這一層，HBase上層不作為數(shù)據(jù)存儲(chǔ)，底層依賴HDFS，作為數(shù)據(jù)存儲(chǔ)現(xiàn)行拓展。而且HBase當(dāng)前在建表過程當(dāng)中支持預(yù)先分區(qū)分表，可以提前玻璃做好一些負(fù)載均衡的事情，HBase現(xiàn)行拓展能力強(qiáng)，吞吐率也非常好。最重要一點(diǎn)，按照時(shí)間的排序，這種排序基于了HBase的特性，我們?cè)诓樵冞^程當(dāng)中掃描一段數(shù)據(jù)，經(jīng)過排序的連續(xù)數(shù)據(jù)。我們應(yīng)用了HBase之后，我們這邊的數(shù)據(jù)量增長(zhǎng)大概是已經(jīng)成長(zhǎng)到了5萬個(gè)Region。我們Rowkey設(shè)計(jì)，滿足它的用戶需求是字典排序，只查自己的數(shù)據(jù)，Userdi0開頭，交易類型再補(bǔ)為0，第二個(gè)交易時(shí)間最后是交易號(hào)，我們選擇基于最基礎(chǔ)版本HBase0.9、0.1，中間打破了非常多的重要的，我們也碰到其他問題，今天重點(diǎn)只介紹在故障這塊的問題，沒有經(jīng)過優(yōu)化之前，HBase每次響應(yīng)達(dá)到秒級(jí)，經(jīng)過優(yōu)化之后，他們每次請(qǐng)求響應(yīng)在20毫秒，我們正常用戶都可以接受的實(shí)時(shí)請(qǐng)求。剛才大綱當(dāng)中提到了RegionServer在恢復(fù)過程當(dāng)中有幾個(gè)流程。這個(gè)流程很復(fù)雜，流程非常非常多，以當(dāng)前的系統(tǒng)規(guī)模，它凸顯出來的問題，這幾個(gè)流程是影響到它的恢復(fù)速度的關(guān)鍵流程。等待時(shí)間周期非常長(zhǎng)，為什么說周期比較長(zhǎng)，原因因?yàn)槲覀儸F(xiàn)在的機(jī)器發(fā)展速度非常得快，每臺(tái)機(jī)器從兩個(gè)G到8個(gè)G，96G，140多G的大層次的機(jī)器，Java語言實(shí)現(xiàn)了系統(tǒng)當(dāng)中大內(nèi)存管理本身存在問題，除非革新這門語言，否則別無他求。如果說我們?cè)谠O(shè)計(jì)的參數(shù)不合理，可能會(huì)導(dǎo)致一個(gè)問題，我們有可能會(huì)發(fā)生這臺(tái)服務(wù)器停止，發(fā)生這么一次情況就非常可，幾十G的內(nèi)存這個(gè)過程需要幾十秒甚至上分鐘，通常情況下，我們會(huì)設(shè)置到3分鐘，意味著，我們?yōu)榱吮苊獬霈F(xiàn)這種問題，同時(shí)引入新的問題，我們宕機(jī)之后恢復(fù)等待時(shí)間需要三分鐘。第二個(gè)關(guān)鍵流程當(dāng)中，當(dāng)它感知到已經(jīng)掛掉了，在線數(shù)據(jù)庫協(xié)助WL數(shù)據(jù)重新做到存儲(chǔ)當(dāng)中去，以保證實(shí)時(shí)更新是同步，否則這個(gè)數(shù)據(jù)庫肯定要丟出去，重做數(shù)據(jù)過程當(dāng)中，會(huì)有一個(gè)過程，SplitHlog，跟當(dāng)前數(shù)據(jù)量有關(guān)系，EditLog數(shù)據(jù)又比較多，大家在業(yè)余時(shí)間可以進(jìn)行測(cè)試，數(shù)據(jù)不以我們?yōu)闇?zhǔn)，以當(dāng)前數(shù)據(jù)系統(tǒng)大小為準(zhǔn)。第三個(gè)關(guān)鍵流程，重做完數(shù)據(jù)之后，這部分重新上線，上線之前進(jìn)行數(shù)據(jù)進(jìn)行二次掃描，告訴系統(tǒng)說，我的Region怎么加入到RegionServer當(dāng)中去，掃描也存在問題，問題可能引發(fā)到兩分鐘到6分鐘這也跟當(dāng)前系統(tǒng)數(shù)據(jù)有關(guān)。第四部分這個(gè)過程稱之為再次上線的過程，這個(gè)再次上線，上線時(shí)間跟當(dāng)前這臺(tái)機(jī)器的Region上線有關(guān)系。我們支付寶面對(duì)消費(fèi)記錄查詢，用戶查不出來數(shù)據(jù)，15分鐘之后才能查到，這是非常可怕的面臨在線的事情。針對(duì)我們?cè)赗egionServer這一層關(guān)鍵流程當(dāng)中，我們做了一些優(yōu)化。這個(gè)優(yōu)化正是提到關(guān)鍵流程第一點(diǎn)，在判斷宕機(jī)超市的情況下，不強(qiáng)依賴于Zookeeper，我們又啟動(dòng)了監(jiān)控進(jìn)程，叫MirrorProcess，每一臺(tái)，RegionServer當(dāng)中都會(huì)起到UPID存不存在，這種檢查并非完全可靠，當(dāng)檢查PID不存在，我們有理由認(rèn)為已經(jīng)掛掉了，要進(jìn)行可靠檢查，通常DBA在線判斷數(shù)據(jù)庫是否可用，通常會(huì)用PIng連續(xù)服務(wù)端口，這就彌補(bǔ)了系動(dòng)中的調(diào)用命令不可靠的事情。最后當(dāng)我們發(fā)現(xiàn)服務(wù)端口不可用，有理由認(rèn)為當(dāng)前進(jìn)程已經(jīng)死掉了，死掉了之后，我們按照現(xiàn)有邏輯刪除結(jié)點(diǎn)，這三分鐘的時(shí)間就完全省略掉。這是我們?cè)趦?yōu)化ZK宕機(jī)啟動(dòng)流程。首先，RegionServer會(huì)啟動(dòng)自身自己服務(wù)，會(huì)向ZK注冊(cè)，注冊(cè)自己專有結(jié)點(diǎn)，監(jiān)控自己的進(jìn)程如果是就會(huì)發(fā)PID，如果不是就會(huì)直接進(jìn)入下一步。優(yōu)化強(qiáng)依賴Zookeeper的宕機(jī)超時(shí)判斷監(jiān)控進(jìn)程的啟動(dòng)流程，我發(fā)現(xiàn)當(dāng)前我的RegionServer已經(jīng)啟動(dòng)了，我會(huì)主動(dòng)向我的RegionServer拉動(dòng)它，保證了PD的唯一性。為什么不采用在系統(tǒng)級(jí)的PS一下，檢查一它的進(jìn)行字符匹配，其實(shí)我們認(rèn)為這不是很可靠，假如說程序當(dāng)中判斷失誤，我們有可能會(huì)檢查到原本不屬于進(jìn)程該檢查，會(huì)造成監(jiān)控的失誤，誤刪除的現(xiàn)象存在，我們啟動(dòng)了自己認(rèn)為可靠的程序進(jìn)行監(jiān)控。同時(shí)我們認(rèn)為除了自己本機(jī)RegionServer會(huì)宕掉之后，還存在這臺(tái)機(jī)器完全宕機(jī)的風(fēng)險(xiǎn)，完全宕機(jī)如果RegionServer所在的機(jī)器，所啟動(dòng)的監(jiān)控進(jìn)程它只監(jiān)控自己當(dāng)前的RegionServer，就會(huì)面臨這樣一個(gè)問題，如果整臺(tái)機(jī)器全部管掉了，我們監(jiān)控其實(shí)失效了，肯定還是要回到原來的起點(diǎn)當(dāng)中等待ZK的超市，除了本機(jī)監(jiān)控之外還應(yīng)該依賴于其他當(dāng)中相互覆蓋的監(jiān)控方式，比如說，相鄰兩個(gè)結(jié)點(diǎn)，除了只監(jiān)控自己本機(jī)PID是否存在和自己端口是否存在，我還可以檢查進(jìn)程相鄰第二臺(tái)機(jī)器B的服務(wù)端口是否存在，這就做到了看似非常復(fù)雜的網(wǎng)絡(luò)結(jié)構(gòu)的完整監(jiān)控模式。目前，我們將思路已經(jīng)提了專利，我們也提到了社區(qū)，我們跟社區(qū)的思路不是特別一樣社區(qū)有另外考慮，在5075社區(qū)考慮是否用Java的方式來做，大同小異，跟我們做的優(yōu)化目的是一樣，總之為了減少等待時(shí)間。我們當(dāng)前解決方案只能說檢查當(dāng)前機(jī)器的服務(wù)是否存在，不能檢查我們當(dāng)前機(jī)器它RegionServer內(nèi)部的問題，比方說這臺(tái)機(jī)器當(dāng)中發(fā)生的異常狀況，死鎖，這是內(nèi)核的問題，RegionServer更內(nèi)層的東西進(jìn)行加以優(yōu)化和修訂。所以說我們也是有利有弊的過程，不是完全像第二種說到的情況。關(guān)于RegionServer宕機(jī)恢復(fù)第二流程，就是重做HLog的時(shí)間，0.9X系列目前單線程，如果設(shè)置256兆，如果寫讀量非常大，周期上線是32Hlog，這32和250乘起來，Java處理速度，能有50到每秒不錯(cuò)了，實(shí)際上達(dá)不到這種速度，在現(xiàn)有機(jī)械盤當(dāng)中緩沖區(qū)和內(nèi)存交互速度是30兆每秒，可以算一下256乘以32除以30，很可觀的數(shù)字，得到了現(xiàn)有系統(tǒng)當(dāng)中業(yè)務(wù)量重做Hlog的時(shí)間，串行處理必然降低了速度，在社區(qū)的0.92意識(shí)到這個(gè)問題，Hlog分發(fā)到每臺(tái)RegionServer都會(huì)寫入最終數(shù)據(jù)塊的服務(wù)區(qū)當(dāng)中，這樣的話，利用了每個(gè)臺(tái)機(jī)器服務(wù)能力，我們每臺(tái)機(jī)器只做一個(gè)Hlog的恢復(fù)，256除以30，速度可以看到得到質(zhì)的提升，就是并行的方案。有一定請(qǐng)各位注意，0.92并行Hlog可能出現(xiàn)丟數(shù)據(jù)的現(xiàn)象，0.94代碼并行做過一些修復(fù)，我們初期用了1364版本，但是在0.94系列里面做過同步的代碼，保證至少測(cè)試當(dāng)中都是能過的，目前應(yīng)用系統(tǒng)當(dāng)中還沒有發(fā)現(xiàn)丟數(shù)據(jù)的現(xiàn)象。還有一個(gè)問題掃描原數(shù)據(jù)的問題，如果Rewion越多數(shù)據(jù)肯定是越多的，現(xiàn)有問題也存在一系列的問題，RPC的問題，特定場(chǎng)景才會(huì)發(fā)現(xiàn)的，如果發(fā)生這個(gè)問題，可能延遲幾分鐘時(shí)間，如果沒有這個(gè)問題，這部分所帶來的消耗也并不是太長(zhǎng)，主要會(huì)集中在第二步當(dāng)中，第一步肯定要加以防范，這個(gè)參數(shù)其實(shí)非常簡(jiǎn)單。第二步也是參數(shù)上的優(yōu)化，大家可以實(shí)驗(yàn)。我們宕機(jī)服務(wù)Region恢復(fù)的優(yōu)化，我們解決方案采用并行方式，優(yōu)于單線程串行的時(shí)間，直接使用了HBase初期啟動(dòng)，速度上大大提升，這是我們最終的效果圖。這個(gè)效果圖在第一個(gè)階段當(dāng)中我們將縮短零秒并行10秒左右其實(shí)15分鐘到20分鐘的優(yōu)化上線的時(shí)間。這是我們效果最終對(duì)比，時(shí)間可以看得出來，優(yōu)化后比優(yōu)化前速度有質(zhì)的提升，單位是一千到900，這個(gè)是秒。最重要的一點(diǎn)，我們?cè)贖DFS做了HA的優(yōu)化，現(xiàn)在社區(qū)提出非常多的HA方案，他們都是作為為了解決HDFS單點(diǎn)問題所存在的，現(xiàn)在方案寫到本地文件系統(tǒng)和其他東西當(dāng)中，目前所做的工作至今是尚不成熟的，這部分有的是功能上滿足不了。我們?cè)谛碌纳鐓^(qū)代碼當(dāng)中發(fā)現(xiàn)了，保證在發(fā)現(xiàn)機(jī)器宕機(jī)之后像Node的關(guān)系，我們來源于社區(qū)還會(huì)還自于社區(qū)，依賴于社區(qū)已有的解決方案，我們加以做了整合和自己的二次研發(fā)。我們所做的目標(biāo)得到都是清楚的，首先是自動(dòng)熱切目標(biāo)就是HBase的不定期服務(wù)，我們整盤架構(gòu)圖，我們NameNode之間的優(yōu)化，處理邏輯不一樣，我們利用分布式的方式加一個(gè)Node，如果想當(dāng)前狀態(tài)沒有切過去，就會(huì)向客戶端拋出異常，我是這樣的狀態(tài)你不可以操作，保證了兩臺(tái)機(jī)器數(shù)據(jù)不會(huì)被干擾的。另外一點(diǎn)，NameNode關(guān)系是怎么樣的，同時(shí)會(huì)顯數(shù)據(jù)，寫的過程當(dāng)中除了這個(gè)數(shù)據(jù)結(jié)構(gòu)之外還有另一個(gè)結(jié)構(gòu)，刪除了哪些文件，主要操作NameNode上來進(jìn)行。監(jiān)控的環(huán)節(jié)作為在線系統(tǒng)和離線系統(tǒng)是非常重要的環(huán)節(jié)。如果沒有監(jiān)控監(jiān)控相當(dāng)于是雷達(dá)，只有有了雷達(dá)才可以發(fā)現(xiàn)當(dāng)前系統(tǒng)當(dāng)中有什么問題做診斷，對(duì)它判斷當(dāng)前是否負(fù)載過重等現(xiàn)象的存在這樣才有線上的運(yùn)維，對(duì)癥下藥否則系統(tǒng)像無頭蒼蠅一樣沒法做工作正常安排。我們看到當(dāng)前讀寫比例有多少，我們寫了DPS的展現(xiàn)