前言
本文所寫的，偏重於架構師的內容，所以閱讀的小伙伴，要有綜合的一些能力，否則，你可能會被其中的計算給弄暈，不過既然，閱讀我的文章嘛，都是從基礎開始寫起，所以還是很好讀的。
本文要討論的話題是，當我搭建一個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核
網絡：千兆網路/萬兆網絡