Kafka生產者ack機制的原理是什么

這篇文章主要介紹“Kafka生產者ack機制的原理是什么”，在日常操作中，相信很多人在Kafka生產者ack機制的原理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Kafka生產者ack機制的原理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

分區副本

Kafka的topic是可以分區的，并且可以為分區配置多個副本，改配置可以通過replication.factor參數實現. Kafka中的分區副本包括兩種類型：領導者副本（Leader Replica）和追隨者副本（Follower Replica)，每個分區在創建時都要選舉一個副本作為領導者副本，其余的副本自動變為追隨者副本. 在 Kafka 中，追隨者副本是不對外提供服務的，也就是說，任何一個追隨者副本都不能響應消費者和生產者的讀寫請求. 所有的請求都必須由領導者副本來處理. 換句話說，所有的讀寫請求都必須發往領導者副本所在的 Broker，由該 Broker 負責處理. 追隨者副本不處理客戶端請求，它唯一的任務就是從領導者副本異步拉取消息，并寫入到自己的提交日志中，從而實現與領導者副本的同步.

Kafka默認的副本因子是3，即每個分區只有1個leader副本和2個follower副本.具體如下圖所示：

上面提到生產者客戶端僅寫入Leader broker，跟隨者異步復制數據。由于Kafka是一個分布式系統，必然會存在與 Leader 不能實時同步的風險，所以需要一種方法來判斷這些追隨者是否跟上了領導者的步伐, 即追隨者是否同步了最新的數據.換句話說，Kafka 要明確地告訴我們，追隨者副本到底在什么條件下才算與 Leader 同步？這就是下面所要說的ISR同步副本機制.

同步副本(In-sync replicas)

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是一個動態列表，并不是靜態不變的。

如上圖所示：Broker3上的partition1副本超過了規定時間，未與Leader副本同步，所以被踢出ISR列表，此時的ISR為[1,3].

acks確認機制

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的值可以提升消息的持久性. 因為如果同步副本的數量低于該配置值，則生產者會收到錯誤響應，從而確保消息不丟失.

Case 1

如下圖，當min.insync.replicas=2且acks=all時，如果此時ISR列表只有[1,2],3被踢出ISR列表，只需要保證兩個副本同步了，生產者就會收到成功響應.

Case 2

如下圖，當min.insync.replicas=2，如果此時ISR列表只有[1],2和3被踢出ISR列表，那么當acks=all時，則不能成功寫入數；當acks=0或者acks=1可以成功寫入數據.

Case 3

這種情況是很容易引起誤解的，如果acks=all且min.insync.replicas=2，此時ISR列表為[1,2,3],那么還是會等到所有的同步副本都同步了消息，才會向生產者發送成功響應的ack.因為min.insync.replicas=2只是一個最低限制，即同步副本少于該配置值，則會拋異常，而acks=all，是需要保證所有的ISR列表的副本都同步了才可以發送成功響應. 如下圖所示：

到此，關于“Kafka生產者ack機制的原理是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！