HSVS 第3周-內網集群版推送

順序第3周，其實是第6周了。

申請過的用戶已經通過申請郵箱郵件推送

HSVS 內網版部署指南

定義

hcap: hsvs HTTP流還原模塊，使用Docker方式安裝部署

hsvs-mbridge: hsvs 預處理模塊，使用Dockr方式安裝部署

ElasticSearch: 開源文檔存儲引擎https://www.elastic.co

kafka: 開源分散式消息隊列 http://kafka.apache.org

redis: 開源內存k/v資料庫 https://redis.io/

nsq: golang開發的開源分散式消息隊列 https://nsq.io

部署方案

為了方便適配各種規模企業的使用場景，HSVS支持三種消息中間件redis/nsq/kafka。

kafka方案

優點: kafka吞吐率，穩定性，持久化很優秀，經過長期實踐檢驗，kafka可以多group消費者同時消費一topic數據，方便自定義開發分析程序

nsq方案

優點: nsq是一個golang開發的消息中間件，部署簡單，使用也簡單，支持持久化，支持多group消費者消費同一topic數據。

缺點: nsq設計理念是本地agent，所以如果在鏡像流量的節點nsq消息兩會大幅大於其他端點，沒有實現想要的負載均衡。

redis方案

優點: 部署簡單，可以使用企業已有redis(目前不支持redis集群)

缺點: 目前hcap不支持寫入集群，redis不支持多group訂閱消費，無法自定義分析程序，且不支持持久化。

抓取過濾器規則

hcap支持按照域名和資源來進行過濾，只保留自己所需要的內容

使用kafka時 分區數hsvs-mbridge對應關係

kafka對生產者的個數沒有限制，HSVS使用輪訓隨機寫入多個分區 kafka對消費者的數量有限制，應當能夠被分區書目整除，負責會出現有的分區時鐘無法被消費的情況。 kafka分配分區時建議按照2的整數倍進行分配，建議從4開始，如果不夠，那麼分配8、16，消費者hsvs-mbridge 建議從2開始，如果不夠加到4.通常2Gbps下，4個hsvs-mbridge足夠應對。

怎麼查看處理性能是否足夠，是否需要擴容。系統搭建完畢後在kibana中可以看到沒跳抓取的內容。 沒條記錄里均含有三個時間rawtime和@timestamp，rawtime表示網卡抓取到數據的時刻，@timestamp表示hsvs-mbridge的處理時間。如果相隔距離越來越大，表明消費者處理能力不夠，需要增加。 另外查看每一個hsvs-mbridge的CPU佔用率也是重要的參考。

判斷kafka分區數目是否需要擴容，通過經驗值+帶寬估算，kafka主要的性能瓶頸是帶寬。 千兆網路環境下，kafka broker性能等於帶寬乘以broker所在物理機數量。 通常設計時，分區數量的性能應當在最大流量的兩倍。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！