kakfa
前言
因為遷移了kafka集群，為了確保新環境正常，需要來做一些壓力測試。這次壓力測試重點會關注一些異常情況下，kafka收發消息的狀況。
關於kafka集群的安裝可參考上一篇文章。
kafka可能故障及結論
部分broker集群掛掉
若topic創建的時候設置了replication，那么一般來說，掛掉n-1 個節點都是沒關系的。掛掉的broker對原來的消息收發幾乎不產生任何影響。具體模擬步驟見本文kafka故障模擬。
整個broker集群掛掉
如果整個集群都連接不上了，肯定是避免不了丟消息。重發次數到了設定的值，或者發送請求超時了都會導致生產者丟棄該條消息，發送下一條消息。重試次數增多、發送請求超時設定長點可以減少“丟失”，但是只是相對的，實際上生產者到達超時時間或者重發次數之后還是會丟棄消息。若集群能夠快速恢復，那么重試次數增多，發送請求超時時間增加是有意義的，可以相對使得生產者丟失的消息數目少一些。
磁盤故障
磁盤空間滿，磁盤無法寫入都可以划分為磁盤故障。磁盤空間滿，刪除策略與設置中的kafka刪除策略有關系，不在本文的研究范圍，下一篇文章會專門研究刪除策略。
當某個broker上的磁盤發生故障時，分區leader在該broker上的分區都無法進行訪問，broker server進程被阻塞。在磁盤故障沒有被修復之前，整個kafka集群是不可用的。如果磁盤上的數據能及時恢復，並且磁盤重新進行工作的話，出現磁盤故障的broker就能夠重新恢復服務。生產環境，需要做好監控，如果某個broker由於磁盤故障而不能服務，需要盡快下線該broker，觸發分區復制，確保整個集群可用。
kafka壓測過程
流量壓測
使用kafka自帶腳本進行壓測，生產數據腳本是kafka-producer-perf-test.sh，消費數據腳本是：kafka-consumer-perf-test.sh。模擬大量的生產消費，看看在突發的大量數據的收發壓力下，生產和消費是否會受影響。
生產者發送數據使用命令：kafka-producer-perf-test.sh ，命令具體為：
$ sh kafka-producer-perf-test.sh --topic kafka2-test --num-records 20000000 --record-size 1024 --throughput 500000 --producer-props bootstrap.servers=xxxx:9092
--topic topic名稱
--num-records 總共需要發送的消息數
--record-size 每個記錄的字節數
--throughput 每秒鍾發送的記錄數
--producer-props bootstrap.servers=localhost:9092
消費者接受數據使用命令：kafka-consumer-perf-test.sh：
sh kafka-consumer-perf-test.sh --broker-list=xxx:9092 --topic kafka2-test --show-detailed-stats --group kafka2-test-group --messages 20000000 --fetch-size 10000
--broker-list 指定kafka的鏈接信息
--topic 指定topic的名稱
--fetch-size 指定每次fetch的數據的大小
--messages 總共要消費的消息個數
開啟兩個生產者，每個生產者生產2億條消息，開始3個消費者，每個消費者消費2億條消息。
實驗結果：
生產者延遲：平均380ms,過程中生產消費都沒有報錯，服務器負載正常。
20000000 records sent, 80025.928401 records/sec (78.15 MB/sec), 381.76 ms avg latency, 6178.00 ms max latency, 349 ms 50th, 1122 ms 95th, 2031 ms 99th, 3209 ms 99.9th.
20000000 records sent, 80953.306133 records/sec (79.06 MB/sec), 377.17 ms avg latency, 6259.00 ms max latency, 283 ms 50th, 1449 ms 95th, 3402 ms 99th, 6028 ms 99.9th.
恢復測試
本次測試kafka為5節點，kafka2-test副本數為3個，按照邏輯來講壞掉兩個broker是不影響集群及數據的。
實驗過程：
按照流量測試步驟，進行消息收發，過程中下線broker，觀察是否有延遲變化、是否發生錯誤或者異常。
實驗結果：
下線broker之后，該broker上面的leader分區無法訪問，生產者開始刷出大量報錯，約2分鍾之后，所有生產者均開始重新恢復發送。消費者吞吐量開始降低后來恢復，啟動kafka節點，整個集群可以馬上恢復。
生產者延遲有所增加，延遲在570ms。
20000000 records sent, 54047.334656 records/sec (52.78 MB/sec), 565.70 ms avg latency, 39974.00 ms max latency, 782 ms 50th, 1363 ms 95th, 2384 ms 99th, 4039 ms 99.9th.
20000000 records sent, 52023.858141 records/sec (50.80 MB/sec), 588.22 ms avg latency, 39985.00 ms max latency, 48 ms 50th, 1178 ms 95th, 3483 ms 99th, 5302 ms 99.9th.
kafka集群皆為12c24g機器，2T ssd磁盤，壓測過程中CPU約在30%-40%，系統負載在3-4。
結論
此次壓測結果符合預期，生產已經對kafka完成切換，流量也已經切換到此kafka集群。
kafka作為分布式的消息系統，在集群可用性上還是做得比較完善的。在副本數充足的情況下發生節點故障，只會對生產和消費的速率產生一些影響，總體系統仍然是可用的。
壓測瓶頸基本在網絡帶寬，只要帶寬夠用，那么kafka吞吐量是基本不用考慮了，只需要優化生產消費端就可以了。
本文如果有不對的地方，歡迎大家批評指正，共同學習。