那些分布式系統(tǒng)設(shè)計常用的開源模塊
HBase開發(fā):
HBase
HBase介紹
HBase - Hadoop Base 是一個高可靠、高性能的、面向列、可伸縮的分布式系統(tǒng)、利用HBase技術(shù)可在廉價PC Server上搭建大規(guī)模結(jié)構(gòu)化存儲集群。HBase是Google Bigtable的 java開源實現(xiàn)，類似Google Bigtable利用GFS作為其文件存儲系統(tǒng)，HBase利用Hadoop HDFS作為其文件存儲系統(tǒng)，Google運行MapReduce來處理Bigtable中的海量數(shù)據(jù)，HBase同樣利用Hadoop MapReduce來處理HBase中的海量數(shù)據(jù)，Google Bigtable利用Chubby作為協(xié)同服務，HBase利用Zookeeper作為協(xié)同服務。
HBase使用
適用場景
HBase的這些特點適用于數(shù)據(jù)海量、持續(xù)增長的情況，例如開源監(jiān)控平臺OpenTSDB;網(wǎng)易的logtracer數(shù)據(jù)存儲、監(jiān)控平臺的數(shù)據(jù)存儲;淘寶的交易歷史記錄查詢系統(tǒng)，淘寶指數(shù)等。
Facebook公司整理HBase集群使用的場景如下：
- 需要很高的寫吞吐量
- 在大規(guī)模數(shù)據(jù)集中進行隨機訪問
- 方便的水平擴展
- 結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)
- 不需要全部的關(guān)系數(shù)據(jù)庫特性，例如交叉列、交叉表，事務，連接等等
HBase表的設(shè)計
HBase的表包含如下屬性：
(1)最大版本數(shù)：通常是3，如果對于更新比較頻繁的應用完全可以設(shè)置為1，能夠快速的淘汰無用數(shù)據(jù)，對于節(jié)省存儲空間和提高查詢速度有效果。
(2)壓縮算法：可以嘗試一下最新出爐的snappy算法，相對lzo來說，壓縮率接近，壓縮效率稍高，解壓效率高很多。
(3)inmemory：表在內(nèi)存中存放，一直會被忽略的屬性。如果完全將數(shù)據(jù)存放在內(nèi)存中，那么hbase和現(xiàn)在流行的內(nèi)存數(shù)據(jù)庫memorycached和redis性能差距有多少，尚待實測。
(4)bloomfilter：根據(jù)應用來定，看需要精確到rowkey還是column。不過這里需要理解一下原理，bloomfilter的作用是對一個region下查找記錄所在的hfile有用。即如果一個region下的hfile數(shù)量很多，bloomfilter的作用越明顯。適合那種 compaction趕不上flush速度的應用。
默認情況下，在創(chuàng)建HBase表的時候會自動創(chuàng)建一個region分區(qū)，當導入數(shù)據(jù)的時候，所有的HBase客戶端都向這一個region寫數(shù)據(jù)， 直到這個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先創(chuàng)建一些空的regions，這樣當數(shù)據(jù)寫入HBase時，會按照 region分區(qū)情況，在集群內(nèi)做數(shù)據(jù)的負載均衡。
有關(guān)預分區(qū)，詳情參見：Table Creation: Pre-Creating Regions。
HBase的RowKey設(shè)計
rowkey是hbase的key-value存儲中的key，通常使用用戶要查詢的字段作為rowkey，查詢結(jié)果作為value。可以通過設(shè)計滿足幾種不同的查詢需求。
數(shù)字rowkey的從大到小排序：原生hbase只支持從小到大的排序，這樣就對于排行榜一類的查詢需求很尷尬。那么采用rowkey = Integer.MAX_VALUE-rowkey的方式將rowkey進行轉(zhuǎn)換，最大的變最小，最小的變最大。在應用層再轉(zhuǎn)回來即可完成排序需求。
rowkey的散列原則：如果rowkey是類似時間戳的方式遞增的生成，建議不要使用正序直接寫入rowkey，而是采用reverse的方式反轉(zhuǎn)rowkey，使得rowkey大致均衡分布，這樣設(shè)計有個好處是能將regionserver的負載均衡，否則容易產(chǎn)生所有新數(shù)據(jù)都在一個 regionserver上堆積的現(xiàn)象，這一點還可以結(jié)合table的預切分一起設(shè)計。
columnfamily columnfamily盡量少，原因是過多的columnfamily之間會互相影響。
Column 對于column需要擴展的應用，column可以按普通的方式設(shè)計，但是對于列相對固定的應用，最好采用將一行記錄封裝到一個column中的方式，這樣能夠節(jié)省存儲空間。封裝的方式推薦protocolbuffer。
Hbase的row key設(shè)計較為靈活，根據(jù)業(yè)務需求可靈活運用，在此不展開說明。Row key 高級設(shè)計
HBase Memstore
hbase.hregion.memstore.flush.size參數(shù)注意
hbase.hregion.memstore.flush.size 是出發(fā)系統(tǒng)對Memstore進行flush的閾值，但是該參數(shù)并非單個Memstore flush的閾值而是一個Region內(nèi)所有Memstore的大小之后閾值
深入理解HBase Memstore
MemStore是HBase非常重要的組成部分，深入理解MemStore的運行機制、工作原理、相關(guān)配置，對HBase集群管理以及性能調(diào)優(yōu)有非常重要的幫助。
首先通過簡單介紹HBase的讀寫過程來理解一下MemStore到底是什么，在何處發(fā)揮作用，如何使用到以及為什么要用MemStore。
當RegionServer(RS)收到寫請求的時候(write request)，RS會將請求轉(zhuǎn)至相應的Region。每一個Region都存儲著一些列(a set of rows)。根據(jù)其列族的不同，將這些列數(shù)據(jù)存儲在相應的列族中(Column Family，簡寫CF)。不同的CFs中的數(shù)據(jù)存儲在各自的HStore中，HStore由一個Memstore及一系列HFile組成。 Memstore位于RS的主內(nèi)存中，而HFiles被寫入到HDFS中。當RS處理寫請求的時候，數(shù)據(jù)首先寫入到Memstore，然后當?shù)竭_一定的閥值的時候，Memstore中的數(shù)據(jù)會被刷到HFile中。
用到Memstore最主要的原因是：存儲在HDFS上的數(shù)據(jù)需要按照row key 排序。而HDFS本身被設(shè)計為順序讀寫(sequential reads/writes)，不允許修改。這樣的話，HBase就不能夠高效的寫數(shù)據(jù)，因為要寫入到HBase的數(shù)據(jù)不會被排序，這也就意味著沒有為將來的檢索優(yōu)化。為了解決這個問題，HBase將最近接收到的數(shù)據(jù)緩存在內(nèi)存中(in Memstore)，在持久化到HDFS之前完成排序，然后再快速的順序?qū)懭際DFS。需要注意的一點是實際的HFile中，不僅僅只是簡單地排序的列數(shù)據(jù)的列表，詳見Apache HBase I/O – HFile。
除了解決“無序”問題外，Memstore還有一些其他的好處，例如：
作為一個內(nèi)存級緩存，緩存最近增加數(shù)據(jù)。一種顯而易見的場合是，新插入數(shù)據(jù)總是比老數(shù)據(jù)頻繁使用。
在持久化寫入之前，在內(nèi)存中對Rows/Cells可以做某些優(yōu)化。比如，當數(shù)據(jù)的version被設(shè)為1的時候，對于某些CF的一些數(shù)據(jù)，Memstore緩存了數(shù)個對該Cell的更新，在寫入HFile的時候，僅需要保存一個最新的版本就好了，其他的都可以直接拋棄。
有一點需要特別注意：每一次Memstore的flush，會為每一個CF創(chuàng)建一個新的HFile。在讀方面相對來說就會簡單一些：HBase首先檢查請求的數(shù)據(jù)是否在Memstore，不在的話就到HFile中查找，最終返回merged的一個結(jié)果給用戶。
HBase Memstore關(guān)注要點
迫于以下幾個原因，HBase用戶或者管理員需要關(guān)注Memstore并且要熟悉它是如何被使用的：
- Memstore有許多配置可以調(diào)整以取得好的性能和避免一些問題。HBase不會根據(jù)用戶自己的使用模式來調(diào)整這些配置，你需要自己來調(diào)整。
- 頻繁的Memstore flush會嚴重影響HBase集群讀性能，并有可能帶來一些額外的負載。
- Memstore flush的方式有可能影響你的HBase schema設(shè)計
Memstore配置要點
第一組是關(guān)于觸發(fā)“普通”flush，這類flush發(fā)生時，并不影響并行的寫請求。該類型flush的配置項有：
hbase.hregion.memstore.flush.size
base.regionserver.global.memstore.lowerLimit
需要注意的是第一個設(shè)置是每個Memstore的大小，當你設(shè)置該配置項時，你需要考慮一下每臺RS承載的region總量。可能一開始你設(shè)置的該值比較小，后來隨著region增多，那么就有可能因為第二個設(shè)置原因Memstore的flush觸發(fā)會變早許多。
第二組設(shè)置主要是出于安全考慮：有時候集群的“寫負載”非常高，寫入量一直超過flush的量，這時，我們就希望memstore不要超過一定的安全設(shè)置。在這種情況下，寫操作就要被阻止(blocked)一直到memstore恢復到一個“可管理”(manageable)的大小。該類型 flush配置項有：
hbase.regionserver.global.memstore.upperLimit
hbase.hregion.memstore.block.multiplier
某個節(jié)點“寫阻塞”對該節(jié)點來說影響很大，但是對于整個集群的影響更大。HBase設(shè)計為：每個Region僅屬于一個RS但是“寫負載”是均勻分布于整個集群(所有Region上)。有一個如此“慢”的節(jié)點，將會使得整個集群都會變慢(最明顯的是反映在速度上)。
提示：嚴重關(guān)切Memstore的大小和Memstore Flush Queue的大小。理想情況下，Memstore的大小不應該達到 hbase.regionserver.global.memstore.upperLimit的設(shè)置，Memstore Flush Queue 的size不能持續(xù)增長。
頻繁的Memstore Flushes帶來的影響
要避免“寫阻塞”，貌似讓Flush操作盡量的早于達到觸發(fā)“寫操作”的閾值為宜。但是，這將導致頻繁的Flush操作，而由此帶來的后果便是讀性能下降以及額外的負載。
每次的Memstore Flush都會為每個CF創(chuàng)建一個HFile。頻繁的Flush就會創(chuàng)建大量的HFile。這樣HBase在檢索的時候，就不得不讀取大量的HFile，讀性能會受很大影響。
為預防打開過多HFile及避免讀性能惡化，HBase有專門的HFile合并處理(HFile Compaction Process)。HBase會周期性的合并數(shù)個小HFile為一個大的HFile。明顯的，有Memstore Flush產(chǎn)生的HFile越多，集群系統(tǒng)就要做更多的合并操作(額外負載)。更糟糕的是：Compaction處理是跟集群上的其他請求并行進行的。當 HBase不能夠跟上Compaction的時候(同樣有閾值設(shè)置項)，會在RS上出現(xiàn)“寫阻塞”。像上面說到的，這是最最不希望的。
提示：嚴重關(guān)切RS上Compaction Queue 的size。要在其引起問題前，阻止其持續(xù)增大。
想了解更多HFile 創(chuàng)建和合并，可參看 Visualizing HBase Flushes And Compactions。
理想情況下，在不超過hbase.regionserver.global.memstore.upperLimit的情況下，Memstore應該盡可能多的使用內(nèi)存(配置給Memstore部分的，而不是真?zhèn)€Heap的)。
HLog (WAL) Size & Memstore Flush
當數(shù)據(jù)被寫入時會默認先寫入Write-ahead Log(WAL)。WAL中包含了所有已經(jīng)寫入Memstore但還未Flush到HFile的更改(edits)。在Memstore中數(shù)據(jù)還沒有持久化，當RegionSever宕掉的時候，可以使用WAL恢復數(shù)據(jù)。
當WAL(在HBase中成為HLog)變得很大的時候，在恢復的時候就需要很長的時間。因此，對WAL的大小也有一些限制，當達到這些限制的時候，就會觸發(fā)Memstore的flush。Memstore flush會使WAL 減少，因為數(shù)據(jù)持久化之后(寫入到HFile)，就沒有必要在WAL中再保存這些修改。有兩個屬性可以配置：
l hbase.regionserver.hlog.blocksize
l hbase.regionserver.maxlogs
WAL的最大值由hbase.regionserver.maxlogs * hbase.regionserver.hlog.blocksize (2GB by default)決定。一旦達到這個值，Memstore flush就會被觸發(fā)。所以，當你增加Memstore的大小以及調(diào)整其他的Memstore的設(shè)置項時，你也需要去調(diào)整HLog的配置項。否則，WAL 的大小限制可能會首先被觸發(fā)，因而，你將利用不到其他專門為Memstore而設(shè)計的優(yōu)化。拋開這些不說，通過WAL限制來觸發(fā)Memstore的 flush并非最佳方式，這樣做可能會會一次flush很多Region，盡管“寫數(shù)據(jù)”是很好的分布于整個集群，進而很有可能會引發(fā)flush“大風暴”
提示：最好將hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs 設(shè)置為稍微大于hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE.
HBase Compaction
Compaction是buffer->flush->merge的Log-Structured Merge-Tree模型的關(guān)鍵操作，主要起到如下幾個作用：
- 合并文件
- 清除刪除、過期、多余版本的數(shù)據(jù)
- 提高讀寫數(shù)據(jù)的效率
HBase 有兩種方式的Compaction，Minor和Major
- Minor Compaction操作只用來做部分文件的合并操作以及包括minVersion=0并且設(shè)置ttl的過期版本清理，不做任何刪除數(shù)據(jù)、多版本數(shù)據(jù)的清理工作。
- Major Compaction操作是對Region下的HStore下的所有StoreFile執(zhí)行合并操作，最終的結(jié)果是整理合并出一個文件。
#p#
Compaction如何發(fā)生
在什么情況下會發(fā)生Compaction呢?
CompactionChecker是RS上的工作線程，設(shè)置執(zhí)行周期是通過threadWakeFrequency指定，大小通過 hbase.server.thread.wakefrequency配置(默認10000)，然后乘以默認倍數(shù)multiple(1000),毫秒時間轉(zhuǎn)換為秒。因此，在不做參數(shù)修改的情況下，CompactionChecker大概是2hrs, 46mins, 40sec執(zhí)行一次。
首先，對于HRegion里的每個HStore進行一次判斷，needsCompaction()判斷是否足夠多的文件觸發(fā)了Compaction 的條件。條件為：HStore中StoreFIles的個數(shù) – 正在執(zhí)行Compacting的文件個數(shù) > minFilesToCompact
操作：以最低優(yōu)先級提交Compaction申請。
在大多數(shù)情況下，Major是發(fā)生在storefiles和filesToCompact文件個數(shù)相同，并且滿足各種條件的前提下執(zhí)行。這里進行幾個參數(shù)配置的簡介：
- hbase.hregion.majorcompaction： 設(shè)置系統(tǒng)進行一次MajorCompaction的啟動周期，如果設(shè)置為0，則系統(tǒng)不會主動觸發(fā)MC過程。
- hbase.hstore.compaction.max：設(shè)置執(zhí)行Compaction(包括Major &Minor)的待合并文件的最大個數(shù)。默認值為10，如果超過該設(shè)置值，會對部分文件執(zhí)行一次MinorCompaction，選擇算法如 Figure1。
- hbase.hstore.compactionThreshold: 設(shè)置執(zhí)行Compaction(Major && Minor)操作的閾值，默認是3，如果想降低過頻繁的合并操作，可以稍微調(diào)大一點，對于HBase負載較重的系統(tǒng)，可以設(shè)置成5。
Compaction對讀寫操作的影響
Compaction與Flush不同之處在于：Flush是針對一個Region整體執(zhí)行操作，而Compaction操作是針對Region上的一個Store而言，因此，從邏輯上看，F(xiàn)lush操作粒度較大。這屬于一個LSM存儲模型最核心的設(shè)計：
Flush操作如果只選擇某個Region的Store內(nèi)的MemStore寫入磁盤，而不是統(tǒng)一寫入磁盤，那么HLog上key的一致性在Reigon不同ColumnFamily(Store)下的MemStore內(nèi)就會有不一致的key區(qū)間。
如下圖所示，我們假定該RegionServer上僅有一個Region，由于不同的Row是在列簇上有所區(qū)別，就會出現(xiàn)有些不同Store內(nèi)占用的內(nèi)存不一致的情況，這里會根據(jù)整體內(nèi)存使用的情況，或者RS使用內(nèi)存的情況來決定是否執(zhí)行Flush操作。如果僅僅刷入使用內(nèi)存較大的 memstore，那么在使用的過程中，一是Scan操作在執(zhí)行時就不夠統(tǒng)一，二是在HLog Replayer還原Region內(nèi)Memstore故障前的狀態(tài)，只需根據(jù)Hlog的Flush_marker的標記位來執(zhí)行Replay即可。
Compaction執(zhí)行結(jié)束之后會生成臨時文件，臨時文件所在的hdfs位置如下：/hbase-weibo/bi_weibo_cluster /ffd87a50c3df3080183d4910d183d0ee/.tmp ffd87a50c3df3080183d4910d183d0ee 是bi_weibo_cluster表格的Region名。臨時文件的意義在于，在Compaction執(zhí)行期間，對于原數(shù)據(jù)訪問沒有影響。 Compaction執(zhí)行合并操作生成的文件生效過程，需要對Store的寫操作加鎖，阻塞Store內(nèi)的更新操作，直到更新Store的 storeFiles完成為止。(注意，這個操作過程執(zhí)行會影響到更新服務，但是影響不會太大)
對于讀服務的影響，類似于Flush操作，也是通過ChangedReaderObserver為StoreScanner注冊監(jiān)聽類來實現(xiàn)的。具體內(nèi)容可以參考之前的”HBase Flush操作流程以及對讀寫服務的影響”。
HBase Region Server Compact過程占用大量網(wǎng)絡(luò)出口帶寬的問題
該問題較為普遍，當Regionserver帶寬被大量占用的時候，客戶端的寫入基本全都超時，有網(wǎng)友分析并提供了解決方案。
HBase Region
Region的分配問題
當Region數(shù)量變多的時候，就需要把它們分配給不同的Region Server來保證每個Region Server都有事情做，但是當region數(shù)量遠遠大于Region Server個數(shù)的時候，就需要保證一個load balance問題，不能讓一個Region Server上有大量的regions，而其他Region Server上只有幾個regions，這樣很可能導致負載不均衡。
Region split問題
hbase通過split region實現(xiàn)水平的sharding，但在split的過程中舊的region會下線，新region還會做compaction，中間有一段時間大量的數(shù)據(jù)不能被讀寫，這對于我們這種online系統(tǒng)是不能忍受的。我們同樣禁掉自動的split，而在晚上系統(tǒng)空閑時執(zhí)行我們的splittool手動的split。
禁用方法把hbase.hregion.max.filesize參數(shù)值設(shè)成較大的值例如536870912000
(500g)
在對Region進行手工split的過程中，出現(xiàn)以下異常
./hbase org.apache.hadoop.hbase.util.RegionSplitter -r lsmp_lottery_presplit HexStringSplit
這個HBase的一個bug,HBase0.94 出現(xiàn)以上錯誤,需要打補丁即可，https://issues.apache.org/jira/browse/HBASE-7048
HBase寫客戶端優(yōu)化
多HTable并發(fā)寫
創(chuàng)建多個HTable客戶端用于寫操作，提高寫數(shù)據(jù)的吞吐量。另外還可以使用HTablePool來實現(xiàn)多線程寫入。
HTable參數(shù)設(shè)置
- Auto Flush
通過調(diào)用HTable.setAutoFlush(false)方法可以將HTable寫客戶端的自動flush關(guān)閉，這樣可以批量寫入數(shù)據(jù)到 HBase，而不是有一條put就執(zhí)行一次更新，只有當put填滿客戶端寫緩存時，才實際向HBase服務端發(fā)起寫請求。默認情況下auto flush是開啟的。
- Write Buffer
通過調(diào)用HTable.setWriteBufferSize(writeBufferSize)方法可以設(shè)置 HTable客戶端的寫buffer大小，如果新設(shè)置的buffer小于當前寫buffer中的數(shù)據(jù)時，buffer將會被flush到服務端。其 中，writeBufferSize的單位是byte字節(jié)數(shù)，可以根據(jù)實際寫入數(shù)據(jù)量的多少來設(shè)置該值。
- WAL Flag
在HBae中，客戶端向集群中的RegionServer提交數(shù)據(jù)時(Put/Delete操作)，首先會先寫WAL(Write Ahead Log)日志(即HLog，一個RegionServer上的所有Region共享一個HLog)，只有當WAL日志寫成功后，再接著寫 MemStore，然后客戶端被通知提交數(shù)據(jù)成功;如果寫WAL日志失敗，客戶端則被通知提交失敗。這樣做的好處是可以做到RegionServer宕機 后的數(shù)據(jù)恢復。
因此，對于相對不太重要的數(shù)據(jù)，可以在Put/Delete操作時，通過調(diào)用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函數(shù)，放棄寫WAL日志，從而提高數(shù)據(jù)寫入的性能。
需要注意的是：謹慎選擇關(guān)閉WAL日志，因為這樣的話，一旦RegionServer宕機，Put/Delete的數(shù)據(jù)將會無法根據(jù)WAL日志進行恢復。
批量寫入
通過調(diào)用HTable.put(Put)方法可以將一個指定的row key記錄寫入HBase，同樣HBase提供了另一個方法：通過調(diào)用HTable.put(List)方法可以將指定的row key列表，批量寫入多行記錄，這樣做的好處是批量執(zhí)行，只需要一次網(wǎng)絡(luò)I/O開銷，這對于對數(shù)據(jù)實時性要求高，網(wǎng)絡(luò)傳輸RTT高的情景下可能帶來明顯的 性能提升。
多線程并發(fā)寫
在客戶端開啟多個HTable寫線程，每個寫線程負責一個HTable對象的flush操作，這樣結(jié)合定時flush和寫 buffer(writeBufferSize)，可以既保證在數(shù)據(jù)量小的時候，數(shù)據(jù)可以在較短時間內(nèi)被flush(如1秒內(nèi))，同時又保證在數(shù)據(jù)量大的 時候，寫buffer一滿就及時進行flush。
其他
enable和disable表時出現(xiàn)表未disable/enable異常處理
今天在為表增加LZO壓縮，在enable表時，發(fā)現(xiàn)耗時很長都未結(jié)束，就ctrl+c退出hbase shell，再進入繼續(xù)enable表，但此時出現(xiàn)如下錯誤：
錯誤說表未禁用，但進行disable表操作時，又出現(xiàn)如下錯誤：
那肯定是剛才強行退出導致出問題了，根據(jù)大家的經(jīng)驗，指出這是因為zookeeper保持了要enable的這個表信息，只需要登錄zk刪除該記錄就行。
登錄到zookeeper也有兩種方式，一是到zk目錄運行腳本連接，而是直接在hbase安裝目錄bin下運行：
hbase zkcli
都是小寫字母。之后就能連接上zookeeper了，跟著刪除/hbase/table下對應的表項就行：
delete /hbase/table/user_video_recommend2
之后就可以成功的enable表了。
如果此時仍然失敗，則可以運行一下命了修復META：
hbase hbck -fixMeta -fixAssignments
HBase元數(shù)據(jù)損壞修復
hbase hbck -repair -sidelineDir hdfs://mycluster/hbase/rbu
但是出問題的時候有可能出現(xiàn)RIT中大量任務無法結(jié)束，只要沒有長期PENDING_OPEN的任務，就可以先將有問題的表先disable一下。這里要提到的是hbase的hbck很弱，會形成一個死循環(huán)，一方面region由于元數(shù)據(jù)破壞無法開啟需要repair，造成大量的RIT長期hang 在上面，但是repair的操作卻要等待這些RIT結(jié)束才能繼續(xù)，而且repair操作也不是離線操作，必須要先保證hbase能正常起來。因此打破死循環(huán)的關(guān)鍵就是先處理掉RIT中hang的操作，這需要經(jīng)驗和仔細排查。
如果出現(xiàn)長期的pending_open，則要觀察pending_open的原因，要嘗試解決，這次我們出現(xiàn)的問題是元數(shù)據(jù)出錯，某個 Region的對row的加鎖范圍超出region本身的key的取值范圍，引起不斷地PENING_OPEN，通過離線的merge操作將該 region隨便找了個region merge下解決了該問題，./hbase org.apache.hadoop.hbase.util.Merge
最后可通過hbck恢復元數(shù)據(jù)，但是hbck恢復過程中可能會丟失數(shù)據(jù)，因此要慎用，最好通過SNAPSHOT做備份來解決這類問題
HBaseClient異常：java.io.IOException: Connection reset by peer
hbase客戶端每次和regionserver交互的時候，都會在服務器端生成一個租約(Lease),租約的有效期由參數(shù)hbase.regionserver.lease.period確定。
客戶端去regionserver取 數(shù)據(jù)的時候，hbase中存得數(shù)據(jù)量很大并且很多region的時候的，客戶端請求的region不在內(nèi)存中，或是沒有被cache住，需要從磁盤中加 載，如果這時候加載需要的時間超過hbase.regionserver.lease.period所配置的時間，并且客戶端沒有和 regionserver報告其還活著，那么regionserver就會認為本次租約已經(jīng)過期，并從LeaseQueue從刪除掉本次租約，當 regionserver加載完成后，拿已經(jīng)被刪除的租約再去取數(shù)據(jù)的時候，就會出現(xiàn)如上的錯誤現(xiàn)象。
解決的辦法：
1)、適當?shù)脑龃?hbase.regionserver.lease.period參數(shù)的值，默認是1分鐘
2)、增大regionserver的cache大小
#p#
Nginx:
概要介紹
Nginx是一款高性能的HTTP和反向代理服務器，也是一個IMAP/POP3/SMTP代理服務器。第一個公開版本發(fā)布于2004年10月4日，其將源代碼以類BSD許可證的形式發(fā)布，因它的穩(wěn)定性、豐富的功能集和低系統(tǒng)資源的消耗而聞名。Nginx的最新穩(wěn)定版本是1.4.4。與Apache、Lighttpd不同，Nginx充分使用異步邏輯，削減了上下文調(diào)度開銷，所以并發(fā)服務能力更強。Nginx整體采用模塊化設(shè)計，有豐富的模塊庫和第三方模塊庫，配置靈活。 在Linux操作系統(tǒng)下，Nginx使用epoll事件模型，得益于此，其在效率相當高。在國內(nèi)，各大主流站點都在使用Nginx作為Web服務器或反向代理服務器。據(jù)統(tǒng)計，截止今年2013年7月，在全球Top 1000網(wǎng)站中，有34.9%的網(wǎng)站在使用Nginx，這使得Nginx超越Apache，成為了TOP站點最信任的Web服務器。下圖可見Nginx在 TOP站點的受歡迎程度(見橙色條目)。
主要功能
- 輕松搞定C10K問題，且占內(nèi)存極少，據(jù)稱C10K idle連接僅需內(nèi)存2.5MB;
- 處理靜態(tài)文件的性能非常優(yōu)秀，支持sendfile、AIO等高級特性，支持靜態(tài)文件Auto Index;
- 支持反向代理，對后端服務進行健康檢查;
- 支持反向代理緩存，避免與后端的頻繁交互;
- 支持郵件服務代理：IMAP、POP3、SMTP;
- 支持負載均衡策略，包括：round-robin、weight、hash、consistent hash、fair等;
- 支持HTTPS安全訪問;
- 支持虛擬主機的配置;
- 支持基本W(wǎng)eb認證機制;
- 支持基于IP的訪問控制;
- 支持URL規(guī)則重寫;
- 支持并發(fā)連接數(shù)限制和單條連接的限速;
- 支持WebSocket和SPDY;
- 支持Referer 過濾防盜鏈;
- 支持靈活配置輸出日志;
擴展功能
- 能夠在配置文件中嵌入ngx_perl和ngx_lua腳本，擴展功能超強;
- 提供了與Memcached、Redis、MySQL、PostgreSQL、MangoDB、MogileFS、TaobaoFS等常見服務器交互的模塊;
- Image 模塊實現(xiàn)了簡單的圖片功能，包括：縮略、裁剪、質(zhì)量參數(shù)等;
- 視頻支持包括：FLV和MP4視頻播放，RTMP模塊具有在線ffmpeg轉(zhuǎn)碼以及M3U8的支持;
- PageSpeed模塊實現(xiàn)網(wǎng)頁加速功能，具體包括：圖片優(yōu)化，CSS&JS 壓縮合并，資源內(nèi)聯(lián)，HTML重寫;
- 與后端Tomcat的連接可以使用AJP 模塊進行協(xié)議優(yōu)化;
- Push 模塊實現(xiàn)長連接輪詢服務，實現(xiàn)Web推送服務(Comet);
- UploadRate 模塊實現(xiàn)上傳的流量限制功能;
常用配置
虛擬主機
- http {
- index index.html;
- # 虛擬主機 www.domain1.com;
- server {
- server_name www.domain1.com;
- access_log logs/domain1.access.log main;
- root /var/www/domain1.com/htdocs;
- }
- # 虛擬主機 www.domain2.com
- server {
- server_name www.domain2.com;
- access_log logs/domain2.access.log main;
- root /var/www/domain2.com/htdocs;
- }
- }
負載均衡
- # 默認的負載均衡，Round-Robin
- upstream backend1 {
- server backend1.example.com;
- server backend2.example.com;
- server backend3.example.com;
- }
- # 基于權(quán)重的負載均衡
- upstream backend2 {
- server backend1.example.com weight=5;
- server backend2.example.com weight=2;
- server backend3.example.com weight=3;
- }
- # 基于request_uri hash的負載均衡
- upstream backend3 {
- server backend1.example.com;
- server backend2.example.com;
- server backend3.example.com;
- hash $request_uri;
- }
- # 基于request_uri consistent hash的負載均衡
- upstream backend4 {
- server backend1.example.com;
- server backend2.example.com;
- server backend3.example.com;
- consistent_hash $request_uri;
- }
- # 基于后端響應時間的負載均衡
- upstream backend5 {
- server backend1.example.com;
- server backend2.example.com;
- server backend3.example.com;
- fair;
- }
- server {
- location / {
- proxy_pass http://backend1;
- # proxy_pass http://backend2;
- # proxy_pass http://backend3;
- # proxy_pass http://backend4;
- # proxy_pass http://backend5;
- }
- }
以上可見，Nginx支持的負載均衡策略非常全面，總結(jié)有五種策略，即：
- Round-Robin：輪詢;
- Weight：基于權(quán)重;
- Hash：基于Nginx內(nèi)置參數(shù)的哈希，內(nèi)置參數(shù)可以為ClientIP、Request_URI等;
- Consistent Hash：基于Nginx內(nèi)置參數(shù)的一致性哈希;
- Fair：公平策略，根據(jù)響應時間來判定應該將請求發(fā)往那個后端服務器;
除此之外，Nginx負載均衡還支持以下關(guān)鍵參數(shù)：
- down：表示當前的server暫時不參與負載;
- max_fails：允許重試的最大次數(shù)，當達到該次數(shù)，Nginx將暫停向該server發(fā)送請求;
- fail_timeout：max_fails次失敗后，暫停的時間;
- backup： 其它所有的非backup機器down或者忙的時候，請求backup機器，這臺機器壓力會最輕;
流量限制
- server {
- location / {
- root html; # 靜態(tài)文件root目錄
- limit_rate_after 1m; # 文件下載1M后
- limit_rate 100k; # 限制其下載流量為100k
- }
- }
注：limit_rate只能限制單條連接的流量
連接限制
- http {
- # 并發(fā)連接統(tǒng)計粒度為 $binary_remote_addr
- # 粒度還可以為 $request_uri 等任意的Nginx內(nèi)置變量
- limit_conn_zone $binary_remote_addr zone=one:2m;
- server {
- location /download {
- limit_conn one 100; # 同一個remote_addr只允許100個并發(fā)連接
- }
- }
- }
代理緩存
- server {
- # 設(shè)置Web緩存區(qū)名稱為cache_one，內(nèi)存緩存空間大小為200MB，1天沒有被訪問的內(nèi)容自動清除，硬盤緩存空間大小為30GB。
- proxy_cache_path /data0/proxy_cache_dir levels=1:2 keys_zone=cache_one:200m inactive=1d max_size=30g;
- location / {
- # 如果后端的服務器返回502、504、執(zhí)行超時等錯誤，自動將請求轉(zhuǎn)發(fā)到upstream負載均衡池中的另一臺服務器，實現(xiàn)故障轉(zhuǎn)移。
- proxy_next_upstream http_502 http_504 error timeout invalid_header;
- proxy_cache cache_one;
- # 對不同的HTTP狀態(tài)碼設(shè)置不同的緩存時間
- proxy_cache_valid 200 304 12h;
- # 以域名、URI、參數(shù)組合成Web緩存的Key值，Nginx根據(jù)Key值哈希，存儲緩存內(nèi)容到二級緩存目錄內(nèi)
- proxy_cache_key $host$uri$is_args$args;
- proxy_set_header Host $host;
- proxy_set_header X-Forwarded-For $remote_addr;
- proxy_pass http://backend_server;
- expires 1d;
- }
- }
注1：Nginx反向代理緩存應用于云閱讀縮略圖服務的緩存;
注2：Nginx仍舊以小文件的方式存儲緩存數(shù)據(jù)，導致磁盤IOUtil較高，當前線上使用SSD;
視頻播放
- server {
- # mp4后綴的文件走mp4播放模塊
- location ~ \.mp4$ {
- mp4;
- mp4_buffer_size 1m;
- mp4_max_buffer_size 5m;
- mp4_limit_rate on;
- mp4_limit_rate_after 30s;
- }
- # flv后綴的文件走flv播放模塊
- location ~ \.flv$ {
- flv;
- }
- }
注1：云課堂、公開課就是使用這種方式進行視頻播放;
注2：線上環(huán)境更加復雜，還編譯了第三方的mp4播放模塊以支持android4.4的播放;
常見問題
- CLOUD-6824：與后端服務務必保持長連接，否則將出現(xiàn)大量TIME_WAIT，并且會影響性能;
- CLOUD-6832：HTTP1.0的請求在過Nginx反向代理時，默認將不會保持Keep-Alive，需要專門進行配置;
- CLOUD-6833：錯誤日志error.log是監(jiān)控Nginx狀態(tài)的重要途徑，可以寫腳本監(jiān)控其輸出并報警;
- CLOUD-6332：Nginx默認會緩存上傳和下載的臨時文件，大量的上傳下載可能導致臨時文件目錄磁盤IO成為瓶頸，需要適當調(diào)整;
- CLOUD-6519：Nginx與后端并發(fā)量不是很大的時候，可以開啟流式下載，以避免臨時文件導致的額外磁盤IO;
- CLOUD-7493：Nginx讀靜態(tài)文件時默認不會開啟AIO，可能導致Worker進程D狀態(tài);
- CLOUD-7065：Nginx默認情況下，worker_rlimit_nofile為1024，導致大并發(fā)請求失敗，因此大并發(fā)需要設(shè)置合理的worker_rlimit_nofile值;
- CLOUD-6334：對于服務海量請求的Nginx，需要做專門的優(yōu)化，具體這里有專門的總結(jié);
- CLOUD-5582：Nginx與后端服務器Keep-Alive連接的數(shù)量為 worker_count * keep_alive 配置;
- CLOUD-7224：可以配置Nginx coredump時產(chǎn)生的core路徑，以便事后分析原因;
- CLOUD-7461：臨時文件緩存大小和后端連接的超時需要綜合考慮，否則可能出問題;
- SDFS-497：如果后端服務返回的HTTP請求沒有Content-Length頭，Nginx默認將使用Transfer-Encoding:chunked對Body進行編碼;
#p#
Zookeeper：
ZooKeeper
一、簡介
ZooKeeper是一個開源的分布式應用協(xié)調(diào)服務，以Fast Paxos算法為理論基礎(chǔ)，可保證分布式環(huán)境中數(shù)據(jù)的強一致性，可用于解決分布式應用中經(jīng)常遇到的數(shù)據(jù)管理問題。
二、ZooKeeper編程模型
ZooKeeper的數(shù)據(jù)模型風格很像文件系統(tǒng)的目錄結(jié)構(gòu)，可看做一個樹形結(jié)構(gòu)的數(shù)據(jù)庫，與文件系統(tǒng)不同的是文件系統(tǒng)中的節(jié)點有目錄和文件的區(qū)分， 目錄是中間節(jié)點，其本身并不存數(shù)據(jù)，而文件是葉節(jié)點，只有內(nèi)容沒有子項;而zookeeper的樹形結(jié)構(gòu)中所有的節(jié)點上都能存儲數(shù)據(jù)內(nèi)容，也能包含子項。 其節(jié)點被成為zNode，zNode有臨時(EPHEMERAL)和遞增(SEQUENTIAL)等可選屬性，zNode可以通過配置Watcher來監(jiān) 控狀態(tài)變化，并引導客戶端觸發(fā)相應操作。關(guān)于Zookeeper的介紹和數(shù)據(jù)模型等可參考以下文章：
http://shiyanjun.cn/archives/474.html
http://stblog.baidu-tech.com/?p=1164
三、應用場景
常見的應用場景如下：
場景1 心跳狀態(tài)檢測
利用zookeeper的EPHEMERAL節(jié)點的特征，記錄server的活動狀態(tài)。server宕機時，zookeeper連接斷開，EPHEMERAL自動刪除，可通過watch EPHEMERAL節(jié)點的存在狀況判斷server的存活狀態(tài)。
場景2 全局自增ID的生成
利用Zookeeper的SEQUENTIAL的特征，單個節(jié)點下的SEQUENTIAL節(jié)點名稱都帶有自增的序號，獲取ID是只需創(chuàng)建一個SEQUENTIAL節(jié)點即可。
場景3 統(tǒng)一命名服務(Naming Service)
利用zk的樹形結(jié)構(gòu)特征，每個節(jié)點有全局唯一的路徑，可用來提供全局命名。
場景4 配置管理(即發(fā)布訂閱)
利用zookeeper可以配置Watcher的特征，可以將分布式系統(tǒng)的配置寫入到不同的樹形節(jié)點中，客戶端對關(guān)心的配置項設(shè)置watcher，當配置發(fā)生變更時自動獲取最新配置，從而實現(xiàn)分布式環(huán)境下不同節(jié)點上配置的實時更新。
場景5 集群管理
利用zookeeper基于fast paxos算法的選舉功能，實現(xiàn)集群master節(jié)點的選舉。可以在集群環(huán)境中master宕機時動態(tài)選擇master，解決傳統(tǒng)上很容易出現(xiàn)的單點故障問題。
場景6 共享鎖Locks
利用EPHEMERAL_SEQUENTIAL節(jié)點的特征，實現(xiàn)共享鎖，需要獲得鎖的 Server 創(chuàng)建一個 EPHEMERAL_SEQUENTIAL 目錄節(jié)點，然后調(diào)用 getChildren方法獲取當前的目錄節(jié)點列表中最小的目錄節(jié)點是不是就是自己創(chuàng)建的目錄節(jié)點，如果正是自己創(chuàng)建的，那么它就獲得了這個鎖，如果不是 那么它就調(diào)用 exists(String path, boolean watch) 方法并監(jiān)控 Zookeeper 上目錄節(jié)點列表的變化，一直到自己創(chuàng)建的節(jié)點是列表中最小編號的目錄節(jié)點，從而獲得鎖，釋放鎖時直接刪除自己創(chuàng)建的節(jié)點。
場景7 隊列管理
ZooKeeper 可以處理兩種類型的隊列：
1. 當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達，這種是同步隊列。
2. 隊列按照 FIFO 方式進行入隊和出隊操作，例如實現(xiàn)生產(chǎn)者和消費者模型。關(guān)于應用場景的描述和實現(xiàn)具體可參考以下博文：
http://django-china.cn/topic/135/ (原文http://rdc.taobao.com/team/jm/archives/1232 )
四、應用陷阱
并不是任何分布式應用都適合使用ZooKeeper來構(gòu)建協(xié)調(diào)服務，以下是幾種可能出現(xiàn)的問題：
1. 丟失ZNode上的變更通知
客戶端連接到ZooKeeper Server以后，會維護一個TCP連接，在CONNECTED狀態(tài)下，客戶端設(shè)置了某個ZNode的Watch監(jiān)聽器，可以收到來自該節(jié)點變更的通知并 觸發(fā)相應的事件。但是如果由于網(wǎng)絡(luò)異常客戶端斷開了與ZooKeeper Server的連接，在斷開的過程中，是無法收到ZooKeeper在ZNode上發(fā)送的節(jié)點數(shù)據(jù)變更通知的。如果使用ZooKeeper的Watch， 必須要尋找保持CONNECTED的Watch，才能保證不會丟失該Watch監(jiān)控的ZNode上的數(shù)據(jù)變更通知。
2. 無效ZooKeeper集群節(jié)點列表
與ZooKeeper集群交互時，一般情況下客戶端會持有一個ZooKeeper集群節(jié)點的列表，或者列表的子集，那么會存在如下兩種情況： 一種情況是，如果客戶端持有ZooKeeper集群節(jié)點列表或列表子集，如果列表中的某些節(jié)點因為故障退出了集群客戶端再次連接這一類失效的節(jié)點，就無法 獲取服務。所以在應用中使用ZooKeeper集群時，一定要明確這一點，或者跳過無效的節(jié)點，或者重新尋找有效的節(jié)點繼續(xù)業(yè)務處理，或者檢查 ZooKeeper集群，使整個集群恢復正常。
3. 配置導致的性能問題
如果設(shè)置Java堆內(nèi)存(Heap)不合理，會導致ZooKeeper內(nèi)存不足，會在內(nèi)存與文件系統(tǒng)之間進行數(shù)據(jù)交換，導致ZooKeeper的性 能極大地下降，從而可能會影響應用程序。為了避免Swapping問題的出現(xiàn)，主要考慮設(shè)置足夠的Java堆內(nèi)存，同時減少被操作系統(tǒng)和Cache使用的 內(nèi)存，盡量避免在內(nèi)存與文件系統(tǒng)之間發(fā)生數(shù)據(jù)交換，或者可以將交換限制在一定的范圍之內(nèi)。
4. 事務日志存儲設(shè)備性能
ZooKeeper會同步事務到存儲設(shè)備，如果存儲設(shè)備不是專用的，而是和其他I/O密集型應用共享同一磁盤，會導致ZooKeeper的效率降 低。因為客戶端請求ZNode數(shù)據(jù)變更而發(fā)生的事務，ZooKeeper會在響應之前將事務日志寫入存儲設(shè)備，為zookeeper配置專用的存儲設(shè)備可 以使整個服務以及外部應用都會獲得極大地性能提升。
5. ZNode存儲大量數(shù)據(jù)導致性能問題
ZooKeeper的設(shè)計初衷是，每個ZNode只存放少量的同步數(shù)據(jù)(一般一個節(jié)點上的數(shù)據(jù)小于1M)，如果存儲了大量數(shù)據(jù)，導致 ZooKeeper每次節(jié)點發(fā)生變更時需要將事務寫入存儲設(shè)備，同時還要在集群內(nèi)部復制傳播，這將導致不可避免的延遲和性能問題。所以，如果需要與大量的 數(shù)據(jù)相關(guān)，可以將大量數(shù)據(jù)存儲在其他設(shè)備中，而只是在ZooKeeper中存儲一個簡單的映射，如指針、引用等等。
五、其他
- zookeeper節(jié)點的size限制，和超限后的解決方法
Zookeeper單個Znode能存放的數(shù)據(jù)大小在1M左右，如果數(shù)據(jù)量過大客戶端會出現(xiàn)異常，異常信息類似如下：Packet len5187750 is out of range!
這種情況可以通過修改java環(huán)境變量來解決，但是還是需要在應用中避免在zookeeper上存儲大量數(shù)據(jù)的情況，這是一種不好的使用方式。-Djute.maxbuffer=51877500
如:$JAVA -cp “$CLASSPATH” -Djute.maxbuffer=51877500 com.netease.datastream.tool.zkUtil.opers.ZkUtilMain $* 2>&1 &
- 配置完ZooKeeper集群服務之后要配置Snapshot和Transaction log的定時清理任務
由于所有zookeeper上的數(shù)據(jù)操作都會觸發(fā)事務日志，事務日志在達到一定大小之后會歸檔為鏡像文件snapshot，如果不配置定時清理任務，這些文件會很快耗盡磁盤空間。可以在linux的crontab任務列表中配置如下項：# m h dom mon dow command
0 7 * * * /home/ds/zookeeper/bin/zkCleanup.sh -n 5 >/dev/null以上任務表示每日7：00執(zhí)行清理任務，僅保留最新的5個鏡像文件和事務日志。
- 查看指定某個節(jié)點狀態(tài)
可通過以下腳本echo stat|nc
- 相關(guān)工具
Eclipse插件 update-site http://www.massedynamic.org/eclipse/updates/
Zookeeper瀏覽器客戶端 https://issues.apache.org/jira/secure/attachment/12436620/ZooInspector.zip
附、參考文檔
官方文檔： http://zookeeper.apache.org/doc/r3.4.5/
安裝配置： http://shiyanjun.cn/archives/469.html
原文鏈接：http://thinkinginjavablog.sinaapp.com/?p=599&utm_source=tuicool&utm_medium=referral
