influxDB叢集模式實踐

1. 傳統資料庫多用於記錄資料的當前值。

2. 時序資料庫記錄基於時間的一系列資料。

由時序產生，並且需要展現其歷史趨勢、週期規律、異常性的，進一步對未來做出預測分析的，都是時序資料庫適合的場景。具體場景：各類裝置的監控資料，醫學中的血糖、血壓、心率的監控資料，金融業中交易、成交資料等。

1. 開發者社群活躍，使用者眾多，開源時間較長。效能經過檢驗；

2. 類SQL的插入、查詢語言，不會增加太大的學習成本；

3. 原生HTTP介面支援各類語言呼叫；

4. 僅僅作為儲存方案，可插拔。

• TSM 儲存引擎主要由幾個部分組成：

• cache。在記憶體中是一個簡單的 map 結構預設配置檔案中為1g。

• wal。記錄內容和cache一樣，目的是為了持久化cache資料，influxdb啟動時會載入wal的資料到記憶體。

• tsm file。用於資料儲存。

• compactor。主要進行兩類操作：

1.    cache->snapshot->tsm；

2.    合併小tsm成為大的   tsm。

1. 按時間戳所在不同範圍建立不同Shard；

2. 根據時間可以快速定位要查詢的資料資源，加快查詢的過程；

3. 讓根據時間的批次刪除操作變得非常簡單且高效。

1. influxdb社群版預設並未提供叢集解決方案。

2. 官方開源的influxdb-relay僅僅支援雙寫功能，並未支援負載均衡能力。

3. 餓了麼開源的influx-proxy叢集方案元件眾多，安裝部署、後期維護成本高、複雜度大。

4. 360公司內部需求：提供十萬臺主機的兩百個監控項資料的實時出圖、訪問，基於這些監控項的告警以及故障預測。

5. 基於上述需求，於是有了influxDB-HA專案。

未解決的問題：

1.  採用雙寫僅僅解決了資料備份的問題，並未解決influxdb讀寫效能的問題；

2.  只是寫入了資料，查詢還是需要去讀influxdb。增加了配置檔案的複雜度不易維護；

3.  並未對寫入失敗的資料做任何重試機制的處理。

優勢：

1. influx-proxy是餓了麼在influxdb-relay滿足不了其效能要求、配置維護要求痛定思痛後重構的產物；

2. influxdb機器支援動態擴縮；

3. 增加了強大的請求失敗後的重試機制。

劣勢：

1. 架構中使用的元件較多，增加了使用者的學習成本，且不易於後期的維護；

2. 請求失敗重試本身是雙刃劍，試想機器效能達到極限，重試無形中又增加了機器的負載；

3. 與自身場景需求不相符，我們內部只是做監控資料的持久化儲存，應該是最簡單的接入和與influxdb最小的架構改造。

優勢：

1. 以measurement為最小拆分單元，從而保證以時序查詢influxdb的高效性。

2. 支援業務層動態的拆庫、拆表操作。

與單機influxdb 磁碟IO對比。

與單機influxdb CPU使用對比。

influxDB-HA管理influxdb例項配置。

Grafana接入influxDB-HA說明。

三方程式接入influxDB-HA寫入資料說明。

1. 完全相容influxdb原生的/write介面方式寫入，且支援原生查詢介面的所有引數；
   

2. 如果您說您以前習慣了使用influxdb的SDK方式寫入，那也恭喜您。influxDB-HA支援任何語言的influxdb SDK接入。

一個優秀的專案需要經歷無數的版本迭代和最佳化，而對於開發者而言，能相容各類需求、適應各類場景是沉澱、提升技術的不二法門。鑑於此，我們應該不斷完善influxDB-HA以支援360內部各類使用場景。接來下，僅提出未來可見的最佳化點：

1. 接入kafka、RabbitMQ做寫入請求之前的緩衝，降低資料丟失的風險；

2. influxDB-HA配置檔案的熱載入（目前已經透過golang的fsnotify庫實現，將來更大規模的influxDB-HA叢集應該透過etcd等外部的配置統一管理來實現）；

3. 對接業務方分表，以支援更大資料規模場景下的解決方案，measurement始終作為influxDB-HA叢集中可拆分的最小單元，避免不同measurement的合併排序問題。

經過一段時間（近一個多月）的實踐和對influxdb效能的綜合觀察，總結出以下結論供我們大家一起探討：

1、continuous queries/select：

筆者看見很多對於influxdb的不滿來自於對其效能的詬病。然而有目共睹的是其寫入效能是極其優秀的，那究竟查詢效能如何呢？

實踐總結：對於超過10萬樣本資料的查詢操作而言，我們透過索引（即influxdb中的tag）查詢將能夠節省機器效能，大大降低查詢時間。查詢操作往往耗當機器的根本原因是：OOM（Out Of Memory）

那麼在配置CQ時，應該：

• 儘可能使用tag；

• 應該拿寫好的CQ充分模擬線上環境的測試，證明效能沒問題後再上線。

2、retention policy：

配置資料的留存策略好處是資料持久化，但資料量較大時劣勢也非常明顯，會佔用很大的CPU，造成讀寫資料異常。所以配置RP時我們必須注意：

• 儘量在讀寫併發量較小的時刻去操作；

• 可以在influxdb slave庫中反覆設定RP實踐出最佳方式再上線。