鎖屏面試題百日百刷，每個工作日堅持更新面試題。請看到最後就能獲取你想要的,接下來的是今日的面試題： 1.HBase內部機制是什麼？ Hbase是一個能適應聯機業務的資料庫系統 物理存儲：hbase的持久化數據是將數據存儲在HDFS上。 存儲管理：一個表是劃分為很多region的，這些region分佈 ...
鎖屏面試題百日百刷，每個工作日堅持更新面試題。請看到最後就能獲取你想要的,接下來的是今日的面試題：
1.HBase內部機制是什麼？
Hbase是一個能適應聯機業務的資料庫系統
物理存儲：hbase的持久化數據是將數據存儲在HDFS上。
存儲管理：一個表是劃分為很多region的，這些region分散式地存放在很多regionserver上Region內部還可以
劃分為store，store內部有memstore和storefile。
版本管理：hbase中的數據更新本質上是不斷追加新的版本，通過compact操作來做版本間的文件合併Region
的split。
集群管理：ZooKeeper + HMaster + HRegionServer。
2.HTable API有沒有線程安全問題，在程式是單例還是多例？
在單線程環境下使用hbase的htable是沒有問題，但是突然高併發多線程情況下就可能出現問題。
以下為Htable的API說明：
This class is not thread safe for updates; the underlying write buffer can be corrupted if multiple threads contend over a single HTable instance. 當有多個線程競爭時可能把當前正在寫的線程corrupted，那麼原因是什麼呢？
根據Htable的源碼：
public HTable(final byte [] tableName)throws IOException{this(HBaseConfiguration.create(), tableName);}public static Configuration create() {Configuration conf = new Configuration();return addHbaseResources(conf);}
從上面我們可以看到每一個HTable的實例化過程都要創建一個新的conf，我們甚至可以認為一個conf對應的是一個HTable的connection，因此如果客戶端對於同一個表，每次新new 一個configuration對象的話，那麼意味著這兩個HTable雖然操作的是同一個table，但是建立的是兩條鏈接connection，它們的socket不是共用的，在多線程的情況下，經常會有new Htable的情況發生，而每一次的new都可能是一個新的connection，而我們知道zk上的鏈接是有限制的如果鏈接達到一定閾值的話，那麼新建立的鏈接很有可能擠掉原先的connection，而導致線程不安全。
因此hbase官方文檔建議我們：HTable不是線程安全的。建議使用同一個HBaseConfiguration實例來創建HTable實例，這樣可以共用ZooKeeper和socket實例。例如，最好這樣做：
HBaseConfiguration conf = HBaseConfiguration.create();HTable table1 = new HTable(conf, "myTable");HTable table2 = new HTable(conf, "myTable");
而不是這樣：
HBaseConfiguration conf1 = HBaseConfiguration.create();HTable table1 = new HTable(conf1, "myTable");HBaseConfiguration conf2 = HBaseConfiguration.create();HTable table2 = new HTable(conf2, "myTable");
當然最方便的方法就是使用HTablepool了，維持一個線程安全的map裡面存放的是tablename和其引用的映射，可以認為是一個簡單的計數器，當需要new 一個HTable實例時直接從該pool中取，用完放回。
3.HBase有沒有併發問題？
針對HBase在高併發情況下的性能，我們進行如下測試：
測試版本：hbase 0.94.1、 hadoop 1.0.2、 jdk-6u32-linux-x64.bin、snappy-1.0.5.tar.gz
測試hbase搭建：14台存儲機器+2台master、DataNode和regionserver放在一起。
測試一：高併發讀(4w+/s) + 少量寫(允許分拆、負載均衡)
癥狀：1-2天後，hbase掛掉(系統性能極差，不到正常的10%)。其實並非全部掛掉，而是某些regionserver掛了，併在幾個小時內引發其他regionserver掛掉。系統無法恢復：單獨啟regionserver無法恢復正常。重啟後正常。
測試二：高併發讀(4w+/s)
癥狀：1-2天後，hbase掛掉(系統性能極差，不到正常的10%)。後發現是由於zookeeper.session.timeout設置不正確導致(參見regionserver部分：http://hbase.apache.org/book.html#trouble)。重啟後正常。
測試三：高併發讀(4w+/s)
癥狀：1-2天後，hbase掛掉(系統性能極差，不到正常的10%)。從log未看出問題，但regionserver宕機，且datanode也宕機。重啟後正常。
測試四：高併發讀(4w+/s)+禁止分拆、禁止majorcompaction、禁止負載均衡(balance_switch命令)癥狀：1-2天後，hbase掛掉(系統性能極差，不到正常的10%)。從log未看出問題，但regionserver宕機，且datanode也宕機。重啟後正常。
測試期間，還發現過：無法獲取".MATE."表的內容(想知道regionserver的分佈情況)、hbase無法正確停止、hbase無法正確啟動(日誌恢復失敗，文件錯誤，最終手動刪除日誌重啟)。
全部內容在[git](https://gitee.com/zjlalaforgit/interview)上,瞭解更多請點我頭像或到我的主頁去獲得，謝謝
