下面我們來介紹下Kafka怎么調(diào)優(yōu)吞吐量相關(guān)的參數(shù)，首先我們需要確定當(dāng)我們想要調(diào)優(yōu)kafka的時(shí)候，我們需要從哪些方面開始呢，一般來說，我們需要從性能，可用性和持久性來做集群的調(diào)優(yōu)配置，下面就來解釋一下這幾個(gè)方面:
1.性能，主要包括吞吐量和延時(shí)
吞吐量:broker或client每秒能處理多少字節(jié)
延時(shí):通常指producer發(fā)送消息到broker端持久化保存消息之間的時(shí)間間隔，也可以指producer發(fā)送一條消息到consumer接受這條消息的時(shí)間間隔。
2.可用性
在某段時(shí)間內(nèi)，系統(tǒng)或組件正常運(yùn)行的概率或在時(shí)間上的比率。
3.持久性
確保了已提交操作所產(chǎn)生的效果會(huì)被永久地保持，即使系統(tǒng)出現(xiàn)崩潰。對于kafka來說，持久性通常意味著已提交的消息需要被持久化到broker底層的文件系統(tǒng)而不能發(fā)生丟失。
知道了需要從哪些方面做調(diào)優(yōu)之后，下面在來看看如何調(diào)優(yōu)kafka的吞吐量。首先就是確定broker端的分區(qū)數(shù)，我們知道，kafka的topic是被放到不同的partitiion，在producer端可以同時(shí)對多個(gè)分區(qū)發(fā)送消息，而這些消息也可以被寫入到多個(gè)broker中由多個(gè)consumer同時(shí)消費(fèi)。因此，如何設(shè)置分區(qū)數(shù)成為了調(diào)優(yōu)吞吐量的重點(diǎn)，下面給出一個(gè)基本公式，但是需要注意的是，具體情況需要具體分析，還是以實(shí)際生產(chǎn)環(huán)境數(shù)據(jù)為依據(jù)比較好，一般來說，可以先創(chuàng)建單分區(qū)的topic，然后在生產(chǎn)機(jī)器上分別測試producer和consumer的tps,分別為t1和t2,假設(shè)目標(biāo)tps為t3，那么分區(qū)數(shù)則可以確定為t3/max(t1,t2)。值得注意的是，在測試producer端tps通常是很容易的，因?yàn)檫壿嫳容^簡單，直接發(fā)送消息給broker即可，但測試consumer端tps時(shí)，應(yīng)該盡量使用真實(shí)的消息處理邏輯，這樣測試的結(jié)果才能準(zhǔn)確的反映線上環(huán)境的數(shù)據(jù)。
在確定了分區(qū)數(shù)后，我們將從producer，broker，consumer這3個(gè)方面來討論如何調(diào)優(yōu)tps的參數(shù)。
首先broker端：
應(yīng)該適當(dāng)增加num.replica.fetchers，這個(gè)參數(shù)代表了broker的follower replica從leader拉取消息的最大線程數(shù)，默認(rèn)值為1，表示follower raplica只使用一個(gè)線程從leader拉取消息。對于設(shè)置了asks=all的producer來說，主要延時(shí)可能都在follower與leader同步消息的過程，因此增加該值通常能夠減少同步消息的時(shí)間間隔，從而可以提高producer端的tps。所以需要設(shè)置該參數(shù)來保證更好的性能。
對于producer端：
1.應(yīng)當(dāng)適當(dāng)增加batch.size，比如說增加到100-512kb，我們知道，producer是批量發(fā)送消息的，它會(huì)將消息放到隊(duì)列中，然后在一個(gè)發(fā)送請求中統(tǒng)一發(fā)送消息。更大的batch.size可以使一個(gè)請求發(fā)送更多的消息，所以可以提高tps,還有另一個(gè)參數(shù)linger.ms，是等待發(fā)送消息的延時(shí)，提高linger.ms也會(huì)讓一個(gè)請求發(fā)送更多的消息，從而提高tps，當(dāng)然這樣就會(huì)降低延時(shí)，所以需要根據(jù)具體的情況選擇參數(shù)值。
2.可以設(shè)置消息壓縮，compression.type為kafka的消息壓縮類型，對消息進(jìn)行壓縮可以減少網(wǎng)絡(luò)傳輸量，從而提高tps。可以考慮設(shè)置消息壓縮來提高發(fā)送消息的效率。
3.acks設(shè)置為0或1，我們知道，當(dāng)producer發(fā)送消息給broker時(shí)，默認(rèn)情況下，producer會(huì)等待leader返回發(fā)送結(jié)果，這時(shí)才能知道這條消息是否發(fā)送成功，consumer端也只能消息那些已經(jīng)成功發(fā)送的消息。因此，調(diào)整acks參數(shù)是必要的，默認(rèn)值為1表示leader把消息寫入文件系統(tǒng)就返回，無需等待follower的ack。也可以將acks設(shè)置為0，則表示producer端不需要broker端返回結(jié)果就可以開始發(fā)送下一條消息。這種方式可以提高tps，但是會(huì)影響消息的持久化，因此需要根據(jù)實(shí)際情況去選擇。
4.當(dāng)acks不是0時(shí)，一旦消息發(fā)送失敗，producer會(huì)根據(jù)retries參數(shù)設(shè)置的值進(jìn)行重試。如果應(yīng)用可以忍受消息丟失，可以將retries設(shè)置為0，這樣就可以提高tps。但是需要注意的是，一旦消息發(fā)送失敗，producer將不會(huì)嘗試再次發(fā)送消息，應(yīng)用需要自己catch異常并處理異常信息。
5.當(dāng)分區(qū)數(shù)很多時(shí)，需要考慮增加buffer.memory參數(shù)。
對于consumer端：
1.可以考慮采用多consumer實(shí)例。使用多個(gè)consumer實(shí)例共同消費(fèi)分區(qū)的數(shù)據(jù)，能夠提高tps。最好是啟動(dòng)與消費(fèi)的分區(qū)數(shù)相同的實(shí)例數(shù)，以保證每個(gè)實(shí)例都能分配一個(gè)具體的分區(qū)進(jìn)行消費(fèi)。
2.可以增加fetch.min.bytes參數(shù)，對于consumer來說，用戶可以調(diào)整leader broker每次返回的最小數(shù)據(jù)量來影響tps,這就是fetch.min.bytes的作用，該參數(shù)控制了leader每次返回的最小字節(jié)數(shù)。通過增加該參數(shù)值，每次拉取消息的response會(huì)返回更多的數(shù)據(jù)，從而可以提高tp。當(dāng)然在提高tps的同時(shí)也會(huì)增加延時(shí)，因此需要根據(jù)實(shí)際的調(diào)優(yōu)目標(biāo)確定具體的參數(shù)值。
到這里，我們就介紹了kafka吞吐量相關(guān)的參數(shù)，kafka吞吐量相關(guān)的參數(shù)就介紹到這里了。