【kafka】kafka部署 硬體考慮
前言
本文所寫的，偏重於架構師的內容，所以閱讀的小夥伴，要有綜合的一些能力，否則，你可能會被其中的計算給弄暈，不過既然，閱讀我的文章嘛，都是從基礎開始寫起，所以還是很好讀的。
本文要討論的話題是，當我搭建一個kafka叢集的時候，我們需要考慮的問題。
不能張口就來，我需要什麼什麼配置的機器之類的，那是耍流氓，我們要考慮的有理有據才可以對吧。
方案背景
假設我們要搭建一個每天要承載10億資料的kafka叢集。一天24小時，晚上12點到凌晨8點幾乎沒多少資料，使用二八法則估計，也就是80%的資料（8億）會在16個小時湧入，而且8億的80%的資料（6.4億）會在這16個小時的20%時間（3小時）湧入。QPS計算公式=640000000÷(3_60_60)=6萬，也就是說高峰期的時候，咱們的kafka叢集要扛住眉每妙6萬的併發。
磁碟空間計算，每天10億資料，每條50kb，也就是46T的資料，儲存2副本，462=92T，保留最近三天的資料，故需要923=276T
QPS角度
部署kafka，Hadoop，mysql，大資料核心分散式系統，一般建議大家直接採用物理機，不建議用一些低配置的虛擬機器，QPS這個東西，不能說你只要6萬QPS，你的叢集就剛好支撐6萬QPS就可以了，加入說你只要支撐6WQPS，2臺物理機絕對夠了，單臺物理機部署kafka支撐個幾萬QPS是沒問題的，但是，儘量讓高峰QPS控制在叢集能承載的總QPS的39% 左右，也就是總QPS為20萬～30萬才是安全的，所以大體上來說，需要5到7臺物理機，每臺要求在每妙幾萬條資料就可以了。
磁碟角度
磁碟數量，我們現在需要5臺物理機，需要存貯276T的資料，所以大概需要每臺存貯60T的資料，公司配置一般是11塊盤，這樣的話，一個盤7T就搞定了。
SAS盤還是SSD盤
我們都知道ssd盤比sas盤要塊，但是他快的是隨機讀寫能力，那kafka呢？kafka是順序寫入的，所以這個時候，ssd盤的作用就不是很大，所以，我們是可以採用sas盤的，也就是機械硬碟的，當然了，能用ssd盤更好。
記憶體角度
前提預知條件，kafka寫入資料是先寫到快取中，也就是os cache中，然後再寫入磁碟中。
kafka自身的jvm是用不了過多的對記憶體的，因為kafaka設計就是規避掉用jvm物件來儲存資料，避免頻繁fullgc導致的問題，所以一般kafka自身的jvm堆記憶體，分配個10G左右就夠了，剩下的記憶體全部都留給os cache。
那麼伺服器需要多少記憶體呢？我們估算一下，大概有100個topic，所以要保證有100個topic的leader partition的資料在os cache，按照一個topic有5個分割槽，總共有500個partition，每個partition的大小是1個G，按照兩個副本，也就是1千G，如果都要駐留在記憶體中的話，需要1000G的記憶體，現在有5臺伺服器，每個平均分一下，就是200G，當然了，並不是所有的資料都需要留在記憶體，所以按照25% 的計算就行了，也就是我們需要50G的記憶體，然後再留給jvm為10G，比較接近的，我們可以選擇64G的記憶體伺服器就可以了，當然了，記憶體肯定是越大也好，比如我們選擇128G的。
cpu角度
cup的規劃，主要是看你的執行緒有多少個執行緒。
所以到這裡，我們來插播一個關於kafka的網路傳輸過程。
這個圖片字型看起來比較小，但是你可以把它下載下來看，主要說一下他的過程，這個過程是kafka及其核心的過程。
首先客戶端有500個消費者，200個生產者，那麼他首先會將這些請求傳送給Acceptor,然後acceptor，這些請求叫socketchannel，然後這些socketchannel就會被髮送給processor，預設情況下，有三個proccessor，然後這些proccessor就會將請求傳送給request佇列，這個時候後面預設有8個執行緒池來請求這些request佇列裡面的內容，這些執行緒池就會用零拷貝的方式直接寫入到磁碟中，當然了，零拷貝本身也實現寫入os cache，然後，執行緒池處理完畢，就會發送給reponse佇列，告訴客戶端寫入成功了，當然了，這個成功，我們再寫程式碼的時候會有三種配置，後面我會寫通過程式碼的方式配置的文章的時候會提到這個引數配置的。
那麼我們在搭建kafka叢集的時候，會關注這樣兩個引數，分別為
# The number of threads that the server uses for receiving requests from the network and sending responses to the network
num.network.threads=3
# The number of threads that the server uses for processing requests, which may include disk I/O
num.io.threads=8
num.network,threads=3這個引數就是processor，
num.io.threads=8，這個就是執行緒池。
我們在搭建叢集的時候，建議將它擴大，比如num.network.threads這個可以搞成6個或者9個，num.io.threads=8這個我們可以將它搞成24個，或者32個，這樣子，執行緒一下就可以增大很多倍。
有了這個知識之後，我們就可以來具體的說cpu了。
我們來算一算這個執行緒數，首先會有9*32=288，在加上定期定期清理7天前資料的執行緒，加起來有幾百個了，這樣子，根據經驗4個Cpu core，一般來說支援個10幾個執行緒的話，在高峰期是完全打滿了，所以我們選擇8個cpu core，這樣子就比較寬裕支援個幾十個執行緒繁忙的工作，所以，我們採用16核的，當然了，採用32 cpu core更好了。
網絡卡角度
現在的網基本上就是千兆ka，還有萬兆網絡卡，kafka叢集之間，broker和broker之間是會做資料同步的，因為leader要同步資料到follwer上面去，所以不同伺服器之間的傳輸比較頻繁，根據之前測算的qps計算，每妙有6萬，按照每天請求處理1000個請求，每個請求50kb，大概是488M，當然了，我們還有副本，所以要有兩倍，於是大概是就是976M/s的網路頻寬。於是如果在高峰期的話，採用千兆網路，就會有壓力的。
於是經過上面的分析，我們大概得出結論。
配置總結
5臺物理機
硬碟：11 （sas） * 7T，7200轉
記憶體：64G/128G，jvm分配10G，剩餘的給os cache
cpu：16核/32核
網路：千兆網路/萬兆網路