kafka提供了兩套consumer API：高階Consumer API和低階API。

1.消費模型

       訊息由生產者釋出到Kafka集群后，會被消費者消費。訊息的消費模型有兩種：推送模型（push）和拉取模型（pull）。

     基於推送模型（push）的訊息系統，由訊息代理記錄消費者的消費狀態。訊息代理在將訊息推送到消費者後，標記這條訊息為已消費，但這種方式無法很好地保證訊息被處理。比如，訊息代理把訊息傳送出去後，當消費程序掛掉或者由於網路原因沒有收到這條訊息時，就有可能造成訊息丟失（因為訊息代理已經把這條訊息標記為已消費了，但實際上這條訊息並沒有被實際處理）。如果要保證訊息被處理，訊息代理髮送完訊息後，要設定狀態為“已傳送”，只有收到消費者的確認請求後才更新為“已消費”，這就需要訊息代理中記錄所有的消費狀態，這種做法顯然是不可取的。

     Kafka採用拉取模型，由消費者自己記錄消費狀態，每個消費者互相獨立地順序讀取每個分割槽的訊息。如下圖所示，有兩個消費者（不同消費者組）拉取同一個主題的訊息，消費者A的消費進度是3，消費者B的消費進度是6。消費者拉取的最大上限通過最高水位（watermark）控制，生產者最新寫入的訊息如果還沒有達到備份數量，對消費者是不可見的。這種由消費者控制偏移量的優點是：消費者可以按照任意的順序消費訊息。比如，消費者可以重置到舊的偏移量，重新處理之前已經消費過的訊息；或者直接跳到最近的位置，從當前的時刻開始消費。

       在一些訊息系統中，訊息代理會在訊息被消費之後立即刪除訊息。如果有不同型別的消費者訂閱同一個主題，訊息代理可能需要冗餘地儲存同一訊息；或者等所有消費者都消費完才刪除，這就需要訊息代理跟蹤每個消費者的消費狀態，這種設計很大程度上限制了訊息系統的整體吞吐量和處理延遲。Kafka的做法是生產者釋出的所有訊息會一致儲存在Kafka叢集中，不管訊息有沒有被消費。使用者可以通過設定保留時間來清理過期的資料，比如，設定保留策略為兩天。那麼，在訊息釋出之後，它可以被不同的消費者消費，在兩天之後，過期的訊息就會自動清理掉。

2.高階API

(1) 高階API優點

    高階API 寫起來簡單

    不需要自行去管理offset，系統通過zookeeper自行管理。

    不需要管理分割槽，副本等情況，系統自動管理。

    消費者斷線會自動根據上一次記錄在zookeeper中的offset去接著獲取資料（預設設定1分鐘更新一下zookeeper中存的offset）。

    可以使用group來區分對同一個topic 的不同程式訪問分離開來（不同的group記錄不同的offset，這樣不同程式讀取同一個topic才不會因為offset互相影響）。

(2) 高階API缺點

    不能自行控制offset（對於某些特殊需求來說）

    不能細化控制如分割槽、副本、zk等

3.低階API

(1) 低階 API 優點

    能夠讓開發者自己控制offset，想從哪裡讀取就從哪裡讀取。

    自行控制連線分割槽，對分割槽自定義進行負載均衡

    對zookeeper的依賴性降低（如：offset不一定非要靠zk儲存，自行儲存offset即可，比如存在檔案或者記憶體中）

(2) 低階API缺點

    太過複雜，需要自行控制offset，連線哪個分割槽，找到分割槽leader 等。

4.消費者組

    消費者是以consumer group消費者組的方式工作，由一個或者多個消費者組成一個組，共同消費一個topic。每個分割槽在同一時間只能由group中的一個消費者讀取，但是多個group可以同時消費這個partition。如上圖所示，有一個由三個消費者組成的group，有一個消費者讀取主題中的兩個分割槽，另外兩個分別讀取一個分割槽。某個消費者讀取某個分割槽，也可以叫做某個消費者是某個分割槽的擁有者。

    在這種情況下，消費者可以通過水平擴充套件的方式同時讀取大量的訊息。另外，如果一個消費者失敗了，那麼其他的group成員會自動負載均衡讀取之前失敗的消費者讀取的分割槽。

5.消費方式

    consumer採用pull（拉）模式從broker中讀取資料。

    push（推）模式很難適應消費速率不同的消費者，因為訊息傳送速率是由broker決定的。它的目標是儘可能以最快速度傳遞訊息，但是這樣很容易造成consumer來不及處理訊息，典型的表現就是拒絕服務以及網路擁塞。而pull模式則可以根據consumer的消費能力以適當的速率消費訊息。

    對於Kafka而言，pull模式更合適，它可簡化broker的設計，consumer可自主控制消費訊息的速率，同時consumer可以自己控制消費方式——即可批量消費也可逐條消費，同時還能選擇不同的提交方式從而實現不同的傳輸語義。

    pull模式不足之處是，如果kafka沒有資料，消費者可能會陷入迴圈中，一直等待資料到達。為了避免這種情況，我們在我們的拉請求中有引數，允許消費者請求在等待資料到達的“長輪詢”中進行阻塞（並且可選地等待到給定的位元組數，以確保大的傳輸大小）。

6.消費者組案例

(1) 需求

測試同一個消費者組中的消費者，同一時刻只能有一個消費者消費。

(2) 案例實操

    ① 在hadoop102、hadoop103上修改/opt/module/kafka/config/consumer.properties配置檔案中的group.id屬性為任意組名。

        [[email protected] config]$ vi consumer.properties

        group.id=luomk

    ② 在hadoop102、hadoop103上分別啟動消費者

        [[email protected] kafka]$ bin/kafka-console-consumer.sh -zookeeper hadoop102:2181 --topic first --consumer.config config/consumer.properties

        [[email protected] kafka]$ bin/kafka-console-consumer.sh -zookeeper hadoop102:2181 --topic first --consumer.config config/consumer.properties

    ③ 在hadoop104上啟動生產者

        [[email protected] kafka]$ bin/kafka-console-producer.sh --broker-list hadoop102:9092 --topic first

        >hello world

    ④ 檢視hadoop102和hadoop103的接收者。

        同一時刻只有一個消費者接收到訊息。