若此時C0下線，RoundRobinAssignor重分配的結果如下：

而StickyAssignor重分配結果如下：

綜上：

StickyAssignor分配策略的優點就是可以使分區重分配具備 “黏性”，減少不必要的分區移動（一個分區剝離之前的消費者 ，轉而分配給另一個新的消費者）。

Kafka中的消息消費是基于拉模式。

Kafka每次拉取一組消息，每條消息的格式如下：

在每次拉取方法時，它返回的是還沒有被消費過的消息集。要實現這個功能，就需要知道上次消費時的消費位移，消費者在消費完消息后要進行消費位移提交動作，且消費位移要進行持久化，消費位移保存在__買粉絲nsumer_offsets主題中。

當前拉取消息的最大offset為x，消費者消費完成提交位移的是offset其實為x+1，表示下次拉取消息的起始位置。

自動提交

默認采用自動提交，默認每隔5s會將拉取到的每個分區的最大的消息位移進行提交。真正的提交動作是在拉取消息的邏輯完成，每次拉取消息前會判斷是否可以進行位移提交，如果可以則提交上一次的位移。這里會有兩個問題，如下圖所示。

重復消費：當前拉取消息【x+2,x+7】，當前消費到X+5，在提交消費位移前，消費者宕機；新的消費者還是會從X+2開始拉取消息， 因此導致重復消費。

消息丟失：當前拉取消息【x+2,x+7】，當前消費X+5，到下次拉取的時候，消費位移已經提交為X+8，若此時消費者宕機，新的消費者會從X+8處開始消費，導致X+5 ~ X+7的消息沒有被消費，導致消息的丟失。

手動提交

同步提交和異步提交。

同步提交默認提交本次拉取分區消息的最大偏移量，如本次拉取【X+2，X+7】的消息，同步提交默認提交X+8的位置；當時同步提交也可指定提交的偏移量，比如消費一條提交1次，因為提交本身為同步操作，所以會耗費一定的性能。

同步提交也會導致重復消費的問題，如消費完成后，提交前消費者宕機。

異步提交消費者線程不會被阻塞，使性能得到增強，但異步提交失敗重試可能會導致提交位移被覆蓋的問題，如本次異步提交offset=X失敗，下次異步提交offset=X+y成功；此時前一次提交重試再次提交offset=x，如果業務上沒有重試校驗，會導致offset被覆蓋，最終導致重復消費。

當新的消費組建立、消費者訂閱新的主題或之前提交的位移信息因為過期被刪除等，此時查不到紀錄的消費位移。Kafka可配置從最新或從最早處開始消費。

Kafka還支持從特定位移處開始消費，可以實現回溯消費，Kafka內部提供了Seek()方法，來重置消費位移。

當需要回溯指定時間后的消息時，可先用offsetsForTimes方法查到指定時間后第一條消息的位移，然后再用seek重置位移。

分區的所屬權從一個消費者轉移到另一消費者的行為，它為消費組具備高可用性和伸縮性提供保障，使我們可以既方便又安全地刪除或添加消費者。

Kfaka提供了組協調器(GroupCoordinator)和消費者協調器(ConsumerCoordinator)，前者負責管理消費組，后者負責與前者交互，兩者最重要的職責就是負責再均衡的操作。

舉例說明，當消費者加入消費組時，消費者、消費組和組協調器之間一般會經歷以下幾個階段。

第一階段（FIND COORDINATOR）

消費者需要確定它所屬的消費組對應的GroupCoordinator所在的broker并創建與該broker 相互通信的網絡連接。

消費者會向集群中的某個節點發送FindCoordinatorRequest請求來查找對應的組協調器。

Kafka根據請求中的買粉絲ordinator_key（也就是groupld ）的哈希值計算__買粉絲nsumer_offsets中的分區編號，如下圖所示。找到對應的分區之后，在尋找此分區leader副本所在的broker節點，該節點即為當前消費組所在的組協調器節點。

消費組最終的分區分配方案及組內消費者所提交的消費位移信息都會發送給該broker節點。該broker節點既扮演GroupCoordinato的角色又扮演保存分區分配方案和組內消費者位移的角色，這樣可以省去很多不必要的中間輪轉所帶來的開銷。

第二階段（JOIN GROUP)

在成功找到消費組所對應的GroupCoordinator之后就進入加入消費組的階段，在此階段的 消費者會向GroupCoordinator發送JoinGroupRequest請求，并處理響應。

組協調器內部主要做了以下幾件事：

選舉消費組的****leader

如果當前組內沒有leader，那么第一個加入消費組的則為leader。如果leader掛掉，組協調器會從內部維護的HashMap（消費者信息，key為member_id）中選擇第一個key作為新的leader。

選舉分區分配策略

前面說的每個消費者可能會上報多個分區分配策略，選舉過程如下：

第三階段（SYNC GROUP)

leader消費者根據在第二階段中得到的分區分配策略來實施分區分配，然后將分配結果同步到組協調器。各個消費者會向組協調器發送SyncGroupRequest請求來同步分配方案。

請求結構如圖，leader發送的請求才會有group_assignment。

其中包含了各個消費者對應的具體分配方案，member_id表示消費者的唯一標識，而 member_assignment是與消費者對應的分配方案，如圖

消費者收到具體的分區分配方案后，會開啟心跳任務，定期向組協調器發送心跳請求確定彼此在線。

第四階段（HEARTBEAT)

在正式消費之前，消費者還需要確定拉取消息的起始位置。假設之前已經將最后的消費位移提交成功，那么消費者會請求獲取上次提交的消費位移并從此處繼續消費。

心跳線程是一個獨立的線程，可以在輪詢消息的空檔發送。如果消費者停發送心跳的時間足夠長，組協調器會認為這個消費者已經死亡，則觸發一次再均衡行為。

請問kafka和rabbitmq有啥區別啊？

kafaka和rabbitmq的最主要區別在于數據的可靠性和吞吐量上；在實際場景中，需要按需求取舍。rabbitmq在金融場景中經常使用，具有較高的嚴謹性，數據丟失的可能性更小，同時具備更高的實時性，基于存儲的可靠性的要求存儲可以采用內存或者硬盤。而kafka優勢主要體現在吞吐量上，雖然可以通過策略實現數據不丟失，但從嚴謹性角度來講，大不如rabbitmq；而且由于kafka保證每條消息最少送達一次，有較小的概率會出現數據重復發送的情況。

請采納，謝謝！

《Kafka權威指南》pdf下載在線閱讀，求百度網盤云資源

《Kafka權威指南》（Neha Narkhede）電子書網盤下載免費在線閱讀

鏈接：買粉絲s://pan..買粉絲/s/17wJr53y7UtHbj-H7Y2H-4w 提取碼：1234    

書名：Kafka權威指南

作者：Neha Narkhede

譯者：薛命燈

豆瓣評分：8.5

出版社：人民郵電出版社

出版年份：2017-12-26

頁數：214

內容簡介：

每個應用程序都會產生數據，包括日志消息、度量指標、用戶活動記錄、響應消息等。如何移動數據，幾乎變得與數據本身一樣重要。如果你是架構師、開發者或者產品工程師，同時也是Apache Kafka新手，那么這本實踐指南將會幫助你成為流式平臺上處理實時數據的專家。

本書由出身于LinkedIn的Kafka核心作者和一線技術人員共同執筆，詳細介紹了如何部署Kafka集群、開發可靠的基于事件驅動的微服務，以及基于Kafka平臺構建可伸縮的流式應用程序。通過詳盡示例，你將會了解到Kafka的設計原則、可靠性保證、關鍵API，以及復制協議、控制器和存儲層等架構細節。

● 了解發布和訂閱消息模型以及該模型如何被應用在大數據生態系統中

● 學習使用Kafka生產者和消費者來生成消息和讀取消息

● 了解Kafka保證可靠性數據傳遞的模式和場景需求

● 使用Kafka構建數據管道和應用程序的最佳實踐

● 在生產環境中管理Kafka，包括監控、調優和維護

● 了解Kafka的關鍵度量指標

● 探索Kafka如何成為流式處理利器

作者簡介：

Neha Narkhede， Confluent聯合創始人、CTO，曾在LinkedIn主導基于Kafka和Apache Samza構建流式基礎設施，是Kafka作者之一。

Gwen Shapira， Confluent系統架構師，幫助客戶構建基于Kafka的系統，在可伸縮數據架構方面擁有十余年經驗；曾任Cloudera公司解決方案架構師。另著有《Hadoop應用架構》。

Todd Palino， LinkedIn主任級SRE，負責部署管理大型的Kafka、Zookeeper和Samza集群。

【譯者簡介】

薛命燈，畢業于廈門大學軟件學院，十余年軟件開發和架構經驗，InfoQ高級社區編輯。譯有《硅谷革命》《生產微服務》等書。買粉絲買粉絲CodeDeep。