kafka真實環境部署規劃（轉載）

kafka真實環境部署規劃

1. 操做系統選型

由於kafka服務端代碼是Scala語言開發的，所以屬於JVM系的大數據框架，目前部署最多的3類操做系統主要由Linux ，OS X 和Windows,可是部署在Linux數量最多，爲何呢？由於I/O模型的使用和數據網絡傳輸效率兩點。

• 第一：Kafka新版本的Clients在設計底層網絡庫時採用了Java的Select模型，而在Linux實現機制是epoll,感興趣的讀者能夠查詢一下epoll和select的區別，明確一點就是：kafka跑在Linux上效率更高，由於epoll取消了輪詢機制，換成了回調機制，當底層鏈接socket數較多時，能夠避免CPU的時間浪費。
• 第二：網絡傳輸效率上。kafka須要經過網絡和磁盤進行數據傳輸，而大部分操做系統都是經過Java的FileChannel.transferTo方法實現，而Linux操做系統則會調用sendFile系統調用，也即零拷貝（Zero Copy 技術），避免了數據在內核地址空間和用戶程序空間進行重複拷貝。

2. 磁盤類型規劃

• 機械磁盤（HDD） 通常機械磁盤尋道時間是毫秒級的，如有大量隨機I/O，則將會出現指數級的延遲，可是kafka是順序讀寫的，所以對於機械磁盤的性能也是不弱的，因此，基於成本問題能夠考慮。
• 固態硬盤（SSD） 讀寫速度可觀，沒有成本問題能夠考慮。
• JBOD (Just Bunch Of Disks ) 經濟實惠的方案，對數據安全級別不是很是很是高的狀況下能夠採用，建議用戶在Broker服務器上設置多個日誌路徑，每一個路徑掛載在不一樣磁盤上，能夠極大提高併發的日誌寫入速度。
• RAID 磁盤陣列 常見的RAID是RAID10，或者稱爲（RAID 1+0） 這種磁盤陣列結合了磁盤鏡像和磁盤帶化技術來保護數據，由於使用了磁盤鏡像技術，使用率只有50%，注意，LinkedIn公司採用的就是RAID做爲存儲來提供服務的。那麼弊端在什麼地方呢？若是Kafka副本數量設置爲3，那麼實際上數據將存在6倍的冗餘數據，利用率實在過低。所以，LinkedIn正在計劃更改方案爲JBOD.

3. 磁盤容量規劃

咱們公司物聯網平臺天天大約可以產生一億條消息，假設副本replica設置爲2 （其實咱們設置爲3），數據留存時間爲1周，平均每條上報事件消息爲1K左右，那麼天天產生的消息總量爲：1億 乘 2 乘 1K 除以 1000 除以 1000 =200G磁盤。預留10%的磁盤空間，爲210G。一週大約爲1.5T。採用壓縮，平均壓縮比爲0.5，總體磁盤容量爲0.75T。 關聯因素主要有：

• 新增消息數
• 副本數
• 是否啓用壓縮
• 消息大小
• 消息保留時間

4. 內存容量規劃

kafka對於內存的使用，並不過多依賴JVM 內存,而是更多的依賴操做系統的頁緩存，consumer若命中頁緩存，則不用消耗物理I/O操做。通常狀況下，java堆內存的使用屬於朝生夕滅的，很快會被GC,通常狀況下，不會超過6G，對於16G內存的機器，文件系統page cache 能夠達到10-14GB。

• 怎麼設計page cache，能夠設置爲單個日誌段文件大小，若日誌段爲10G,那麼頁緩存應該至少設計爲10G以上。
• 堆內存最好不要超過6G。

5. CPU選擇規劃

kafka不屬於計算密集型系統，所以CPU核數夠多就能夠，而沒必要追求時鐘頻率，所以核數選擇最好大於8。

6. 網絡帶寬決定Broker數量

帶寬主要有1Gb/s 和10 Gb/s 。咱們能夠稱爲千兆位網絡和萬兆位網絡。舉例以下： 咱們的物聯網系統一天每小時都要處理1Tb的數據，咱們選擇1Gb/b帶寬，那麼須要選擇多少機器呢？

• 假設網絡帶寬kafka專用，且分配給kafka服務器70%帶寬，那麼單臺Borker帶寬就是710Mb/s，可是萬一出現突發流量問題，很容易把網卡打滿，所以在下降1/3,也即240Mb/s。由於1小時處理1TTB數據，每秒須要處理292MB,1MB=8Mb，也就是2336Mb數據，那麼一小時處理1TB數據至少須要2336/240=10臺Broker數據。冗餘設計，最終能夠定爲20臺機器。

做者：凱新的技術社區
連接：https://juejin.im/post/5bd464...
來源：掘金
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

1. kafka生產者吞吐量測試指標

kafka-producer-perf-test :是kafka提供的測試Producer性能腳本，經過腳本，能夠計算出Producer在一段時間內的平均延時和吞吐量。

1.1 kafka-producer-perf-test

在kafka安裝目錄下面執行以下命令,生產環境中儘可能讓腳本運行較長的時間，纔會有意義：

bin/kafka-producer-perf-test.sh --topic test --num-records 500000 --record-size 200 --througthput -1 --producer-props bootstrap.servers=bd-master:9092,bd-slave1=9092,bd-slave3=9092 acks=1

1.2 測試結果分析以下：

500000 records sent ,41963 records/sec (8.00 MB/sec),2362.85 ms/avg latency ,3513.00 ms max latency ,2792ms 50h ,3144ms 95th ,3364 ms 99h,3503ms 99.9th

看到上面的結果確定蒙了，看我細細講來： kafka 的平均吞吐量是8.00 MB/sec ，即佔用64Mb/s左右的帶寬，平均每一秒發送41963條消息。平均延時爲2362.85 ms，最大延時爲3513.00 ms，95%的消息發送須要3144ms，99%的消息發送須要3364ms，99.9%的消息發送須要3503ms。

2. kafka消費者吞吐量指標說明：

2.1 kafka-consumer-perfs

咱們總共測試500萬條數據量 bin/kafka-consumer-perfs-test.sh --broker-list bd-master:9092,bd-slave1=9092,bd-slave3=9092 --message-size 200 --messages 500000 --topic test

2.2 獲得以下結果：

2018-10-28 9:39:02 95.4188 92.2313 500271 484289 看到上面的結果確定蒙了，看我細細講來： 該環境下，1s內總共消費了95.4188MB消息，吞吐量爲92.2313MB/s,也即736Mb/s。

做者：凱新的技術社區
連接：https://juejin.im/post/5bd50b...
來源：掘金
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

1. Producer核心工做流程

• Producer首先使用用戶主線程將待發送的消息封裝進一個ProducerRecord類實例中。
• 進行序列化後，發送給Partioner，由Partioner肯定目標分區後，發送到Producer程序中的一塊內存緩衝區中。
• Producer的另外一個工做線程（即Sender線程），則負責實時地從該緩衝區中提取出準備好的消息封裝到一個批次的內，統一發送給對應的broker中。

2. producer 主要參數設置

2.1 producer 參數acks 設置（無數據丟失）

在消息被認爲是「已提交」以前，producer須要leader確認的produce請求的應答數。該參數用於控制消息的持久性，目前提供了3個取值：

acks = 0: 表示produce請求當即返回，不須要等待leader的任何確認。這種方案有最高的吞吐率，可是不保證消息是否真的發送成功。

acks = -1: 表示分區leader必須等待消息被成功寫入到全部的ISR副本(同步副本)中才認爲produce請求成功。這種方案提供最高的消息持久性保證，可是理論上吞吐率也是最差的。

acks = 1: 表示leader副本必須應答此produce請求並寫入消息到本地日誌，以後produce請求被認爲成功。若是此時leader副本應答請求以後掛掉了，消息會丟失。這是個這種的方案，提供了不錯的持久性保證和吞吐。

商業環境推薦：

若是要較高的持久性要求以及無數據丟失的需求，設置acks = -1。其餘狀況下設置acks = 1

2.2 producer參數 buffer.memory 設置（吞吐量）

該參數用於指定Producer端用於緩存消息的緩衝區大小，單位爲字節，默認值爲：33554432合計爲32M。kafka採用的是異步發送的消息架構，prducer啓動時會首先建立一塊內存緩衝區用於保存待發送的消息，而後由一個專屬線程負責從緩衝區讀取消息進行真正的發送。

商業環境推薦：

• 消息持續發送過程當中，當緩衝區被填滿後，producer當即進入阻塞狀態直到空閒內存被釋放出來，這段時間不能超過max.blocks.ms設置的值，一旦超過，producer則會拋出TimeoutException 異常，由於Producer是線程安全的，若一直報TimeoutException，須要考慮調高buffer.memory 了。
• 用戶在使用多個線程共享kafka producer時，很容易把 buffer.memory 打滿。

2.3 producer參數 compression.type 設置（lZ4）

producer壓縮器，目前支持none（不壓縮），gzip，snappy和lz4。

商業環境推薦：

基於公司物聯網平臺，試驗過目前lz4的效果最好。固然2016年8月，FaceBook開源了Ztandard。官網測試： Ztandard壓縮率爲2。8，snappy爲2.091，LZ4 爲2.101 。

2.4 producer參數 retries設置(注意消息亂序,EOS)

producer重試的次數設置。重試時producer會從新發送以前因爲瞬時緣由出現失敗的消息。瞬時失敗的緣由可能包括：元數據信息失效、副本數量不足、超時、位移越界或未知分區等。假若設置了retries > 0，那麼這些狀況下producer會嘗試重試。

商業環境推薦：

• producer還有個參數：max.in.flight.requests.per.connection。若是設置該參數大約1，那麼設置retries就有可能形成發送消息的亂序。
• 版本爲0.11.1.0的kafka已經支持"精確到一次的語義」，所以消息的重試不會形成消息的重複發送。

2.5 producer參數batch.size設置(吞吐量和延時性能)

producer都是按照batch進行發送的，所以batch大小的選擇對於producer性能相當重要。producer會把發往同一分區的多條消息封裝進一個batch中，當batch滿了後，producer纔會把消息發送出去。可是也不必定等到滿了，這和另一個參數linger.ms有關。默認值爲16K，合計爲16384.

商業環境推薦：

• batch 越小，producer的吞吐量越低，越大，吞吐量越大。

2.6 producer參數linger.ms設置(吞吐量和延時性能)

producer是按照batch進行發送的，可是還要看linger.ms的值，默認是0，表示不作停留。這種狀況下，可能有的batch中沒有包含足夠多的produce請求就被髮送出去了，形成了大量的小batch，給網絡IO帶來的極大的壓力。

商業環境推薦：

• 爲了減小了網絡IO，提高了總體的TPS。假設設置linger.ms=5，表示producer請求可能會延時5ms纔會被髮送。

2.7 producer參數max.in.flight.requests.per.connection設置(吞吐量和延時性能)

producer的IO線程在單個Socket鏈接上可以發送未應答produce請求的最大數量。增長此值應該能夠增長IO線程的吞吐量，從而總體上提高producer的性能。不過就像以前說的若是開啓了重試機制，那麼設置該參數大於1的話有可能形成消息的亂序。

商業環境推薦：

• 默認值5是一個比較好的起始點,若是發現producer的瓶頸在IO線程，同時各個broker端負載不高，那麼能夠嘗試適當增長該值.
• 過大增長該參數會形成producer的總體內存負擔，同時還可能形成沒必要要的鎖競爭反而會下降TPS

做者：凱新的技術社區
連接：https://juejin.im/post/5bd51b...
來源：掘金
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

調整partiton

調整partition能夠直接執行以下命令：

./kafka-topics.sh --alter --topic topicName --zookeeper $ZK_HOST_NODE --partitions partitionNum

注意替換topicName、$ZK_HOST_NODE和partitionNum三個參數。

調整replica factor

調整replica-factor須要先建立一個json描述文件replica.json，大體以下：

{
    "version": 1,
    "partitions": [
        {
            "topic": "topicName",
            "partition": 0,
            "replicas": [
,
 
            ]
        },
        {
            "topic": "topicName",
            "partition": 1,
            "replicas": [
,
 
            ]
        },
        {
            "topic": "topicName",
            "partition": 2,
            "replicas": [
,
 
            ]
        }
    ]
}

在描述文件中說明分區和副本所在broker的Id的映射。

然後在replica.json所在的位置執行以下命令：

$KAFKA_HOME/bin/kafka-reassign-partitions.sh --zookeeper $ZK_HOST_NODE  --reassignment-json-file replica.json --execute

另外，kafka-manager是個好東西，能夠直接在界面上完成partiton數目的調整。惋惜不能調整replica-factor。

轉載於:https://www.cnblogs.com/bigbe...