每個分區（Partition）都是有序的(所以每壹個Partition內部都是有序的)，不變的記錄序列，這些記錄連續地附加到結構化的提交日誌中。分區中的每個記錄均分配有壹個稱為偏移的順序ID號，該ID 唯壹地標識分區中的每個記錄。
每個消費者保留的唯壹元數據是該消費者在日誌中的偏移量或位置。此偏移量由使用者控制：通常，使用者在讀取記錄時會線性地推進其偏移量，但實際上，由於位置是由使用者控制的，因此它可以按喜歡的任何順序使用記錄。例如，使用者可以重置到較舊的偏移量以重新處理過去的數據，或者跳到最近的記錄並從“現在”開始使用。（類似於遊標指針的方式順序處理數據，並且該指標可以任意移動）
分區的設計結構
生產者分區策略是 決定生產者將消息發送到哪個分區的算法， 主要有以下幾種：
kafka消息的有序性，是采用消息鍵保序策略來實現的。 壹個topic，壹個partition(分割)，壹個consumer，內部單線程消費，寫N個內存queue，然後N個線程分別消費壹個內存queue。
kafka發送進行消息壓縮有兩個地方，分別是生產端壓縮和Broker端壓縮。
生產者端壓縮 生產者壓縮通常采用的GZIP算法這樣 Producer 啟動後生產的每個消息集合都是經 GZIP 壓縮過的，故而能很好地節省網絡傳輸帶寬以及 Kafka Broker 端的磁盤占用。 配置參數：
Broker壓縮 大部分情況下 Broker 從 Producer 端接收到消息後僅僅是原封不動地保存而不會對其進行任何修改，但以下情況會引發Broker壓縮
消費者端解壓 Kafka 會將啟用了哪種壓縮算法封裝進消息集合中，在Consummer中進行解壓操作。
kafka提供以下特性來保證其消息的不丟失，從而保證消息的可靠性
生產者確認機制 當 Kafka 的若幹個 Broker（根據配置策略，可以是壹個，也可以是ALL） 成功地接收到壹條消息並寫入到日誌文件後，它們會告訴生產者程序這條消息已成功提交。此時，這條消息在 Kafka 看來就正式變為“已提交”消息了。 設置 acks = all。acks 是 Producer 的壹個參數，代表了妳對“已提交”消息的定義。如果設置成 all，則表明所有副本 Broker 都要接收到消息，該消息才算是“已提交”。這是最高等級的“已提交”定義。
生產者失敗回調機制 生產者不要使用 producer.send(msg)，而要使用 producer.send(msg, callback)。記住，壹定要使用帶有回調通知的 send 方法。producer.send(msg, callback) 采用異步的方式，當發生失敗時會調用callback方法。
失敗重試機制 設置 retries 為壹個較大的值。這裏的 retries 同樣是 Producer 的參數，對應前面提到的 Producer 自動重試。當出現網絡的瞬時抖動時，消息發送可能會失敗，此時配置了 retries > 0 的 Producer 能夠自動重試消息發送，避免消息丟失。
消費者確認機制 確保消息消費完成再提交。Consumer 端有個參數 enable.auto.commit，最好把它設置成 false，並采用手動提交位移的方式。就像前面說的，這對於單 Consumer 多線程處理的場景而言是至關重要的。
副本機制 設置 replication.factor >= 3。這也是 Broker 端的參數。其實這裏想表述的是，最好將消息多保存幾份，畢竟目前防止消息丟失的主要機制就是冗余。 設置 min.insync.replicas > 1。這依然是 Broker 端參數，控制的是消息至少要被寫入到多少個副本才算是“已提交”。設置成大於 1 可以提升消息持久性。在實際環境中千萬不要使用默認值 1。 確保 replication.factor > min.insync.replicas。如果兩者相等，那麽只要有壹個副本掛機，整個分區就無法正常工作了。我們不僅要改善消息的持久性，防止數據丟失，還要在不降低可用性的基礎上完成。推薦設置成 replication.factor = min.insync.replicas + 1。
限定Broker選取Leader機制 設置 unclean.leader.election.enable = false。這是 Broker 端的參數，它控制的是哪些 Broker 有資格競選分區的 Leader。如果壹個 Broker 落後原先的 Leader 太多，那麽它壹旦成為新的 Leader，必然會造成消息的丟失。故壹般都要將該參數設置成 false，即不允許這種情況的發生。
由於kafka生產者確認機制、失敗重試機制的存在，kafka的消息不會丟失但是存在由於網絡延遲等原因造成重復發送的可能性。 所以我們要考慮消息冪等性的設計。 kafka提供了冪等性Producer的方式來保證消息冪等性。使用 ****的方式開啟冪等性。
冪等性 Producer 的作用範圍：
Kafka事務 事務型 Producer 能夠保證將消息原子性地寫入到多個分區中。這批消息要麽全部寫入成功，要麽全部失敗。另外，事務型 Producer 也不懼進程的重啟。Producer 重啟回來後，Kafka 依然保證它們發送消息的精確壹次處理。 同樣使用 的方式開啟事務。
consumer group是kafka提供的可擴展且具有容錯性的消費者機制。它是由壹個或者多個消費者組成，它們***享同壹個Group ID. 組內的所有消費者協調在壹起來消費訂閱主題(subscribed topics)的所有分區(partition)。當然，每個分區只能由同壹個消費組內的壹個consumer來消費。
consummer group有以下的特性：
消費者位置 消費者位置，即位移。 消費者在消費的過程中需要記錄自己消費了多少數據。 位移提交有自動、手動兩種方式進行位移提交。
Kafka通過壹個內置Topic(__consumer_offsets)來管理消費者位移。
rebalance本質上是壹種協議，規定了壹個consumer group下的所有consumer如何達成壹致來分配訂閱topic的每個分區。
Kafka提供了壹個角色：coordinator來執行對於consumer group的管理。 Group Coordinator是壹個服務，每個Broker在啟動的時候都會啟動壹個該服務。Group Coordinator的作用是用來存儲Group的相關Meta信息，並將對應Partition的Offset信息記錄到Kafka內置Topic(__consumer_offsets)中。
Rebalance 過程分為兩步：Join 和 Sync。 Join 顧名思義就是加入組。這壹步中，所有成員都向coordinator發送JoinGroup請求，請求加入消費組。壹旦所有成員都發送了JoinGroup請求，coordinator會從中選擇壹個consumer擔任leader的角色，並把組成員信息以及訂閱信息發給leader——註意leader和coordinator不是壹個概念。leader負責消費分配方案的制定。
Sync，這壹步leader開始分配消費方案，即哪個consumer負責消費哪些topic的哪些partition。壹旦完成分配，leader會將這個方案封裝進SyncGroup請求中發給coordinator，非leader也會發SyncGroup請求，只是內容為空。coordinator接收到分配方案之後會把方案塞進SyncGroup的response中發給各個consumer。這樣組內的所有成員就都知道自己應該消費哪些分區了。