背景

前段時間我們想實現(xiàn) Pulsar 消息的追蹤流程，追蹤實現(xiàn)的效果圖如下：

實現(xiàn)其實比較簡單，其中最重要的就是如何存儲消息。

消息的讀取我們是通過 Pulsar 自帶的 BrokerInterceptor 實現(xiàn)的，對這個感興趣的朋友后面會單獨做一個分享。

根據(jù)這里的顯示內(nèi)容我們大概需要存儲這些信息：

• 客戶端地址
• 消息發(fā)布時間
• 分發(fā)消費者、訂閱者名稱
• ACK 消費者、訂閱者名稱
• 消息 ID 最終捋了下：

圖片

都以兩個 consumer 計算：一條消息占用內(nèi)存：140+ 535*2 + 536*2 =2282byte存儲三天：TPS * 86400 * 3=TPS*259200 條總存儲：2282*TPS*259200≈ 百GB

根據(jù)我們的 TPS 計算，三天的大概會使用到 上百 G 的存儲，這樣首先就排除了 Redis 這種內(nèi)存型數(shù)據(jù)庫。

同樣的換成 MySQL 存儲也不劃算，因為其實這些數(shù)據(jù)并不算那么重要。

做了幾個技術(shù)選型都不太滿意，不是資源開銷太大就是沒有相關(guān)的運維經(jīng)驗。

后面在領(lǐng)導(dǎo)的提醒下，我們使用的 VictoriaMetrics 開源了一個 VictoriaLogs，雖然當時的版本還是 0.1.0，使用過他們家 Metrics 的應(yīng)該都會比較信任他們的技術(shù)能力，所以就調(diào)研了一下。

具體的信息可以查看官方文檔：https://docs.victoriametrics.com/VictoriaLogs/

圖片

簡單來說就是它也是一個日志存儲數(shù)據(jù)庫，并且有著極低的資源占有率，相對于 ElasticSearch 來說內(nèi)存、磁盤、CPU 都是幾十倍的下降率。

圖片

通過官方的壓測對比圖會發(fā)現(xiàn)確實在各方面對 ES 都是碾壓。

圖片

官方宣傳的第一反應(yīng)是不能全信，于是我自己壓測了一下，果然 CPU 內(nèi)存 磁盤的占用都是極低的。

同時也發(fā)現(xiàn)運維部署確實簡單，直接一個 helm install 就搞定，就是一個二進制文件，不會依賴第二個組件。

按照剛才同樣的數(shù)據(jù)存儲三天，只需要不到 6G 的磁盤空間，我們生產(chǎn)環(huán)境已經(jīng)平穩(wěn)運行一段時間了。

圖片

因為我們是批量寫入數(shù)據(jù)的，所以在最高峰 20K 的 TPS 下 CPU 使用不到 0.1 核，內(nèi)存使用最高 120M，這點確實是對 ES 碾壓了。

圖片

磁盤占用也是非常少。

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

還存在的問題

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

分詞功能有限

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

不支持集群

當前版本不支持集群部署，也就是無法橫向擴展了；不過幸好他的的單機性能已經(jīng)非常強了。

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

過期時間無法混用

VictoriaLogs 支持為數(shù)據(jù)配置過期時間自動刪除，有點類似于 Redis，它會在后臺啟動一個協(xié)程定期判斷數(shù)據(jù)是否過期，但只能對所有數(shù)據(jù)統(tǒng)一設(shè)置。

比如我想在 VictoriaLogs 中存放兩種不同類型的數(shù)據(jù)，同時他們的過期刪除時間也不相同；比如一個是三天刪除，一個是三月后刪除。

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

默認無法查詢所有字段

圖片

由于 VictoriaLogs  可以存儲非結(jié)構(gòu)化數(shù)據(jù)，默認情況下只能查詢內(nèi)置的三個字段，我們自定義的字段目前沒法自動查詢，需要我們手動指定。

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

圖片

圖片

• https://github.com/VictoriaMetrics/VictoriaMetrics/issues/4780
• https://github.com/VictoriaMetrics/VictoriaMetrics/issues/4513

沒有官方 SDK

圖片

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

總結(jié)

當前我們只用來存儲 Pulsar 鏈路追蹤數(shù)據(jù)，目前看來非常穩(wěn)定，各方面資源占用極少；所以后續(xù)我們會陸續(xù)講一些日志類型的數(shù)據(jù)遷移過來，比如審計日志啥的。

之后再逐步完善功能后，甚至可以將所有應(yīng)用存放在 ElasticSeach 中的日志也遷移過來，這樣確實能省下不少資源。

總得來說 VictoriaLogs  資源占用極少，如果只是拿來存儲日志相關(guān)的數(shù)據(jù)，沒有很強的分詞需求那它將非常合適。

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