7、hbase的容錯性
注：一張hbase表在剛剛建立的時候，預設只有乙個region。所以多有關於這張表的請求都被路由到同乙個region server，不管集群中有多少region server。這也就是為什麼hbase表在剛剛建立的階段不能充分利用整個集群的吞吐量的原因。如果想開始就用到集群的吞吐量，可以再建立表時候，啟用預分割槽方式實現。
注：hstore儲存由兩部分組成：memstore和storefiles。 memstore是sorted memory buffer,使用者 寫入資料首先 會放在memstore,當memstore滿了以後會flush成乙個 storefile（實際儲存在hdhs上的是hfile），當storefile檔案數量增長到一定閥值，就會觸發compact合併操作，並將多個storefile合併成乙個storefile，合併過程中會進行版本合併和資料刪除，因此可以看出hbase其實只有增加資料，所有的更新和刪除操作都是在後續的compact過程中進行的，這使得使用者的 讀寫操作*只要進入記憶體中就可以立即返回，保證了hbase i/o的高效能。
hbase的用-root-表來記錄.meta.的region資訊，就和.meta.記錄使用者表的region資訊一模一樣。-root-只會有乙個region。
這麼一來client端就需要先去訪問-root-表。所以需要知道管理-root-表的regionserver的位址。這個位址被存在zookeeper中。預設的路徑是：/hbase/root-region-server
-root-行記錄結構
.meta.表結構
hbase的所有region元資料被儲存在.meta.表中，隨著region的增多，.meta.表中的資料也會增大，並**成多個新的region。為了定位.meta.表中各個region的位置，把.meta.表中所有region的元資料儲存在-root-表中，最後由zookeeper記錄-root-表的位置資訊。所有客戶端訪問使用者資料前，需要首先訪問zookeeper獲得-root-的位置，然後訪問-root-表獲得.meta.表的位置，最後根據.meta.表中的資訊確定使用者資料存放的位置，如下圖所示。
-root-表永遠不會被分割，它只有乙個region，這樣可以保證最多隻需要三次跳轉就可以定位任意乙個region。為了加快訪問速度，.meta.表的所有region全部儲存在記憶體中。客戶端會將查詢過的位置資訊快取起來，且快取不會主動失效。如果客戶端根據快取資訊還訪問不到資料，則詢問相關.meta.表的region伺服器，試圖獲取資料的位置，如果還是失敗，則詢問-root-表相關的.meta.表在**。最後，如果前面的資訊全部失效，則通過zookeeper重新定位region的資訊。所以如果客戶端上的快取全部是失效，則需要進行6次網路來回，才能定位到正確的region。
最後要提醒大家注意兩件事情：
在整個路由過程中並沒有涉及到masterserver，也就是說hbase日常的資料操作並不需要masterserver，不會造成masterserver的負擔。
client端並不會每次資料操作都做這整個路由過程，很多資料都會被cache起來。至於如何cache，則不在本文的討論範圍之內。
參考：參考：
寫請求被region server處理，region server會先將資料寫到稱為「memstore」的記憶體儲存系統中。一旦memstore寫滿，就會被寫到磁碟上的儲存檔案中，這個過程稱為「memstore flush」。隨著儲存檔案的積累，region server會將它們合併成乙個更大檔案。隨著每一次寫磁碟和合併操作完成，如果region拆分策略任務這個region需要被拆分，則會發起region拆分請求。由於hbase所有的資料檔案是不可變的，進行region拆分時，乙個region被拆分為兩個region時，兩個新建立的region不會重寫所有的資料到新的檔案，而是建立小的sym-link檔案，sym-link檔案也叫reference檔案。reference檔案根據分割點，指向父儲存檔案的頂部或底部。reference檔案的使用和常規資料檔案一樣，但它只有一半的記錄。如果reference檔案不再有對父region的不可變資料檔案的引用，則這個region不可以再拆分。這些reference檔案通過合併逐漸清理，以便該region停止引用其父檔案，並可以進一步拆分。
儘管region拆分是由region server本地進行決策的，但是拆分過程卻有很多參與者。region server在region拆分前後都會通知master程序更新.meta.表， 以便client可以找到拆分出來的新的兩個region。還需要重新排列目錄結構以及hdfs中的資料檔案。region拆分過程有多個任務完成。為了在發生錯誤時可以回滾，regionserver會在記憶體中儲存執行狀態日誌。圖1顯示了region server執行拆分的步驟。每個步驟都標有其步驟編號。來自region servers或master的操作顯示為紅色，而來自客戶端的操作顯示為綠色。
參考：(1) client通過zookeeper的排程，向regionserver發出寫資料請求，在region中寫資料。
(2) 資料被寫入region的memstore，直到memstore達到預設閾值。
(3) memstore中的資料被flush成乙個storefile。
(4) 隨著storefile檔案的不斷增多，當其數量增長到一定閾值後，觸發compact合併操作，將多個storefile合併成乙個storefile，同時進行版本合併和資料刪除。
(5) storefiles通過不斷的compact合併操作，逐步形成越來越大的storefile。
(6) 單個storefile大小超過一定閾值後，觸發split操作，把當前region split成2個新的region。父region會下線，新split出的2個子region會被hmaster分配到相應的regionserver上，使得原先1個region的壓力得以分流到2個region上。
可以看出hbase只有增添資料，所有的更新和刪除操作都是在後續的compact歷程中舉行的，使得使用者的寫操作只要進入記憶體就可以立刻返回，實現了hbase i/o的高效能。
(1) client訪問zookeeper，查詢-root-表，獲取.meta.表資訊。
(2) 從.meta.表查詢，獲取存放目標資料的region資訊，從而找到對應的regionserver。
(3) 通過regionserver獲取需要查詢的資料。
(4) regionserver的記憶體分為memstore和blockcache兩部分，memstore主要用於寫資料，blockcache主要用於讀資料。讀請求先到memstore中查資料，查不到就到blockcache中查，再查不到就會到storefile上讀，並把讀的結果放入blockcache。
定址過程：client–>zookeeper–>-root-表–>meta表–>regionserver–>region–>client
一文弄懂 C vector
c 標準模板庫的核心包括以下三個元件 元件描述 容器 containers 容器是用來管理某一類物件的集合。c 提供了各種不同型別的容器，比如 deque list vector map 等。演算法 algorithms 演算法作用於容器。它們提供了執行各種操作的方式，包括對容器內容執行初始化 排序...
一文弄懂Nginx最核心的配置
在日常的工作中，跟nginx打交道的時候挺多的。之前對location的匹配規則是一知半解的，為了搞明白location是如何匹配的，查了些資料總結此文。希望能給大家帶來幫助。location uri location name語法規則很簡單，乙個location關鍵字，後面跟著可選的修飾符，後面是...
從頭學習Drupal 基本架構一
前面學習了drupal的一些基本概念,其實我們在構建乙個系統的時候,一般都需要從兩個方面來考慮問題 業務模型 也就是領域模型,是面向我們所要解決的問題域所構建的模型,前面我們說的關於內容描述方面的幾個概念,其實就是對領域內概念,元素進行概括,抽象得出的業務模型基類.構建良好的業務模型,能有效地將問題...