Kafka內(nèi)核中的分布式機制實現(xiàn)是怎樣的

Kafka內(nèi)核中的分布式機制實現(xiàn)是怎樣的，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

一個Topic中的所有數(shù)據(jù)分布式的存儲在kafka集群的所有機器(broker)上，以分區(qū)(partition)的的形式進行數(shù)據(jù)存儲;每個分區(qū)允許存在備份數(shù)據(jù)/備份分區(qū)(存儲在同一kafka集群的其它broker上的分區(qū))

每個數(shù)據(jù)分區(qū)在Kafka集群中存在一個broker節(jié)點上的分區(qū)叫做leader，存儲在其它broker上的備份分區(qū)叫做followers;只有l(wèi)eader節(jié)點負責該分區(qū)的數(shù)據(jù)讀寫操作，followers節(jié)點作為leader節(jié)點的熱備節(jié)點，從leader節(jié)點備份數(shù)據(jù);當leader節(jié)點掛掉的時候，followers節(jié)點中會有一個節(jié)點變成leader節(jié)點，重新提供服務

Kafka集群的Partition的leader和followers切換依賴Zookeeper

Kafka分布式保證的第一個特性就是：Kafka的Replication

Kafka的Replication指的是Partition的復制，一個Partition的所有分區(qū)中只有一個分區(qū)是leader節(jié)點，其它分區(qū)是follower節(jié)點。

Replication對Kafka的吞吐率有一定的影響，但是極大的增強了可用性

Follower節(jié)點會定時的從leader節(jié)點上獲取增量數(shù)據(jù)，一個活躍的follower節(jié)點必須滿足一下兩個條件：

1. 所有的節(jié)點必須維護和zookeeper的連接(通過zk的heartbeat實現(xiàn))

2. follower必須能夠及時的將leader上的writing復制過來，不能“落后太多”; “落后太多”由參數(shù){replica.lag.time.max.ms}和{replica.lag.max.messages}決定

Kafka分布式保證的第二個特性就是：Kafka Leader Election

Kafka提供了一個in-sync replicas(ISR)來確保Kafka的Leader選舉，ISR是一個保存分區(qū)node的集合，如果一個node宕機了或數(shù)據(jù)“落后太多”，leader會將該node節(jié)點從ISR中移除，只有ISR中的follower節(jié)點才有可能成為leader節(jié)點

Leader節(jié)點的切換基于Zookeeper的Watcher機制，當leader節(jié)點宕機的時候，其他ISR中的follower節(jié)點會競爭的在zk中創(chuàng)建一個文件目錄(只會有一個follower節(jié)點創(chuàng)建成功)，創(chuàng)建成功的follower節(jié)點成為leader節(jié)點

看完上述內(nèi)容，你們掌握Kafka內(nèi)核中的分布式機制實現(xiàn)是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內(nèi)容，歡迎關注億速云行業(yè)資訊頻道，感謝各位的閱讀！