Kafka性能調優 - Kafka優化的方法

今天，咱們將討論Kafka Performance Tuning。在本文「Kafka性能調優」中，咱們將描述在設置集羣配置時須要注意的配置。此外，咱們將討論Tuning Kafka Producers，Tuning Kafka Consumers和Tuning Kafka Brokers。
那麼，讓咱們從Kafka Performance Tuning開始吧。

Kafka性能調優 - Kafka優化的方法

2. Kafka Performance Tuning是什麼？

在咱們討論Kafka性能調優時，須要考慮的配置參數不多。所以，爲了提升性能，最重要的配置是控制磁盤刷新率的配置。
此外，咱們能夠在組件的基礎上劃分這些配置。那麼，讓咱們首先談談製片人。所以，生產者方面須要注意的最重要的配置是 -

• 壓縮
• 批量大小
• 同步或異步

並且，在消費者方面，重要的配置是 -

• 獲取大小

雖然，當咱們考慮批量大小時，老是會混淆批量大小最佳。咱們能夠說，大批量可能很大，以得到高吞吐量，它帶來延遲問題。這意味着延遲和吞吐量彼此成反比。
可能具備低吞吐量和高吞吐量，咱們必須爲使用隊列時間或刷新間隔選擇合適的批量大小以找到所需的正確平衡。

Kafka性能調整圖

檢查你的卡夫卡表演 - 你站在哪裏

3.調整Kafka以得到最佳性能

更具體地說，調整涉及兩個重要指標：延遲測量和吞吐量測量。延遲度量意味着處理一個事件須要多長時間，相似地，在特定時間內有多少事件到達，這意味着吞吐量度量。所以，大多數系統都針對延遲或吞吐量進行了優化，而Apache Kafka則對二者進行了平衡。此外，咱們能夠說，一個通過良好調整的Kafka系統只有足夠的經紀人來處理主題吞吐量，由於在接收信息時須要處理信息所需的延遲。

一個。調整卡夫卡製片人

衆所周知，Kafka使用異步發佈/訂閱模型。當咱們的生產者調用send（）命令時，返回的結果是將來。將來提供了檢查過程當中信息狀態的方法。此外，當批處理準備就緒時，生產者將其發送給代理。基本上，代理等待事件，而後接收結果，並進一步響應事務完成。
對於延遲和吞吐量，兩個參數對於Kafka性能調優尤爲重要：
Apache Kafka用例| 卡夫卡應用程序

一世。批量大小

batch.size不是消息數，而是以總字節數來衡量批量大小。這意味着它在向Kafka代理髮送消息以前控制要收集的數據字節數。所以，在不超出可用內存的狀況下，將其設置爲儘量高。確保默認值爲16384. 
可是，若是咱們增長緩衝區的大小，它可能永遠不會滿。在其餘觸發器的基礎上，例如逗留時間（以毫秒爲單位），Producer最終會發送信息。雖然經過將緩衝區批處理大小設置得過高，但咱們可能會損害內存使用，這不會影響延遲。
並且，若是咱們的製做人一直在發送，咱們可能會得到最佳的吞吐量。此外，若是生產者常常閒置，咱們可能沒有編寫足夠的數據來保證當前的資源分配。

II。靈兒時間

爲了在異步模式下緩衝數據，linger.ms設置最大時間。讓咱們經過一個例子來理解它，一次設置100個批次100ms的消息。這裏，緩衝增長了消息傳遞延遲，但這提升了吞吐量。
閱讀Apache Kafka Streams | 流處理拓撲
可是，默認狀況下，生產者不會等待。所以，它會在數據可用時發送緩衝區。
此外，咱們能夠將linger.ms設置爲5並在一個批次中發送更多消息，而不是當即發送。這將爲發送的記錄增長5毫秒的延遲，但也會減小發送的請求數，即便系統上的負載不能保證延遲。
所以，爲了提升生產者的延遲和吞吐量，請增長linger.ms。

灣 調整卡夫卡經紀人

咱們知道，主題分爲幾個分區。此外，每一個分區都有一個領導者。此外，對於多個副本，大多數分區都寫入領導者。可是，若是領導者沒有獲得適當的平衡，那麼與其餘人相比，可能會有人過分勞累。
所以，基於咱們的系統或咱們的數據有多重要，咱們但願確保咱們有足夠的複製集來保存咱們的數據。建議從每一個物理存儲磁盤一個分區和每一個分區一個使用者開始。
閱讀Apache Kafka Workflow | Kafka Pub-Sub Messaging

C。調整卡夫卡消費者

基本上，Kafka消費者能夠建立吞吐量問題。主題的使用者數量必須等於分區數量。由於，爲了處理跟上生產者所需的全部消費者，咱們須要足夠的分區。
在同一個消費者羣體中，消費者將分區分開。所以，向組中添加更多消費者能夠提升性能，同時添加更多消費者組不會影響性能。
並且，咱們使用-replica.high.watermark.checkpoint.interval.ms的方式屬性，能夠影響吞吐量。此外，咱們能夠標記從分區讀取時讀取信息的最後一點。經過這種方式，若是咱們必須返回並找到丟失的數據，咱們有一個檢查點能夠向前移動而沒必要從新讀取先前的數據。所以，若是咱們爲每一個事件設置檢查點水印，咱們將永遠不會丟失消息，但它會顯着影響性能。此外，咱們有一個安全邊際，對吞吐量的影響要小得多，相反，咱們將其設置爲檢查每百條消息的偏移量。

4. Kafka Tuning中的生產服務器配置

根據集羣環境和機器配置的可用性，如下是咱們能夠修改的一些配置參數及其值 -

你知道重要的Kafka工具 - 在這裏學習

Kafka性能調優 - 生產服務器配置

一個。num.replica.fetchers

此參數定義將數據從leader複製到跟隨者的線程數。根據線程的可用性，咱們能夠修改此參數的值。若是咱們有可用的線程，那麼讓副本獲取器的數量並行完成複製是很重要的。

灣 replica.fetch.max.bytes

此參數是關於咱們想要從每一個獲取請求中的任何分區獲取多少數據。增長此參數的值是很好的，這有助於在關注者中快速建立副本。

C。replica.socket.receive.buffer.bytes

若是咱們有更少的線程可用於建立副本，咱們能夠增長緩衝區的大小。此外，若是複製線程與傳入消息速率相比較慢，則有助於保存更多數據。

d。num.partitions

在實時使用Kafka時，咱們應該注意這種配置。咱們能夠具備並行級別並行並行寫入數據，這將自動增長吞吐量。
瞭解Storm Kafka與配置和代碼的集成
可是，若是系統配置沒法處理，那麼增長分區數會下降咱們的性能和吞吐量。基本上，若是系統沒有足夠的線程或只有單個磁盤，那麼在建立大量分區以得到更好的吞吐量時沒有意義。所以，咱們能夠說，爲主題建立更多分區直接依賴於可用的線程和磁盤。

即 num.io.threads

基本上，咱們在集羣中有多少磁盤，它決定了I / O線程的設置值。此外，服務器使用這些線程來執行請求。所以，許多線程必須依賴於多個磁盤。
因此，這徹底是關於Kafka Performance Tuning。但願你喜歡咱們的解釋。

5.結論：Kafka Performance Tuning

所以，咱們已經看到了Kafka Performance調整的整個概念。此外，咱們研究了Tuning Kafka Producer，Tuning Kafka Broker，調整Kafka Consumer。另外，咱們討論了5個生產服務器配置。