上一篇 Kafka 的文章《大白話帶你認識Kafka》中咱們應該已經瞭解了一些關於基礎角色和集羣架構相關的問題，這時候咱們應該很想了解一下如何構建生產中的Kafka集羣或者一些相關的運維工具，因此就應運而生了下文。php
Kafka的生產集羣部署html
方案背景java
假設天天集羣須要承載10億數據。一天24小時，晚上12點到凌晨8點幾乎沒多少數據。bootstrap
使用二八法則估計，也就是80%的數據（8億）會在16個小時涌入，並且8億的80%的數據（6.4億）會在這16個小時的20%時間（3小時）涌入。安全
QPS計算公式：640000000 ÷ (3x60x60) = 60000，也就是說高峯期的時候Kafka集羣要扛住每秒6萬的併發。服務器
磁盤空間計算，天天10億數據，每條50kb，也就是46T的數據。保存2個副本（在上一篇中也提到過其實兩個副本會比較好，由於follower須要去leader那裏同步數據，同步數據的過程須要耗費網絡，並且須要磁盤空間，可是這個須要根據實際狀況考慮），46 * 2 = 92T，保留最近3天的數據。故須要 92 * 3 = 276T。網絡
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萬條數據就能夠了，物理機的配置和性能也不須要特別高。app
磁盤方面
磁盤數量
須要5臺物理機的狀況，須要存儲276T的數據，平均下來差很少一臺56T的數據。這個具體看磁盤數和盤的大小。
SAS仍是SSD
如今咱們須要考慮一個問題：是須要SSD固態硬盤，仍是普通機械硬盤？
SSD就是固態硬盤，比機械硬盤要快，那麼究竟是快在哪裏呢？其實SSD的快主要是快在磁盤隨機讀寫，就要對磁盤上的隨機位置來讀寫的時候，SSD比機械硬盤要快。好比說MySQL這種就應該使用SSD了（MySQL須要隨機讀寫）。好比說咱們在規劃和部署線上系統的MySQL集羣的時候，通常來講必須用SSD，性能能夠提升不少，這樣MySQL能夠承載的併發請求量也會高不少，並且SQL語句執行的性能也會提升不少。
由於寫磁盤的時候Kafka是順序寫的。機械硬盤順序寫的性能機會跟內存讀寫的性能是差很少的，因此對於Kafka集羣來講其實使用機械硬盤就能夠了。若是是須要本身創業或者是在公司成本不足的狀況下，經費是可以縮減就儘可能縮減的。
內存角度
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內存那就更好。
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那就最好不過了。
網卡
如今的網基本就是千兆網卡（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核 網絡：千兆網卡，萬兆更好
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也宕機，會致使數據的丟失。
由於實際的集羣搭建說真的沒有太大難度，因此搭建的過程就不詳細展開了，網上應該不少相關資料。
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
KafkaManager
KafkaManager使用scala寫的項目。安裝步驟能夠參考：https://www.cnblogs.com/dadonggg/p/8205302.html，很是不錯。使用方法能夠經過搜索引擎查找。
安裝好了以後可使用jps命令查看一下，會多出一個名字叫作ProdServerStart的服務。
功能介紹：
管理多個Kafka集羣
便捷的檢查Kafka集羣狀態（topics，brokers，備份分佈狀況，分區分佈狀況）
選擇你要運行的副本
基於當前分區情況進行
能夠選擇topic配置並建立topic（0.8.1.1和0.8.2的配置不一樣）
刪除topic（只支持0.8.2以上的版本而且要在broker配置中設置delete.topic.enable=true）
Topic list會指明哪些topic被刪除（在0.8.2以上版本適用）
爲已存在的topic增長分區
爲已存在的topic更新配置
在多個topic上批量重分區
在多個topic上批量重分區（可選partition broker位置）
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這些，酌情使用。
文章來源：https://juejin.im/post/6844904001989771278
Kubernetes管理員認證（CKA）培訓
本次CKA培訓將於11月20到22日在北京開課，培訓基於最新考綱，經過線下授課、考題解讀、模擬演練等方式，幫助學員快速掌握Kubernetes的理論知識和專業技能，並針對考試作特別強化訓練，讓學員能從容面對CKA認證考試，使學員既能掌握Kubernetes相關知識，又能經過CKA認證考試，學員可屢次參加培訓，直到經過認證。點擊下方圖片或者閱讀原文連接查看詳情。