插曲：Kafka的集羣部署實踐及運維相關

前言

上一篇 Kafka 的文章 --- 插曲：大白話帶你認識Kafka 中咱們應該已經瞭解了一些關於基礎角色和集羣架構相關的問題，這時候咱們應該很想了解一下如何構建生產中的Kafka集羣或者一些相關的運維工具，因此就應運而生了下文，配圖基本沒有，

1、Kafka的生產集羣部署

1.1 方案背景

假設天天集羣須要承載10億數據。一天24小時，晚上12點到凌晨8點幾乎沒多少數據。

使用二八法則估計，也就是80%的數據（8億）會在16個小時涌入，並且8億的80%的數據（6.4億）會在這16個小時的20%時間（3小時）涌入。

QPS計算公式：640000000 ÷ 36060 = 60000，也就是說高峯期的時候Kafka集羣要扛住每秒6萬的併發。

磁盤空間計算，天天10億數據，每條50kb，也就是46T的數據。保存2個副本（在上一篇中也提到過其實兩個副本會比較好，由於follower須要去leader那裏同步數據，同步數據的過程須要耗費網絡，並且須要磁盤空間，可是這個須要根據實際狀況考慮），46 * 2 = 92T，保留最近3天的數據。故須要 92 * 3 = 276T

1.2 QPS方面

部署Kafka，Hadoop，MySQL···等核心分佈式系統，通常建議直接採用物理機，拋棄使用一些低配置的虛擬機的想法。高併發這個東西，不多是說，你須要支撐6萬QPS，你的集羣就恰好把這6萬併發卡的死死的。加入某一天出一些活動讓數據量瘋狂上漲，那整個集羣就會垮掉。

可是，假如說你只要支撐6w QPS，單臺物理機自己就能扛住4~5萬的併發。因此這時2臺物理機絕對絕對夠了。可是這裏有一個問題，咱們一般是建議，公司預算充足，儘可能是讓高峯QPS控制在集羣能承載的總QPS的30%左右（也就是集羣的處理能力是高峯期的3~4倍這個樣子），因此咱們搭建的kafka集羣能承載的總QPS爲20萬~30萬纔是安全的。因此大致上來講，須要5~7臺物理機來部署，基本上就很安全了，每臺物理機要求吞吐量在每秒4~5萬條數據就能夠了，物理機的配置和性能也不須要特別高。

1.3 磁盤方面

1.3.1 磁盤數量

須要5臺物理機的狀況，須要存儲276T的數據，平均下來差很少一臺56T的數據。這個具體看磁盤數和盤的大小

1.3.2 SAS仍是SSD

如今咱們須要考慮一個問題：是須要SSD固態硬盤，仍是普通機械硬盤？

SSD就是固態硬盤，比機械硬盤要快，那麼究竟是快在哪裏呢？其實SSD的快主要是快在磁盤隨機讀寫，就要對磁盤上的隨機位置來讀寫的時候，SSD比機械硬盤要快。好比說MySQL這種就應該使用SSD了（MySQL須要隨機讀寫）。好比說咱們在規劃和部署線上系統的MySQL集羣的時候，通常來講必須用SSD，性能能夠提升不少，這樣MySQL能夠承載的併發請求量也會高不少，並且SQL語句執行的性能也會提升不少。

**由於寫磁盤的時候kafka是順序寫的。機械硬盤順序寫的性能機會跟內存讀寫的性能是差很少的，因此對於Kafka集羣來講其實使用機械硬盤就能夠了。**若是是須要本身創業或者是在公司成本不足的狀況下，經費是可以縮減就儘可能縮減的。

1.4 內存角度

JVM很是怕出現full gc的狀況。kafka自身的jvm是用不了過多堆內存的，由於kafka設計就是規避掉用jvm對象來保存數據，避免頻繁full gc致使的問題，因此通常kafka自身的jvm堆內存，分配個10G左右就夠了，剩下的內存所有留給os cache。

那服務器須要多少內存呢。咱們估算一下，大概有100個topic，因此要保證有100個topic的leader partition的數據在操做系統的內存裏。100個topic，一個topic有5個partition。那麼總共會有500個partition。每一個partition的大小是1G（在上一篇中的日誌分段存儲中規定了.log文件不能超過1個G），咱們有2個副本，也就是說要把100個topic的leader partition數據都駐留在內存裏須要1000G的內存。

咱們如今有5臺服務器，因此平均下來天天服務器須要200G的內存，可是其實partition的數據咱們不必全部的都要駐留在內存裏面，只須要25%的數據在內存就行，200G * 0.25 = 50G就能夠了（由於在集羣中的生產者和消費者幾乎也算是實時的，基本不會出現消息積壓太多的狀況）。因此一共須要60G（附帶上剛剛的10G Kafka服務）的內存，故咱們能夠挑選64G內存的服務器也行，大不了partition的數據再少一點在內存，固然若是可以提供128G內存那就更好。

1.5 CPU core

CPU規劃，主要是看你的這個進程裏會有多少個線程，線程主要是依託多核CPU來執行的，若是你的線程特別多，可是CPU核不多，就會致使你的CPU負載很高，會致使總體工做線程執行的效率不過高，上一篇的Kafka的網絡設計中講過Kafka的Broker的模型。acceptor線程負責去接入客戶端的鏈接請求，可是他接入了以後其實就會把鏈接分配給多個processor，默認是3個，可是通常生產環境建議你們仍是多加幾個，總體能夠提高kafka的吞吐量好比說你能夠增長到6個，或者是9個。另外就是負責處理請求的線程，是一個線程池，默認是8個線程，在生產集羣裏，建議你們能夠把這塊的線程數量稍微多加個2倍~3倍，其實都正常，好比說搞個16個工做線程，24個工做線程。

後臺會有不少的其餘的一些線程，好比說按期清理7天前數據的線程，Controller負責感知和管控整個集羣的線程，副本同步拉取數據的線程，這樣算下來每一個broker起碼會有上百個線程。根據經驗4個cpu core，通常來講幾十個線程，在高峯期CPU幾乎都快打滿了。8個cpu core，也就可以比較寬裕的支撐幾十個線程繁忙的工做。因此Kafka的服務器通常是建議16核，基本上能夠hold住一兩百線程的工做。固然若是能夠給到32 cpu core那就最好不過了。

1.6 網卡

如今的網基本就是千兆網卡（1GB / s），還有萬兆網卡（10GB / s）。kafka集羣之間，broker和broker之間是會作數據同步的，由於leader要同步數據到follower上去，他們是在不一樣的broker機器上的，broker機器之間會進行頻繁的數據同步，傳輸大量的數據。那每秒兩臺broker機器之間大概會傳輸多大的數據量？

高峯期每秒大概會涌入6萬條數據，約天天處理10000個請求，每一個請求50kb，故每秒約進來488M數據，咱們還有副本同步數據，故高峯期的時候須要488M * 2 = 976M/s的網絡帶寬，因此在高峯期的時候，使用千兆帶寬，網絡仍是很是有壓力的。

綜上描述

10億數據，6w/s的吞吐量，276T的數據，5臺物理機
硬盤：11（SAS） * 7T，7200轉
內存：64GB/128GB，JVM分配10G，剩餘的給os cache
CPU：16核/32核
網絡：千兆網卡，萬兆更好
複製代碼

2、Kafka的集羣搭建

進到Kafka的config文件夾下，會發現有不少不少的配置文件，但是都不須要你來修改，你僅僅須要點開一個叫做server.properties的文件就夠了。

【broker.id】
每一個broker都必須本身設置的一個惟一id，能夠在0~255之間

【log.dirs】
這個極爲重要，kafka的全部數據就是寫入這個目錄下的磁盤文件中的，若是說機器上有多塊物理硬盤，那麼能夠把多個目錄掛載到不一樣的物理硬盤上，而後這裏能夠設置多個目錄，這樣kafka能夠數據分散到多塊物理硬盤，多個硬盤的磁頭能夠並行寫，這樣能夠提高吞吐量。ps：多個目錄用英文逗號分隔

【zookeeper.connect】
鏈接kafka底層的zookeeper集羣的

【Listeners】
broker監聽客戶端發起請求的端口號，默認是9092

【num.network.threads】默認值爲3
【num.io.threads】默認值爲8
細心的朋友們應該已經發現了，這就是上一篇咱們在網絡架構上提到的processor和處理線程池的線程數目。
因此說掌握Kafka網絡架構顯得尤其重要。
如今你看到這兩個參數，就知道這就是Kafka集羣性能的關鍵參數了

【unclean.leader.election.enable】
默認是false，意思就是隻能選舉ISR列表裏的follower成爲新的leader，1.0版本後才設爲false，以前都是true，容許非ISR列表的follower選舉爲新的leader

【delete.topic.enable】
默認true，容許刪除topic

【log.retention.hours】
能夠設置一下，要保留數據多少個小時，這個就是底層的磁盤文件，默認保留7天的數據，根據本身的需求來就好了

【min.insync.replicas】
acks=-1（一條數據必須寫入ISR裏全部副本纔算成功），你寫一條數據只要寫入leader就算成功了，不須要等待同步到follower纔算寫成功。可是此時若是一個follower宕機了，你寫一條數據到leader以後，leader也宕機，會致使數據的丟失。
複製代碼

由於實際的集羣搭建說真的沒有太大難度，因此搭建的過程就不詳細展開了，網上應該不少相關資料

3、Kafka的簡單集羣操做

在操做Kafka集羣的時候，不一樣的Kafka版本命令的寫法是不同的，因此其實若是須要了解一下，推薦直接到官網去查看

上一篇時也有提到說Kafka在0.8版本之前存在比較大的問題，1.x的算是目前生產環境中使用較多的版本

在quickStart就能看到相關的命令，好比

① 建立主題

bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
將該命令修改一下

zookeeper localhost:2181 --replication-factor 2 --partitions 2 --topic tellYourDream
這時候就是zookeeper的地址爲localhost:2181
兩個分區，兩個副本，一共4個副本，topic名稱爲「tellYourDream」了
複製代碼

還得注意，通常來講設置分區數建議是節點的倍數，這是爲了讓服務節點分配均衡的舉措。

② 查看主題：

bin/kafka-topics.sh --list --zookeeper localhost:2181
複製代碼

③ 生產信息

bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
This is a message
This is another message
複製代碼

④ 消費信息

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning
This is a message
This is another message
複製代碼

這裏有個細節須要說起一下，就是咱們0.8版本的kafka找的是zookeeper，zookeeper上確實是也存在着元數據信息。

不過這存在着一些問題，zookeeper自己有一個過半服務的特性，這是一個限制，過半服務是指任何的請求都須要半數節點贊成才能執行。每次有寫請求，它都要投票，由於它要保持數據的強一致性，作到節點狀態同步，因此高併發寫的性能很差。不適合作高併發的事。zookeeper是Kafka存儲元數據和交換集羣信息的工具，主要是處理分佈式一致性的問題。

⑤ 集羣測試

下面的命令就是生產50W條數據，每條數據200字節，這條命令一運行就會產生一條報告，能夠很直觀的看到集羣性能，看不懂的狀況搜索引擎也能夠很好地幫助你解決問題

測試生產數據
bin/kafka-producer-perf-test.sh --topic test-topic --num-records 500000 --record-size 200 --throughput -1 --producer-props bootstrap.servers=hadoop03:9092,hadoop04:9092,hadoop05:9092 acks=-1
複製代碼

每次消費2000條，集羣沒跑掛那就穩妥了

測試消費數據
bin/kafka-consumer-perf-test.sh --broker-list hadoop03:9092,hadoop04:9092,hadoop53:9092 --fetch-size 2000 --messages 500000 --topic test-topic 
複製代碼

4、KafkaManager

KafkaManager使用scala寫的項目。安裝步驟能夠參考kafka集羣管理工具kafka-manager部署安裝，很是不錯。使用方法能夠經過搜索引擎查找。

安裝好了以後可使用jps命令查看一下，會多出一個名字叫作ProdServerStart的服務

功能介紹

1. 管理多個kafka集羣
2. 便捷的檢查kafka集羣狀態(topics,brokers,備份分佈狀況,分區分佈狀況)
3. 選擇你要運行的副本
4. 基於當前分區情況進行
5. 能夠選擇topic配置並建立topic(0.8.1.1和0.8.2的配置不一樣)
6. 刪除topic(只支持0.8.2以上的版本而且要在broker配置中設置delete.topic.enable=true)
7. Topic list會指明哪些topic被刪除（在0.8.2以上版本適用）
8. 爲已存在的topic增長分區
9. 爲已存在的topic更新配置
10. 在多個topic上批量重分區
11. 在多個topic上批量重分區(可選partition broker位置)
複製代碼

5、KafkaOffsetMonitor

KafkaOffsetMonitor就是一個jar包而已，是一個針對於消費者的工具。它能夠用於監控消費延遲的問題，不過對於重複消費和消息丟失等就沒法解決，由於以後若是須要講解SparkStreaming，flink這些用於消費者的實踐的話，會使用到這個工具，因此如今先不展開，瞭解一下便可

啓動命令：

java -cp KafkaOffsetMonitor-assembly-0.3.0-SNAPSHOT.jar \
 com.quantifind.kafka.offsetapp.OffsetGetterWeb \
 --offsetStorage kafka \
 --zk xx:2181,xx:2181,xx:2181/kafka_cluster \
 --port 8088 \
 --refresh 60.seconds \
 --retain 2.days
複製代碼

還有一些跨機房同步數據的像MirrorMaker這些，酌情使用。

finally

字數不少，仍是但願能夠耐心看完

以後會繼續展開生產者和消費者的原理，還有一些源碼的講述。而且也會總結一些關於kafka常常遇到的一些經典問題提供出來（其實就是面試相關啦），感興趣的朋友能夠持續關注。