背景

前段時間我們想實現 Pulsar 訊息的追蹤流程，追蹤實現的效果圖如下：

實現其實比較簡單，其中最重要的就是如何儲存訊息。

訊息的讀取我們是通過 Pulsar 自帶的 BrokerInterceptor 實現的，對這個感興趣的朋友後面會單獨做一個分享。

根據這裡的顯示內容我們大概需要儲存這些資訊：

都以兩個 consumer 計算：
一條訊息佔用記憶體：140+ 535*2 + 536*2 =2282byte
儲存三天：TPS * 86400 * 3=TPS*259200 條
總儲存：
2282*TPS*259200≈ 百GB

根據我們的 TPS 計算，三天的大概會使用到上百 G 的儲存，這樣首先就排除了 Redis 這種記憶體型資料庫。

同樣的換成 MySQL 儲存也不划算，因為其實這些資料並不算那麼重要。

做了幾個技術選型都不太滿意，不是資源開銷太大就是沒有相關的運維經驗。

後面在領導的提醒下，我們使用的 VictoriaMetrics 開源了一個 VictoriaLogs，雖然當時的版本還是 0.1.0，使用過他們家 Metrics 的應該都會比較信任他們的技術能力，所以就調研了一下。

簡單來說就是它也是一個紀錄檔儲存資料庫，並且有著極低的資源佔有率，相對於 ElasticSearch 來說記憶體、磁碟、CPU 都是幾十倍的下降率。

通過官方的壓測對比圖會發現確實在各方面對 ES 都是碾壓。

官方宣傳的第一反應是不能全信，於是我自己壓測了一下，果然 CPU 記憶體磁碟的佔用都是極低的。

同時也發現運維部署確實簡單，直接一個 helm install 就搞定，就是一個二進位制檔案，不會依賴第二個元件。

按照剛才同樣的資料儲存三天，只需要不到 6G 的磁碟空間，我們生產環境已經平穩執行一段時間了。

因為我們是批次寫入資料的，所以在最高峰 20K 的 TPS 下 CPU 使用不到 0.1 核，記憶體使用最高 120M，這點確實是對 ES 碾壓了。

磁碟佔用也是非常少。

這些有點得歸功於它有些的壓縮、編解碼演演算法，以及 Golang 帶來的相對於 Java 的極低資源佔用。

還存在的問題

如果一切都這麼完美的話那 VictoriaLogs 確實也太變態了，自然他也有一些不太完美的地方。

首先第一個是分詞功能有限，只能做簡單的搜尋，無法做到類似於 ES 的各種分詞，外掛當然也別想了。

當前版本不支援叢集部署，也就是無法橫向擴充套件了；不過幸好他的的單機效能已經非常強了。

這也是目前階段部署簡單的原因。

VictoriaLogs 支援為資料設定過期時間自動刪除，有點類似於 Redis，它會在後臺啟動一個協程定期判斷資料是否過期，但只能對所有資料統一設定。

比如我想在 VictoriaLogs 中存放兩種不同型別的資料，同時他們的過期刪除時間也不相同；比如一個是三天刪除，一個是三月後刪除。

這樣的需求目前是無法實現的，只能部署兩個 VictoriaLogs.

由於 VictoriaLogs 可以儲存非結構化資料，預設情況下只能查詢內建的三個欄位，我們自定義的欄位目前沒法自動查詢，需要我們手動指定。

這個倒不是致命問題，只是使用起來稍微麻煩一些；社群也有一些反饋，相信不久就會優化該功能。

這也是個有了更好的一個功能，目前只能根據 REST API 自己編寫。

當前我們只用來儲存 Pulsar 鏈路追蹤資料，目前看來非常穩定，各方面資源佔用極少；所以後續我們會陸續講一些紀錄檔型別的資料遷移過來，比如審計紀錄檔啥的。

之後再逐步完善功能後，甚至可以將所有應用存放在 ElasticSeach 中的紀錄檔也遷移過來，這樣確實能省下不少資源。

總得來說 VictoriaLogs 資源佔用極少，如果只是拿來儲存紀錄檔相關的資料，沒有很強的分詞需求那它將非常合適。

截止到目前最新版也才 0.3.0 還有很大的進步空間，有類似需求的可以持續關注。