2. Kafka消費(fèi)過的消息如何再消費(fèi)？

kafka消費(fèi)消息的offset是定義在zookeeper中的，    如果想重復(fù)消費(fèi)kafka的消息，可以在redis中自己記錄offset的checkpoint點(diǎn)（n個(gè)），當(dāng)想重復(fù)消費(fèi)消息時(shí)，通過讀取redis中的checkpoint點(diǎn)進(jìn)行zookeeper的offset重設(shè)，這樣就可以達(dá)到重復(fù)消費(fèi)消息的目的了

3. kafka的數(shù)據(jù)是放在磁盤上還是內(nèi)存上，為什么速度會快？

kafka使用的是磁盤存儲。

速度快是因?yàn)椋?/p>

1. 順序?qū)懭耄阂驗(yàn)橛脖P是機(jī)械結(jié)構(gòu)，每次讀寫都會尋址->寫入，其中尋址是一個(gè)“機(jī)械動作”，它是耗時(shí)的。所以硬盤 “討厭”隨機(jī)I/O， 喜歡順序I/O。為了提高讀寫硬盤的速度，Kafka就是使用順序I/O。

2. Memory Mapped Files（內(nèi)存映射文件）：64位操作系統(tǒng)中一般可以表示20G的數(shù)據(jù)文件，它的工作原理是直接利用操作系統(tǒng)的Page來實(shí)現(xiàn)文件到物理內(nèi)存的直接映射。完成映射之后你對物理內(nèi)存的操作會被同步到硬盤上。

3. Kafka高效文件存儲設(shè)計(jì)：Kafka把topic中一個(gè)parition大文件分成多個(gè)小文件段，通過多個(gè)小文件段，就容易定期清除或刪除已經(jīng)消費(fèi)完文件，減少磁盤占用。通過索引信息可以快速定位
   message和確定response的 大     小。通過index元數(shù)據(jù)全部映射到memory（內(nèi)存映射文件），
   可以避免segment file的IO磁盤操作。通過索引文件稀疏存儲，可以大幅降低index文件元數(shù)據(jù)占用空間大小。

注：

1. Kafka解決查詢效率的手段之一是將數(shù)據(jù)文件分段，比如有100條Message，它們的offset是從0到99。假設(shè)將數(shù)據(jù)文件分成5段，第一段為0-19，第二段為20-39，以此類推，每段放在一個(gè)單獨(dú)的數(shù)據(jù)文件里面，數(shù)據(jù)文件以該段中 小的offset命名。這樣在查找指定offset的
   Message的時(shí)候，用二分查找就可以定位到該Message在哪個(gè)段中。

2. 為數(shù)據(jù)文件建 索引數(shù)據(jù)文件分段 使得可以在一個(gè)較小的數(shù)據(jù)文件中查找對應(yīng)offset的Message 了，但是這依然需要順序掃描才能找到對應(yīng)offset的Message。
   為了進(jìn)一步提高查找的效率，Kafka為每個(gè)分段后的數(shù)據(jù)文件建立了索引文件，文件名與數(shù)據(jù)文件的名字是一樣的，只是文件擴(kuò)展名為.index。

4. Kafka數(shù)據(jù)怎么保障不丟失？

分三個(gè)點(diǎn)說，一個(gè)是生產(chǎn)者端，一個(gè)消費(fèi)者端，一個(gè)broker端。

1. 生產(chǎn)者數(shù)據(jù)的不丟失

kafka的ack機(jī)制：在kafka發(fā)送數(shù)據(jù)的時(shí)候，每次發(fā)送消息都會有一個(gè)確認(rèn)反饋機(jī)制，確保消息正常的能夠被收到，其中狀態(tài)有0，1，-1。

如果是同步模式： 
ack設(shè)置為0，風(fēng)險(xiǎn)很大，一般不建議設(shè)置為0。即使設(shè)置為1，也會隨著leader宕機(jī)丟失數(shù)據(jù)。所以如果要嚴(yán)格保證生產(chǎn)端數(shù)據(jù)不丟失，可設(shè)置為-1。

如果是異步模式： 
也會考慮ack的狀態(tài)，除此之外，異步模式下的有個(gè)buffer，通過buffer來進(jìn)行控制數(shù)據(jù)的發(fā)送，有兩個(gè)值來進(jìn)行控制，時(shí)間閾值與消息的數(shù)量閾值，如果buffer滿了數(shù)據(jù)還沒有發(fā)送出去，有個(gè)選項(xiàng)是配置是否立即清空buffer?？梢栽O(shè)置為-1，永久阻塞，也就數(shù)據(jù)不再生產(chǎn)。異步模式下，即使設(shè)置為-1。也可能因?yàn)槌绦騿T的不科學(xué)操作，操作數(shù)據(jù)丟失，比如kill -9，但這是特別的例外情況。

注： 
ack=0：producer不等待broker同步完成的確認(rèn)，繼續(xù)發(fā)送下一條(批)信息。 
ack=1（默認(rèn)）：producer要等待leader成功收到數(shù)據(jù)并得到確認(rèn)，才發(fā)送下一條message。 
ack=-1：producer得到follwer確認(rèn)，才發(fā)送下一條數(shù)據(jù)。

2. 消費(fèi)者數(shù)據(jù)的不丟失

通過offset commit 來保證數(shù)據(jù)的不丟失，kafka自己記錄了每次消費(fèi)的offset數(shù)值，下次繼續(xù)消費(fèi)的時(shí)候，會接著上次的offset進(jìn)行消費(fèi)。

而offset的信息在kafka0.8版本之前保存在zookeeper中，在0.8版本之后保存到topic中，即使消費(fèi)者在運(yùn)行過程中掛掉了，再次啟動的時(shí)候會找到offset的值，找到之前消費(fèi)消息的位置，接著消費(fèi)，由于 offset 的信息寫入的時(shí)候并不是每條消息消費(fèi)完成后都寫入的，所以這種情況有可能會造成重復(fù)消費(fèi)，但是不會丟失消息。

唯一例外的情況是，我們在程序中給原本做不同功能的兩個(gè)consumer組設(shè)置
KafkaSpoutConfig.bulider.setGroupid的時(shí)候設(shè)置成了一樣的groupid，這種情況會導(dǎo)致這兩個(gè)組共享同一份數(shù)據(jù)，就會產(chǎn)生組A消費(fèi)partition1，partition2中的消息，組B消費(fèi)partition3的消息，這樣每個(gè)組消費(fèi)的消息都會丟失，都是不完整的。為了保證每個(gè)組都獨(dú)享一份消息數(shù)據(jù)，groupid一定不要重復(fù)才行。

3. kafka集群中的broker的數(shù)據(jù)不丟失

每個(gè)broker中的partition我們一般都會設(shè)置有replication（副本）的個(gè)數(shù)，生產(chǎn)者寫入的時(shí)候首先根據(jù)分發(fā)策略（有partition按partition，有key按key，都沒有輪詢）寫入到leader中，follower（副本）再跟leader同步數(shù)據(jù)，這樣有了備份，也可以保證消息數(shù)據(jù)的不丟失。

5. 采集數(shù)據(jù)為什么選擇kafka？

采集層 主要可以使用Flume, Kafka等技術(shù)。

Flume：Flume 是管道流方式，提供了很多的默認(rèn)實(shí)現(xiàn)，讓用戶通過參數(shù)部署，及擴(kuò)展API.

Kafka：Kafka是一個(gè)可持久化的分布式的消息隊(duì)列。Kafka 是一個(gè)非常通用的系統(tǒng)。你可以有許多生產(chǎn)者和很多的消費(fèi)者共享多個(gè)主題Topics。

相比之下,Flume是一個(gè)專用工具被設(shè)計(jì)為旨在往HDFS，HBase發(fā)送數(shù)據(jù)。它對HDFS有特殊的優(yōu)化，并且集成了Hadoop的安全特性。

所以，Cloudera 建議如果數(shù)據(jù)被多個(gè)系統(tǒng)消費(fèi)的話，使用kafka；如果數(shù)據(jù)被設(shè)計(jì)給Hadoop使用，使用Flume。

6. kafka 重啟是否會導(dǎo)致數(shù)據(jù)丟失？

1. kafka是將數(shù)據(jù)寫到磁盤的，一般數(shù)據(jù)不會丟失。

2. 但是在重啟kafka過程中，如果有消費(fèi)者消費(fèi)消息，那么kafka如果來不及提交offset，可能會造成數(shù)據(jù)的不準(zhǔn)確（丟失或者重復(fù)消費(fèi)）。

7. kafka 宕機(jī)了如何解決？

1. 先考慮業(yè)務(wù)是否受到影響

kafka 宕機(jī)了，首先我們考慮的問題應(yīng)該是所提供的服務(wù)是否因?yàn)殄礄C(jī)的機(jī)器而受到影響，如果服務(wù)提供沒問題，如果實(shí)現(xiàn)做好了集群的容災(zāi)機(jī)制，那么這塊就不用擔(dān)心了。

2. 節(jié)點(diǎn)排錯(cuò)與恢復(fù)

想要恢復(fù)集群的節(jié)點(diǎn)，主要的步驟就是通過日志分析來查看節(jié)點(diǎn)宕機(jī)的原因，從而解決，重新恢復(fù)節(jié)點(diǎn)。

8. 為什么Kafka不支持讀寫分離？

在 Kafka 中，生產(chǎn)者寫入消息、消費(fèi)者讀取消息的操作都是與 leader 副本進(jìn)行交互的，從 而實(shí)現(xiàn)的是一種主寫主讀的生產(chǎn)消費(fèi)模型。
Kafka 并不支持主寫從讀，因?yàn)橹鲗憦淖x有 2 個(gè)很明顯的缺點(diǎn):

1. 數(shù)據(jù)一致性問題：數(shù)據(jù)從主節(jié)點(diǎn)轉(zhuǎn)到從節(jié)點(diǎn)必然會有一個(gè)延時(shí)的時(shí)間窗口，這個(gè)時(shí)間 窗口會導(dǎo)致主從節(jié)點(diǎn)之間的數(shù)據(jù)不一致。某一時(shí)刻，在主節(jié)點(diǎn)和從節(jié)點(diǎn)中 A 數(shù)據(jù)的值都為 X， 之后將主節(jié)點(diǎn)中 A 的值修改為 Y，那么在這個(gè)變更通知到從節(jié)點(diǎn)之前，應(yīng)用讀取從節(jié)點(diǎn)中的 A 數(shù)據(jù)的值并不為最新的 Y，由此便產(chǎn)生了數(shù)據(jù)不一致的問題。

2. 延時(shí)問題：類似 Redis 這種組件，數(shù)據(jù)從寫入主節(jié)點(diǎn)到同步至從節(jié)點(diǎn)中的過程需要經(jīng)歷 網(wǎng)絡(luò)→主節(jié)點(diǎn)內(nèi)存→網(wǎng)絡(luò)→從節(jié)點(diǎn)內(nèi)存 這幾個(gè)階段，整個(gè)過程會耗費(fèi)一定的時(shí)間。而在 Kafka 中，主從同步會比 Redis 更加耗時(shí)，它需要經(jīng)歷 網(wǎng)絡(luò)→主節(jié)點(diǎn)內(nèi)存→主節(jié)點(diǎn)磁盤→網(wǎng)絡(luò)→從節(jié) 點(diǎn)內(nèi)存→從節(jié)點(diǎn)磁盤 這幾個(gè)階段。對延時(shí)敏感的應(yīng)用而言，主寫從讀的功能并不太適用。

而kafka的主寫主讀的優(yōu)點(diǎn)就很多了：

1. 可以簡化代碼的實(shí)現(xiàn)邏輯，減少出錯(cuò)的可能;  

2. 將負(fù)載粒度細(xì)化均攤，與主寫從讀相比，不僅負(fù)載效能更好，而且對用戶可控;

3. 沒有延時(shí)的影響;

4. 在副本穩(wěn)定的情況下，不會出現(xiàn)數(shù)據(jù)不一致的情況。