在開發中根據業務邏輯，需要儲存在storm中每個spout和bolt中產生的資料到hbase表中。在程式調優的過程中不斷調整和優化了幾種方案。
這是首先考慮和測試的選擇，也是最先放棄的選擇，短時多次建立連線會造成資源的浪費和排隊，儲存的時間的過長也會影響topology流的穩定性和實時性。
8.16補充：
後期實時性要求降低，hbase調優後效能提高，採用這種方法的穩定性大大提高，並通過生產環境的測試。
kafka的效能和訊息佇列的特性非常適合這種短時大吞吐量的應用場景，短時效能也能滿足需求。
但是！乙個topology中幾百個節點，每個節點乙個生產者，進而導致資源的巨大消耗甚至資源耗盡問題。
這個時候又想到了做快取的redis，這次嘗試了一下訂閱發布模式，在每個spout和bolt中發布資料，在topology末尾訂閱資料，channel能非常好滿足效能要求，而且接受的順序也有一定保證。
但是！開啟發布端到開啟訂閱端這段時間會丟資料，其他多種情況也會導致資料的丟失，資料的安全性根本沒***。
這也是最終的解決方案，採用redis list，在每個spout和bolt往每個佇列通過rpush往表尾放資料。在topology末尾傳送資料，lpop刪去並返回表頭，傳送失敗後通過lpush再把資料返回表頭。這樣也能保證資料的安全性，且經過測試滿足效能。
public void send(jedis jedis, string topic, string key) catch (exception e)
}}
外部程式採用spark streaming拉取程式，但因為元件過多，集群負載增加，最後選擇為備選方案
基於HBase做Storm 實時計算指標儲存
基於hbase做storm 實時計算指標儲存 舉個例子，假設我們有客戶 10w，計算指標假設 100 個，5 個 isp，30 個地域，這樣就有億級以上的 key 了，我們還要統計分鐘級別，小時級別，天級別，月級別。所以寫入量和儲存量都不小。如果採用 redis memcached 寫入速度是沒有問...
基於HBase做Storm 實時計算指標儲存
基於 hbase 做 storm 實時計算指標儲存 hbase 實時指標儲存是我入職樂視雲後對原有的實時系統改造的 hbase 儲存設計 storm 結果如何儲存到 hbase hbase 寫入效能優化 與傳統方案 redis mysql 對比 樂視雲內部用 storm 做 cdn，點播，直播流量的...
Storm 實時性分析
都說storm是乙個實時流處理系統，但storm的實時性體現在什麼方面呢？首先有乙個前提 這裡的實時性和我們通常所說的實時系統 晶元 彙編或c編寫的實時處理軟體 的實時性肯定是沒法比的，也不是同乙個概念。這裡的實時性應該是乙個相對的實時性 相對於hadoop之類 從網上找了一些資料 總結一下，sto...