男女一起相嗟嗟免费观看在学校,私密按摩师电影,国产香蕉片

海量吞吐的實(shí)時(shí)NoSQL：HBase的七劍和雙11圣戰(zhàn)(數(shù)據(jù)脫敏版)?

去年淘寶雙11，作為媒體大屏(dataV)、消費(fèi)記錄、支付寶風(fēng)控、物流詳情、庫(kù)存對(duì)賬核心數(shù)據(jù)庫(kù)的集團(tuán)HBase，當(dāng)天穩(wěn)定運(yùn)行，順利完成了任務(wù)。并交出了非常漂亮的幾項(xiàng)數(shù)據(jù)：QPS=1993W，TPS=3656W，讀流量=56GBps，寫流量=40.6GBps，全天吞吐讀2.0PB，寫1.28PB。

由于HBase團(tuán)隊(duì)的組織架構(gòu)變動(dòng)，使得去年雙11的備戰(zhàn)重責(zé)落在了幾桿稚嫩的小槍身上了，不是雙11運(yùn)維、開發(fā)新人就是應(yīng)屆畢業(yè)生。備戰(zhàn)過(guò)程的『點(diǎn)』，若從DB集群老核心業(yè)務(wù)整合開始算起，戰(zhàn)役從去年5月就打響了第一槍。備戰(zhàn)過(guò)程的『面』，涉及支付寶、安全部、菜鳥、天貓、淘寶技術(shù)部、共享業(yè)務(wù)事業(yè)部、航旅、阿里云等幾乎所有BU。在此我想從HBase系統(tǒng)層面和業(yè)務(wù)層面兩個(gè)大方向談?wù)務(wù)麄€(gè)備戰(zhàn)過(guò)程，進(jìn)行一次較為全面的總結(jié)。

系統(tǒng)層面，經(jīng)歷了從3u5.5至3u7.5.1的發(fā)展，磨礪出了七劍，為HBase系統(tǒng)的性能、穩(wěn)定性、高可用、單元化保駕護(hù)航。所謂開發(fā)團(tuán)隊(duì)制造彈藥，PE團(tuán)隊(duì)落地優(yōu)化。有了這些利劍和神兵，我們才能披荊斬棘所向披靡。

ExploringCompaction成為默認(rèn)選舉算法

Replication的優(yōu)化

單元化及Diamond整合

MTTR1期

限制大scan請(qǐng)求的資源使用

混合存儲(chǔ)

基于虛擬節(jié)點(diǎn)的跨ZK集群切庫(kù)

HBase的七劍

>>>>

七劍之莫問(wèn)：

ExploringCompaction成為默認(rèn)選舉算法

HBase本身有非常多的業(yè)務(wù)是以BulkLoad的方式進(jìn)行離線數(shù)據(jù)寫入的，對(duì)應(yīng)的在云端插件為HBaseBulkWriter，優(yōu)點(diǎn)為對(duì)線上影響小（不占用服務(wù)端線程池），代價(jià)為丟失本地化率及帶來(lái)部分IO毛刺。3u5.5之前的版本采用的默認(rèn)文件選擇策略，在BulkLoad的場(chǎng)景下存在缺陷，會(huì)導(dǎo)致compaction積壓（IO不能有效地去做文件合并），文件數(shù)無(wú)法控制，影響在線實(shí)時(shí)讀性能。3u5.5徹底完成了社區(qū)的Exploring選舉算法的引入，極大優(yōu)化了該場(chǎng)景甚至是泛化場(chǎng)景下的文件compaction。

HBase是采用LSM樹作為存儲(chǔ)引擎的，compaction的目的是減少文件數(shù)和刪除無(wú)用的數(shù)據(jù)，優(yōu)化讀性能，準(zhǔn)則是用最小的IO代價(jià)去減少最多的文件數(shù)。Compaction有2個(gè)原則：

所有StoreFile按照順序進(jìn)行排列（此順序?yàn)椋豪衔募谇埃挛募诤蟆ulkLoad進(jìn)來(lái)的文件總是排在HBase內(nèi)部生成的文件之前。詳細(xì)的順序排列參考Store#sortAndClone）；

參與compaction的文件必須是連續(xù)的。

先來(lái)看看默認(rèn)的選舉算法RatioBasedCompaction：

從Storefile列表中，從老到新（即隊(duì)列中從頭到尾），挑選起始的那個(gè)StoreFile，挑選的依據(jù)是：文件大小不能超過(guò)配置中的max size（默認(rèn)2GB），并且文件大小不能超過(guò)后面文件的大小sum*ratio（默認(rèn)為1.2倍）；

決定終止的StoreFile，一般就是列表中的最后一個(gè)文件，但是要求參與compaction的文件數(shù)不能超過(guò)配置的max files數(shù)目，默認(rèn)為10個(gè)，如果超過(guò)10個(gè)了，那么終止的StoreFile為起始位置+max files ；

BulkLoad的場(chǎng)景下，會(huì)產(chǎn)生很多小文件。舉個(gè)例子，典型的會(huì)有如下的file list（ratio=1）：300MB(BulkLoad), 5MB(BulkLoad), 1GB, 23MB, 12MB, 12MB。那么默認(rèn)的ratio算法會(huì)選擇：5MB, 1GB, 23MB, 12MB, 12MB，這樣我們的IO代價(jià)大，收效甚微（打開5個(gè)文件句柄，讀1076MB，寫1076MB，減少4個(gè)文件）。其實(shí)這樣的情況下，我們最想要得到的是： 23MB, 12MB, 12 MB。因?yàn)檫@樣是以最小的IO代價(jià)（打開4個(gè)句柄，讀47MB、寫47MB），減少2個(gè)文件。再舉個(gè)例子，flie list為：20MB(BulkLoad), 20MB(BulkLoad), 1GB, 4MB, 3MB, 2MB, 1MB，默認(rèn)算法會(huì)選擇：20MB, 20MB, 1GB, 4MB, 3MB, 2MB, 1MB，打開8個(gè)句柄，讀1074MB、寫1074MB，減少6個(gè)文件；但是我們想要的選擇是： 4MB, 3MB, 2MB, 1MB，打開5個(gè)句柄，讀10MB、寫10MB，減少3個(gè)文件。

因此ExploringCompaction算法就非常適合我們，檢查Storefile列表的每一個(gè)子隊(duì)列，從中找出一個(gè)最優(yōu)子隊(duì)列，參與compaction：

隊(duì)列中的每一個(gè)文件符合ratio準(zhǔn)則；

1條件下?lián)碛懈嗟奈募?shù)目；

1, 2 條件下?lián)碛懈〉奈募笮　?/p>

相較于默認(rèn)的算法，Exploring更為『智能』，是七劍中的莫問(wèn)。

>>>>

七劍之游龍：Replication的優(yōu)化

Replication是HBase實(shí)現(xiàn)集群內(nèi)部同步的重要組件，是業(yè)務(wù)高可用、單元化的基礎(chǔ)，2015年我們主要在優(yōu)化同步積壓和積壓影響組級(jí)別隔離兩方面做了努力。

主線程shipEdits多線程化。Alimonitor是雙11需要P1級(jí)別保障的業(yè)務(wù)，它的歷史監(jiān)控繪圖數(shù)據(jù)存儲(chǔ)在HBase，日常是有主備實(shí)時(shí)同步進(jìn)行高可用保障的，主庫(kù)主要有宕機(jī)或者1分鐘以上的抖動(dòng)，就會(huì)立刻執(zhí)行切庫(kù)，保障系統(tǒng)的穩(wěn)定。但是2015年年初，有一個(gè)問(wèn)題困擾我們，就是alimonitor因?yàn)闃I(yè)務(wù)特性，存在和時(shí)間序列相關(guān)的持續(xù)熱點(diǎn)，這個(gè)熱點(diǎn)也不是很熱，大約就是其他節(jié)點(diǎn)的+10%。主備庫(kù)同步經(jīng)常積壓，造成即使可以切庫(kù)，也會(huì)有大量監(jiān)控繪圖有斷圖的現(xiàn)象。于是我們對(duì)Replication進(jìn)行了改造，用多線程的方式，將這些數(shù)據(jù)推送（shipEdits）到備集群的多臺(tái)regionserver。即shipEdits動(dòng)作，由單線程改為多線程，而hlog的read動(dòng)作，仍然保持單線程。受益的業(yè)務(wù)不僅包括Alimonitor，也涉及到依賴中美同步的廣大AE和ICBU的同胞們、以及所有單元化、高可用架構(gòu)用戶。似七劍游龍，攻勢(shì)兇猛，分分鐘消化同步積壓，為主備庫(kù)高可用保駕護(hù)航。

積壓影響組級(jí)別隔離。HBase早在2013年就開始了大集群運(yùn)維策略，一個(gè)業(yè)務(wù)或一個(gè)BU的業(yè)務(wù)隔離出一個(gè)分組，底層HDFS可以共享IO，并且可以容易地進(jìn)行資源調(diào)度。引入了Replication后有一個(gè)問(wèn)題，就是GroupA的同步產(chǎn)生了積壓，會(huì)導(dǎo)致備庫(kù)所有業(yè)務(wù)的同步數(shù)據(jù)積壓。因此，我們對(duì)其進(jìn)行了改造，在選擇備庫(kù)代理發(fā)出put請(qǐng)求的服務(wù)器時(shí)，指定在和主庫(kù)group name一致分組下的機(jī)器中進(jìn)行選擇。這樣即使GroupA的同步積壓，也不會(huì)波及其他『無(wú)辜』的業(yè)務(wù)分組了。

>>>>

七劍之天瀑：單元化及diamond整合

異地多活、單元化等關(guān)鍵詞充斥著2015上半年，HBase也有部分業(yè)務(wù)涉及單元化的一中心、多單元的部署架構(gòu)需求。3u7版本前的HBase只支持主主(Peer To Peer)同步備份，無(wú)法支持單元化。

實(shí)現(xiàn)單元化過(guò)程中的主要通過(guò)數(shù)據(jù)打標(biāo)的辦法解決了數(shù)據(jù)環(huán)路問(wèn)題，并且開發(fā)出了一套可視化的運(yùn)維控制臺(tái)。Replication的單元化功能上線后，可以支持如下圖的復(fù)雜部署，滿足單元化的需求：

并且，用戶可以選擇使用diamond的方式訪問(wèn)HBase集群，利用diamond進(jìn)行數(shù)據(jù)源地址推送，和單元化分流。多Peer+diamond使得HBase似七劍天瀑，轉(zhuǎn)易顛倒，意到隨成，數(shù)據(jù)做到真正的任意流轉(zhuǎn)，業(yè)務(wù)做到真正的異地多活。

>>>>

七劍之青干：MTTR一期

對(duì)于分布式數(shù)據(jù)庫(kù)，單個(gè)節(jié)點(diǎn)宕機(jī)（服務(wù)宕機(jī)、物理宕機(jī)）是一個(gè)可能會(huì)發(fā)生的常態(tài)。3u7版本前的HBase只要跪一臺(tái)regionserver，就會(huì)引起業(yè)務(wù)抖動(dòng)近18分鐘。MTTR優(yōu)化一期，主要關(guān)注的是單臺(tái)RS宕機(jī)后的恢復(fù)過(guò)程優(yōu)化和改進(jìn)。單臺(tái)regionserver宕機(jī)的failover過(guò)程可以參看：http://blog.csdn.net/hljlzc2007/article/details/10963425。拿集團(tuán)TT這樣體量的業(yè)務(wù)來(lái)說(shuō)，MTTR一期優(yōu)化后，單臺(tái)物理宕機(jī)恢復(fù)時(shí)間縮短至了7分鐘。整個(gè)MTTR似七劍青干，象征“防守&迅捷”，快速恢復(fù)。其中，我們主要做了以下四項(xiàng)優(yōu)化（數(shù)據(jù)只是測(cè)試數(shù)據(jù)）：

場(chǎng)景改進(jìn)前改進(jìn)后

split-log過(guò)程中過(guò)濾已flush的entry耗時(shí)18 min耗時(shí)5 min

普通RS和服務(wù)Meta的RS先后宕機(jī)，優(yōu)先恢復(fù)Meta Region耗時(shí)4 min耗時(shí)35 sec

recoverLease機(jī)制優(yōu)化由worker進(jìn)行l(wèi)ease recover由master進(jìn)行l(wèi)ease recover

避免HDFS故障導(dǎo)致的RS宕機(jī)HDFS故障后1分鐘內(nèi)RS abortHDFS故障后RS不abort，且可繼續(xù)提供不涉及HDFS操作的讀寫服務(wù)

Split hlog時(shí)過(guò)濾過(guò)時(shí)的edits/entry

該優(yōu)化點(diǎn)主要是在split-log過(guò)程中生成recovered.edits時(shí)skip掉已經(jīng)flush的entry，從而加速整個(gè)split過(guò)程。線上環(huán)境通常配置HBase.regionserver.maxlogs為96，也就是說(shuō)hlog總大小為96*256MB，而Memstore總大小通常不超過(guò)10GB，從這個(gè)角度看該特性應(yīng)該可以在split-log時(shí)過(guò)濾掉一半以上數(shù)據(jù)。

宕機(jī)時(shí)優(yōu)先恢復(fù)Meta region

該優(yōu)化點(diǎn)針對(duì)的情況是當(dāng)有兩臺(tái)RS先后宕機(jī)，后宕機(jī)的RS上服務(wù)meta region且宕機(jī)前存在建表/刪表操作的情況下，加速meta region上線速度。優(yōu)化后，我們會(huì)在每次處理掉一個(gè)split log task之后動(dòng)態(tài)獲取任務(wù)列表（之前是靜態(tài)），并且優(yōu)先處理meta region的相關(guān)的task。

recoverLease機(jī)制優(yōu)化

該優(yōu)化點(diǎn)主要針對(duì)split-log產(chǎn)生大量recovered.edits文件導(dǎo)致HDFS性能緩慢情況下recoverLease長(zhǎng)期無(wú)法完成拖慢整體log split速度的問(wèn)題，改進(jìn)split-log過(guò)程中recoverLease的機(jī)制，加速failover。

HDFS故障導(dǎo)致的RS宕機(jī)

3u7之前，當(dāng)HDFS出現(xiàn)問(wèn)題時(shí)（例如網(wǎng)絡(luò)問(wèn)題，進(jìn)入safemode，或者整個(gè)hdfs集群宕機(jī)等），RegionServer會(huì)很快檢測(cè)到（flush/hlog_roll都會(huì)觸發(fā)對(duì)filesystem的檢查）并abort，這樣帶來(lái)的最大問(wèn)題是HDFS恢復(fù)后會(huì)有大量的split-log發(fā)生，導(dǎo)致非常長(zhǎng)的恢復(fù)時(shí)間。實(shí)際上，當(dāng)HDFS出現(xiàn)問(wèn)題時(shí)，可以捕捉相關(guān)異常，并死等HDFS恢復(fù)，在此期間讀寫仍可進(jìn)行直至觸發(fā)HDFS操作。同時(shí)由于不觸發(fā)server abort，不會(huì)導(dǎo)致split-log，因此可大大縮短恢復(fù)時(shí)間。實(shí)測(cè)效果顯示，HDFS故障1小時(shí)后恢復(fù)仍然可以保證HBase恢復(fù)并保證數(shù)據(jù)一致性，這大大降低了HDFS故障的影響，并在最差情況下可以通過(guò)重啟HDFS來(lái)解決故障，而不用擔(dān)心split-log及恢復(fù)時(shí)間過(guò)長(zhǎng)的問(wèn)題。

>>>>

七劍之舍神：

限制大scan請(qǐng)求的資源使用

2015年，支付寶消費(fèi)記錄去了MySQL，把所有實(shí)時(shí)查詢都搬上了HBase，是歷史以來(lái)責(zé)任最重的雙11，試想當(dāng)你們支付寶支付完成之后，看不到消費(fèi)轉(zhuǎn)賬記錄是何等的心情。但是，在年初的時(shí)候，消費(fèi)記錄的HBase集群，會(huì)經(jīng)常遇到單臺(tái)regionserver handler（線程池）打爆，LOAD飆高至不可接受導(dǎo)致服務(wù)宕機(jī)的問(wèn)題。消費(fèi)記錄是一個(gè)從MYSQL遷移過(guò)來(lái)的應(yīng)用，查詢場(chǎng)景包含了大量scan+filter，并且skip的kv異常多，查詢范圍廣。但凡有跨N多datablock的查詢，服務(wù)端總會(huì)把資源消耗在這種大查詢之上，導(dǎo)致阻塞后續(xù)的查詢。大請(qǐng)求(bigcall)的定義：對(duì)系統(tǒng)資源消耗特別大的請(qǐng)求，典型的例子就是帶有filter的scan，這個(gè)filter過(guò)濾掉了大量的數(shù)據(jù)，導(dǎo)致一個(gè)next操作會(huì)訪問(wèn)成百上千個(gè)block。當(dāng)block大部分都在內(nèi)存時(shí)，這種scan就會(huì)消耗大量資源。當(dāng)多個(gè)大請(qǐng)求并發(fā)訪問(wèn)服務(wù)器時(shí)，會(huì)造成load飆高，吞吐量下降。在實(shí)際的問(wèn)題中，大請(qǐng)求可能幾個(gè)小時(shí)都執(zhí)行不完。

因此我們針對(duì)性的對(duì)bigcall進(jìn)行了截流，實(shí)現(xiàn)了BigCallThrottle。限制大請(qǐng)求的資源消耗，讓正常的請(qǐng)求可以獲取資源。通過(guò)sleep達(dá)到目的。中斷掉對(duì)客戶端來(lái)說(shuō)已經(jīng)超時(shí)的請(qǐng)求，這種請(qǐng)求繼續(xù)運(yùn)行沒有意義。中斷請(qǐng)求釋放資源。優(yōu)化似七劍舍神，使得服務(wù)端具有強(qiáng)烈的生命力。經(jīng)過(guò)優(yōu)化，消費(fèi)記錄在之后的歷次大促和雙11中，系統(tǒng)非常穩(wěn)定，沒有出現(xiàn)過(guò)因大請(qǐng)求導(dǎo)致的服務(wù)宕機(jī)，業(yè)務(wù)抖動(dòng)。

>>>>

七劍之日月：混合存儲(chǔ)

混合存儲(chǔ)是2015年強(qiáng)推的一個(gè)大優(yōu)化，似七劍日月，是最耀眼的優(yōu)化。隨著集團(tuán)HBase承接業(yè)務(wù)范圍的擴(kuò)大，越來(lái)越多實(shí)時(shí)性要求高(99.9% 200ms內(nèi))、數(shù)據(jù)海量(往往超過(guò)幾十TB)的業(yè)務(wù)在硬件選擇上遇到了難題：

選擇SATA？高毛刺高RT，低下的IOPS能力，肯定不行。

選擇SSD？高昂的資源開銷，這個(gè)也承受不住，并且存儲(chǔ)空間也還是問(wèn)題。

選擇混合存儲(chǔ)機(jī)型的SSD做二級(jí)緩存？不同的業(yè)務(wù)具有不同的命中率，無(wú)法提升命中率則一旦抖到SATA盤上還是然并卵。我們是要做一種通用的解決方案，這也不行。

在尋求硬件開銷&性能&存儲(chǔ)空間的tradeoff中，我們想到了真正的混合存儲(chǔ)：12個(gè)硬盤slot中有3個(gè)是SSD，其余9個(gè)是SATA。數(shù)據(jù)寫入的時(shí)候，可以指定寫入1份SSD還是3份，抑或不寫，讀取的時(shí)候可以選擇是否優(yōu)先走SSD讀。這個(gè)功能一上線，太多太多的業(yè)務(wù)都爭(zhēng)先恐后上去，目前集團(tuán)+支付寶已經(jīng)有30%的機(jī)器被替換成了混合存儲(chǔ)，在預(yù)算持平的情況下，讀RT從99% 200ms優(yōu)化至99.9% 200ms，用戶體驗(yàn)上升。

>>>>

七劍之競(jìng)星：

基于虛擬節(jié)點(diǎn)的跨ZK集群切庫(kù)

3u7.1之前的HBase客戶端只能進(jìn)行同ZK集群下基于虛擬節(jié)點(diǎn)的切庫(kù)。但是有幾個(gè)問(wèn)題需要解決：

老集群業(yè)務(wù)平滑遷移，即使客戶端改造為虛擬節(jié)點(diǎn)的方式連接ZK，仍不能保證過(guò)程透明；

單元沒有提供2:2:1部署ZK集群條件的，必須進(jìn)行跨ZK集群多單元部署的情況；

基于diamond的高可用架構(gòu)下，但凡diamond本身無(wú)法保障高可用的情況。

基于以上三種場(chǎng)景，我們需要基于虛擬節(jié)點(diǎn)的跨ZK集群切庫(kù)這一功能。這在正如衣服內(nèi)短小的競(jìng)星劍，非必要時(shí)刻不出手，出手時(shí)迅雷不及掩耳。

經(jīng)平臺(tái)同意授權(quán)轉(zhuǎn)載

來(lái)源：云棲社區(qū)

作者：中間件那珂

近期熱文（點(diǎn)擊標(biāo)題可閱讀全文）