溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章給大家分享的是有關Kafka生產環境的重要配置參數是什么，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
Kafka在彈性、容錯性以及高吞吐量方面有著很大的優勢。想要達到生產環境最優，發揮這些特性，需要我們進行一系列的配置。Kafka提供了非常多的配置屬性，對于初學者而言，很容易陷入困惑。其實，多數的配置已經滿足了大部分的使用場景，小編分享總結了幾個比較重要的配置參數，主要是針對producer端的配置。
acks參數指定了必須要有多少個分區副本收到消息，生產者才認為該消息是寫入成功的，這個參數對于消息是否丟失起著重要作用，該參數的配置具體如下：
acks=0，表示生產者在成功寫入消息之前不會等待任何來自服務器的響應. 換句話說，一旦出現了問題導致服務器沒有收到消息，那么生產者就無從得知，消息也就丟失了. 改配置由于不需要等到服務器的響應，所以可以以網絡支持的最大速度發送消息，從而達到很高的吞吐量。
acks=1，表示只要集群的leader分區副本接收到了消息，就會向生產者發送一個成功響應的ack，此時生產者接收到ack之后就可以認為該消息是寫入成功的. 一旦消息無法寫入leader分區副本(比如網絡原因、leader節點崩潰),生產者會收到一個錯誤響應，當生產者接收到該錯誤響應之后，為了避免數據丟失，會重新發送數據.這種方式的吞吐量取決于使用的是異步發送還是同步發送.
尖叫提示：如果生產者收到了錯誤響應，即便是重新發消息，還是會有可能出現丟數據的現象. 比如，如果一個沒有收到消息的節點成為了新的Leader，消息就會丟失.
acks =all,表示只有所有參與復制的節點(ISR列表的副本)全部收到消息時，生產者才會接收到來自服務器的響應. 這種模式是最高級別的，也是最安全的，可以確保不止一個Broker接收到了消息. 該模式的延遲會很高.
上面提到，當acks=all時，需要所有的副本都同步了才會發送成功響應到生產者. 其實這里面存在一個問題：如果Leader副本是唯一的同步副本時會發生什么呢？此時相當于acks=1.所以是不安全的.
Kafka的Broker端提供了一個參數min.insync.replicas,該參數控制的是消息至少被寫入到多少個副本才算是"真正寫入",該值默認值為1，生產環境設定為一個大于1的值可以提升消息的持久性. 因為如果同步副本的數量低于該配置值，則生產者會收到錯誤響應，從而確保消息不丟失.
In-sync replica(ISR)稱之為同步副本，ISR中的副本都是與Leader進行同步的副本，所以不在該列表的follower會被認為與Leader是不同步的. 那么，ISR中存在是什么副本呢？首先可以明確的是：Leader副本總是存在于ISR中. 而follower副本是否在ISR中，取決于該follower副本是否與Leader副本保持了“同步”.
尖叫提示：對于"follower副本是否與Leader副本保持了同步"的理解如下：
(1)上面所說的同步不是指完全的同步，即并不是說一旦follower副本同步滯后與Leader副本，就會被踢出ISR列表.
(2)Kafka的broker端有一個參數**
replica.lag.time.max.ms**, 該參數表示follower副本滯后與Leader副本的最長時間間隔，默認是10秒. 這就意味著，只要follower副本落后于leader副本的時間間隔不超過10秒，就可以認為該follower副本與leader副本是同步的，所以哪怕當前follower副本落后于Leader副本幾條消息，只要在10秒之內趕上Leader副本，就不會被踢出出局.（3）如果follower副本被踢出ISR列表，等到該副本追上了Leader副本的進度，該副本會被再次加入到ISR列表中，所以ISR是一個動態列表，并不是靜態不變的。
生產者從服務器收到的錯誤有可能是臨時性的錯誤（比如分區找不到首領）。在這種情況下， retries參數的值決定了生產者可以重發消息的次數，如果達到這個次數，生產者會放棄重試并返回錯誤。默認情況下，生產者會在每次重試之間等待100ms ，可以通過retry.backoff.ms 參數來配置時間間隔。
比如，設置了acks=all和min.insync.replicas=2。由于某種原因，所有follower都掛了，由于min.insync.replicas=2，所以生產者無法收到來自Broker端的ack。
此時我們會從Producer端收到一個錯誤消息："Broker: Not enough in-sync replicas"。這就意味著Kafka不能在Broker上追加生產的消息(數據)了，因為此時的ISR的數量不夠。此時在Broker端會有如下的錯誤消息：
org.apache.kafka.common.errors.NotEnoughReplicasException: The size of the current ISR Set(0) is insufficient to satisfy the min.isr requirement of 2 for partition
默認情況下，Producer不會對此錯誤進行處理，這就會造成消息丟失，即**at-most-once **語義。我們可以通過配置重試次數來讓生產者重新發送消息。比如配置retries=3，默認為0
在某些情況下，實際上已將消息提交給了所有同步副本，但是由于網絡問題，Broker無法向Producer發送確認ack。由于我們設置retries=3，所以producer將重新發送消息3次，這可能會導致topic中消息重復。
比如有一個producer向該topic發送1M消息，并且在提交消息之后但在生產者收到所有確認ack之前，broker失敗了。在這種情況下，由于重試機制，最終可能在該topic上收到超過1M的消息，這也稱為at-lease-once語義。
當然，我們想要實現的是exactly-once語義，即：即便生產者重新發送消息，消費者也應該只收到一次相同的消息。
此時需要進行冪等操作，所謂冪等，即指一次執行一個操作或多次執行一個操作具有相同的效果。配置冪等很簡單，通過配置enable.idempotence=true即可,默認為false。
那么，冪等是如何實現的呢？由于消息是分batch(批次)發送的，每個batch都有一個序列號。在Broker端，會追蹤每個分區的最大序列號。如果出現序列號較小或相等的batch(批次)，broker將不會將該batch寫入topic。這樣，除了保證了冪等性，還可以確保batch的順序。
該參數指定了生產者在收到服務器晌應之前可以發送多少個消息。它的值越高，就會占用越多的內存，不過也會提升吞吐量。把它設為1可以保證消息是按照發送的順序寫入服務器的，即使發生了重試。
因為如果將兩個批次發送到單個分區，并且第一個批次失敗并被重試，但是，接著第二個批次寫入成功，則第二個批次中的記錄可能會首先出現，這樣就會發生亂序。
如果沒有啟用冪等功能，但仍然希望按順序發送消息，則應將此設置配置為1。但是，如果已經啟用了冪等，則無需顯式定義此配置。
該參數用來設置生產者內存緩沖區的大小，生產者用它緩沖要發送到服務器的消息。如果應用程序發送消息的速度超過發送到服務器的速度，會導致生產者空間不足。這個時候，send()方法調用要么被阻塞，要么拋出異常，取決于如何設置max.block.ms。
當生產者調用時send()，消息并不會立即發送，而是會添加到內部緩沖區中。默認buffer.memory值為32MB。如果生產者發送消息的速度超過了將消息發送到broker的速度，或者存在網絡問題，send()方法調用會被阻塞max.block.ms參數配置的時常，默認1分鐘。
該參數指定了在調用send()方法或使用partitionsFor()方法獲取元數據時生產者的阻塞時間。當生產者的發送緩沖區已滿，或者沒有可用的元數據時，這些方法就會被阻塞。在阻塞時間達到max.block.ms時，生產者會拋出超時異常。
該參數指定了生產者在發送批次之前等待更多消息加入批次的時間。kafka生產者會在批次填滿或linger.ms達到上限時把批次發送出去。默認情況下，只要有可用的線程，生產者就會把消息發送出去，就算批次里只有一個消息。把linger.ms設置成比0大的數，讓生產者在發送批次之前等待一會兒，使更多的消息加入到這個批次。雖然這樣會增加延遲，但也會提升吞吐量（因為一次性發送更多的消息，每個消息的開銷就變小了）。
當有多個消息需要被發送到同一個分區時，生產者會把它們放在同一個批次里。該參數指定了一個批次可以使用的內存大小，按照字節數計算（而不是消息個數）。當批次被填滿，批次里的所有消息會被發送出去。不過生產者井不一定都會等到批次被填滿才發送，這取決于linger.ms的配置，比如如果linger.ms時間到了，即便批次只包含一個消息，也會被立即發送。所以就算把批次大小設置得很大，也不會造成延遲，只是會占用更多的內存而已。但如果設置得太小，因為生產者需要更頻繁地發送消息，會增加一些額外的開銷。
可以使用配置使用linger.ms和batch.size。linger.ms是準備好發送批次之前的延遲時間，默認值為0。這意味著即使批次中只有1條消息，批次也會立即發送。有時，會增加linger.ms以減少請求數量并提高吞吐量。但這將導致更多消息保留在內存中。batch.size是單個批次的最大大小，當滿足這兩個要求中的任何一個時，將發送批次。
默認情況下，消息發送時不會被壓縮。該參數可以設置為snappy 、gzip 或lz4 ，它指定了消息被發送給broker 之前使用哪一種壓縮算也進行壓縮。使用壓縮可以降低網絡傳輸開銷和存儲開銷，而這往往是向Kafka 發送消息的瓶頸所在。
以上就是Kafka生產環境的重要配置參數是什么，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
