列出集群當(dāng)前所有可用的topic

Kafka-topic.sh –list –zookeeper zookeeper_address

zookeeper_address 需要注意的是? 默認(rèn)的是 zookeerper管理節(jié)點的根目錄下的 brokers節(jié)點為存放kafka對應(yīng)的服務(wù)器數(shù)據(jù)信息

但是如果在CDH-Manager 的管理界面中 Kafka 配置中 修改了 zookeeper.chroot （默認(rèn)為空）修改為 /kafka

則 zookeeper_address 為 安裝kafka broker進(jìn)程的kafka server 對應(yīng)的ip:2181（默認(rèn)端口）/kafka

zookeeper.chroot Znode in zookeeper that should be used as a root for this kafka cluster.

replication.factor? 意味著 某一分區(qū)的全部副本 即如果為1 意味著整個kafka集群中只有這一個副本? 不是原來有一個，再加一個副本

生產(chǎn)者 配置時注意大小寫

分區(qū)消費(fèi)指定時 注意port為9092? 不是19092 否則會報 java.nio.channel.closeException

分區(qū)消費(fèi)時 注意 kafka.api? kafka.javaapi.* 的區(qū)別

一個index 一個log

分區(qū)文件都是存在與kafka日志所在目錄下? 如 topicName-0? topicName-1? topicName-0目錄下包含 00000000000000000.log 00000000000000000.index

replica.log.max.messages 表示 同步狀態(tài)的follower與leader 相差最大不能超過的記錄數(shù) 否則認(rèn)為不同步

leader處理partition的所有讀寫請求

Kafka每個topic的partition有N個副本，其中N是topic的復(fù)制因子。Kafka通過多副本機(jī)制實現(xiàn)故障自動轉(zhuǎn)移，當(dāng)Kafka集群中一個Broker失效情況下仍然保證服務(wù)可用。在Kafka中發(fā)生復(fù)制時確保partition的預(yù)寫式日志有序地寫到其他節(jié)點上。N個replicas中。其中一個replica為leader，其他都為follower，leader處理partition的所有讀寫請求，與此同時，follower會被動定期地去復(fù)制leader上的數(shù)據(jù)。

Kafka必須提供數(shù)據(jù)復(fù)制算法保證,如果leader發(fā)生故障或掛掉，一個新leader被選舉并接收客戶端的消息成功寫入。Kafka確保從同步副本列表中選舉一個副本為leader,或者換句話說,follower追趕leader數(shù)據(jù)。leader負(fù)責(zé)維護(hù)和跟蹤ISR中所有follower滯后狀態(tài)。當(dāng)生產(chǎn)者發(fā)送一條消息到Broker,leader寫入消息并復(fù)制到所有follower。消息提交之后才被成功復(fù)制到所有的同步副本。消息復(fù)制延遲受最慢的follower限制,重要的是快速檢測慢副本,如果follower”落后”太多或者失效,leader將會把它從replicas從ISR移除。

是什么原因?qū)е路謪^(qū)的副本與leader不同步

一個副本可以不同步Leader有如下幾個原因

慢副本：在一定周期時間內(nèi)follower不能追趕上leader。最常見的原因之一是I / O瓶頸導(dǎo)致follower追加復(fù)制消息速度慢于從leader拉取速度。

卡住副本：在一定周期時間內(nèi)follower停止從leader拉取請求。follower replica卡住了是由于GC暫?；騠ollower失效或死亡。

新啟動副本：當(dāng)用戶給主題增加副本因子時，新的follower不在同步副本列表中，直到他們完全趕上了leader日志。

一個partition的follower落后于leader足夠多時，被認(rèn)為不在同步副本列表或處于滯后狀態(tài)。在Kafka-0.8.2.x中,副本滯后判斷依據(jù)是副本落后于leader最大消息數(shù)量(replica.lag.max.messages)或replicas響應(yīng)partition leader的最長等待時間(replica.lag.time.max.ms)。前者是用來檢測緩慢的副本,而后者是用來檢測失效或死亡的副本

Kafka中replication復(fù)制數(shù)據(jù)

Kafka的復(fù)制機(jī)制既不是完全的同步復(fù)制，也不是單純的異步復(fù)制。完全同步復(fù)制要求All Alive Follower都復(fù)制完，這條消息才會被認(rèn)為commit，這種復(fù)制方式極大的影響了吞吐率。而異步復(fù)制方式下，F(xiàn)ollower異步的從Leader復(fù)制數(shù)據(jù)，數(shù)據(jù)只要被Leader寫入log就被認(rèn)為已經(jīng)commit，這種情況下如果Follower都復(fù)制完都落后于Leader，而如果Leader突然宕機(jī)，則會丟失數(shù)據(jù)。而Kafka的這種使用ISR的方式則很好的均衡了確保數(shù)據(jù)不丟失以及吞吐率。Follower可以批量的從Leader復(fù)制數(shù)據(jù)，而且Leader充分利用磁盤順序讀以及send file(zero copy)機(jī)制，這樣極大的提高復(fù)制性能，內(nèi)部批量寫磁盤，大幅減少了Follower與Leader的消息量差。

優(yōu)點

性能高，吞吐量大。

降低了系統(tǒng)和磁盤開銷，Leader充分利用磁盤順序讀以及send file(zero copy)機(jī)制。

降低Leader與Follower之間網(wǎng)絡(luò)開銷和交互次數(shù)。

缺點

有可能會占用大量網(wǎng)絡(luò)帶寬(例如本來集群很大而且數(shù)據(jù)量很多，后來新增Broker節(jié)點需要遷移數(shù)據(jù))，甚至堵塞網(wǎng)絡(luò)，需要有流控機(jī)制，否則會影響線上服務(wù)。

因為Follower是批量拉取Leader消息，如果設(shè)置為保證所有replicas commit，才返回Ack給生產(chǎn)者會存在抖動現(xiàn)象，F(xiàn)ollow拉取Leader修改HW，當(dāng)HW與當(dāng)次生產(chǎn)者請求logEndOffset的offst一致時，客戶端等待時間會拉長。

kafka集群副本分布原理分析

Kafka中partition replication之間同步數(shù)據(jù)，從partition的leader復(fù)制數(shù)據(jù)到follower只需要一個線程(ReplicaFetcherThread)，實際上復(fù)制是follower(一個follower相當(dāng)于consumer)主動從leader批量拉取消息的，這極大提高了吞吐量，從中可以看出無處不顯示Kafka高吞吐量設(shè)計思想。

這是一個異步復(fù)制過程，follow從leader批量拉取消息進(jìn)行同步數(shù)據(jù)

Kafka中partition replica復(fù)制機(jī)制：

Kafka中每個Broker啟動時都會創(chuàng)建一個副本管理服務(wù)(ReplicaManager)，該服務(wù)負(fù)責(zé)維護(hù)ReplicaFetcherThread與其他Broker鏈路連接關(guān)系，該Broker中存在多少Follower的partitions對應(yīng)leader partitions分布在不同的Broker上，有多少Broker就會創(chuàng)建相同數(shù)量的ReplicaFetcherThread線程同步對應(yīng)partition數(shù)據(jù)，Kafka中partition間復(fù)制數(shù)據(jù)是由follower(扮演consumer角色)主動向leader獲取消息，follower每次讀取消息都會更新HW狀態(tài)。每當(dāng)Follower的partitions發(fā)生變更影響leader所在Broker變化時，ReplicaManager就會新建或銷毀相應(yīng)的ReplicaFetcherThread。

Kafka中partitions數(shù)據(jù)一致性：

Kafka中Producer發(fā)送消息到Broker，Broker有三種返回方式，分別為noack、leader commit成功就ack、leader和follower同時commit成功才返回ack。第三種方式是數(shù)據(jù)強(qiáng)一致性。

如何保證數(shù)據(jù)強(qiáng)一致性？

當(dāng)Producer發(fā)送消息到leader partition所在Broker時，首先保證leader commit消息成功，然后創(chuàng)建一個“生產(chǎn)者延遲請求任務(wù)”，并判斷當(dāng)前partiton的HW是否大于等于logEndOffset，如果滿足條件即表示本次Producer請求partition replicas之間數(shù)據(jù)已經(jīng)一致，立即向Producer返回Ack。否則待Follower批量拉取Leader的partition消息時，同時更新Leader ISR中HW，然后檢查是否滿足上述條件，如果滿足向Producer返回Ack。

http://www.cnblogs.com/bonelee/p/6893286.html

http://www.infoq.com/cn/articles/kafka-analysis-part-3?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global