避免hbase訪問熱點需求描述：
掃瞄（查詢）某個區間---》列用hbase多節點的資源，分布式掃瞄，加快速度==》 然後拼接到一起 如何打散資料 冠字型大小逆序，hash
並不一定資料連續就會造成熱點，這個是由資料訪問模式決定的。
ex:時間作為rowkey，但查詢經常按乙個時間段來查詢*****》 時間作為rowkey會造成時間差不多的在乙個region，這就會造成region server 壓力大，===》形成熱點
ex：不按照時間段查詢，簡單的全域性掃瞄，這個就不是熱點===》例如爬蟲的需求。
人民幣冠字型大小作為rowkey，是連續的 ，會造成熱點，所以要經過 hash打撒
爬蟲是hostid_pid_urlid 就希望他儲存到一塊去，方便掃瞄，不擔心熱點
why why why why~~
訪問次數少，但是連續讀（也就是排序）的需求強的，就要放在一起。
訪問次數多的，比如冠字型大小這種的，就得雜湊打撒~~~
在作了較多優化改進後發現仍有幾個worker比較慢，跟蹤那幾個慢的worker日誌發現讀hbase經常超時，找到超時的region server，從hmaster ui上觀察到這個server的讀寫請求數明顯是其它server的好幾倍。開始懷疑是資料有傾斜，有熱點region落到了這台機器上。在hbase ui上逐個檢查pora2用到的hbase表，果然在其中的一張表上發現它的第乙個region的請求數比其它region高出一兩個數量級。
按我們的設計預期，這個表的rowkey是加了hash字首的，理論上不該有熱點region，最終檢查**後才發現是生成rowkey的**存在 bug，生成字首的**用了 key.hashcode() % regionnum，結果有很多key的hashcode返回是負數，使得很多字首是負數，全都落在了第乙個region上。
而對hbase來說，一旦有乙個region有熱點，就會導致該region所在的region server變慢，進而使得這個server上其它表的region訪問也慢，從而影響了整個hbase的效能。
Hbase熱點問題
當處理由連續事件得到的資料時，即時間上連續的資料。這些資料可能來自於某個感測器網路 交易或者乙個監控系統。它們顯著的特點就是rowkey中含有事件發生時間。帶來的乙個問題便是hbase對於row的不均衡分布，它們被儲存在乙個唯一的rowkey區間中，被稱為region，區間的範圍被稱為start k...
Hbase rowkey熱點問題
當處理由連續事件得到的資料時，即時間上連續的資料。這些資料可能來自於某個感測器網路 交易或者乙個監控系統。它們顯著的特點就是 rowkey 中含有事件發生時間。帶來的乙個問題便是 hbase 對於row 的不均衡分布，它們被儲存在乙個唯一的 rowkey 區間中，被稱為 region 區間的範圍被稱...
redis熱點問題
請求分片集中，超過單 server 的效能極限。在服務端讀資料進行訪問時，往往會對資料進行分片切分，此過程中會在某一主機 server 上對相應的 key 進行訪問，當訪問超過 server 極限時，就會導致熱點 key 問題的產生。需要避免失效那一刻大量請求同時去重新構建快取。因為重新構建快取，需...