國際慣例的簡單介紹
kafka是一個分佈式、支持分區的（partition）、多副本的（replica），基於zookeeper協調的分佈式消息系統，有着如下優秀的特性：
高吞吐、低延遲：kafka每秒可以處理幾十萬條消息，延遲最低只有幾毫秒，每個topic可以分多個分區, 消費者組對分區進行消費操作
可擴展性：kafka集羣支持熱擴展
持久性、可靠性：消息被持久化到本地磁盤，並且支持數據備份防止數據丟失
容錯性：允許集羣中節點失敗（若副本數量爲n,則允許n-1個節點失敗）
高併發：支持多個客戶端同時讀寫
基礎概念介紹：
topic主題：一組消息抽象歸納爲一個topic，是對消息的一個邏輯分類，簡單理解就是一個隊列名
message消息：kafka通信的基本單位，主要由offset key value timestamp構成
partition分區：維護kafka消息數據的最小單位，一個topic可包含多個partition，每個分區由一系列有序且不可
變的消息組成，partition在物理上對應爲一個文件夾，partition的命名規則爲topic名稱加”-”，再加分區編號
replica副本：是partition的備份，一個partition可以存在1個or多個replica，分佈在集羣不同代理上
leader副本與follower副本：爲保證一個partition的多個replica之間數據的一致性，kafka會在replica中選擇一個作爲
leader副本，其餘爲follower副本，只有leader副本負責客戶端的write/read請求，follower副本從leader副本同步數
據，若leader副本失效，則選舉其他follower副本爲新的leader副本
offset偏移量：任何發佈到分區的message會被直接追加到日誌文件尾部，而每條message在日誌文件中的位置都會
對應一個按序遞增的offset，是一個partition下嚴格有序的邏輯值，不代表message在磁盤上的物理位置
日誌段logSegment：一個日誌被劃分爲多個日誌段，是kafka日誌對象分片的最小單位，是一個邏輯概念，一個日誌
段對應磁盤上一個具體的日誌文件和兩個索引文件；日誌文件以.log爲後綴，保存消息實際數據，索引文件分別
以.index與.timeindex爲後綴，分別表示消息偏移量索引文件與消息時間戳索引文件
broker代理：kafka集羣中的機器/服務被稱爲broker，一個kafka集羣由一個or多個kafka代理組成，每個broker都要有 一個非負整數的唯一標識id，通過broker.id配置
producer生產者：負責將消息發送給broker，即向kafka代理髮送消息的客戶端
consumer消費者：kafka中通過zookeeper，負責以pull拉取方式拉取數據的客戶端，每個consumer也有一個全局唯 一的id，可通過client.id配置
consumer group消費者組：kafka中每一個消費者都屬於一個特定的consumer group，通過group.id配置，一個 consumer group可以包含多個consumer，若不指定consumer group，則默認屬於test-consumer-group，同一topic的 一條message只能被同一consumer group下的某一個consumer消費，但不同的consumer group的consumer可同時 消費該message，consumer group是kafka用來實現對一個topic消息進行廣播(consumer屬於不同consumer group時) 與單播(consumer屬於同一consumer group)的手段
ISR同步副本列表：該列表保存的是與leader副本保持消息同步的所有副本對應的brokerId，若一個follower副本宕機 或落後太多，則該follower副本將從ISR列表移除
zookeeper：kafka使用zookeeper保存如代理節點信息、Kafka集羣信息、舊版消費者信息及其消費者偏移量信息、主 題信息、分區狀態信息、分區副本分配方案信息、動態配置信息等元數據信息，kafka在啓動or運行過程中會在 zookeeper上創建相應的節點來保存元數據信息，kafka通過監聽機制在這些節點註冊相應的監聽器來監聽節點元數據 的變化，從而由zookeeper負責維護管理kafka集羣
kafka集羣的基本架構圖：
kafka對應的zookeeper中節點信息介紹：
生產者版本介紹：
舊版生產者(scala實現)：在發送消息時候根據配置producer.type來決定是同步/異步發送,不同發送方式,執行邏輯不同
異步發送邏輯如下：
同步發送邏輯如下：
同步/異步區別：異步模式會首先將消息存入到消息隊列，然後由一個獨立的線程判斷是否需要將數據向代理髮送
新版生產者(java實現)：設計思路上與舊版的異步模式類似,只是實現細節與採用的數據結構略有不同；而且舊版本 同步與異步模式是分開實現的,而新版本的同步模式是通過異步模式實現的；因爲新版本異步發送消息的 send(ProducerRecord<K, V> record)方法是返回一個Future<RecordMetadata>對象,只需調用Future的get()即可實現 消息同步發送(後面章節詳細介紹)
消費者版本介紹：
舊版消費者(scala實現)：分別爲SimpleConsumer和ZookeeperConsumerConnector，前者爲低級舊版消費者，後者 爲高級舊版消費者，兩者的區別如下：
新版消費者(java實現)：非線程安全,直接與指定的broker進行連接,無需依賴zookeeper,啓動消費者時不向zookeeper 註冊,而是由消費組協調器統一管理,已消費消息的偏移量提交後會保存到名爲”_consumer_offsets”的內部主題中,且提 供了一系列簡易的api(後面章節詳細介紹)
ISR同步機制：
ISR集合：指目前可用且消息量與leader副本相差不多的副本集合
ISR集合中的副本須滿足以下條件：
A. 副本所在節點必須與zookeeper保持連接
B. 副本最後一條消息的offset與leader副本最後一條消息的offset之間的差值不能超過指定閾值,可通過 replica.lag.max.messages配置來指定
C. 副本需一直同步leader副本的消息,若在指定時間閾值內未同步,則從ISR集合中移除,可通過replica.lag.time.max.ms 配置來指定
每個分區的leader副本會維護自己分區的ISR集合,寫請求首先在leader副本上處理,之後follower副本會從leader副本拉 取寫入消息,當follower副本出現異常違反上面3個條件的1個or多個,則會被剔除ISR集合,等異常恢復後又會與leader副本 進行同步,當follower副本“追上”leader副本時候,又會重新加入ISR集合
HW(High WaterMark)：HW標記了一個特殊的offset,當消費者處理消息時候,只能拉取到HW之前的消息,HW之後的消息 對消費者來說是不可見的(即使已經在leader副本處理了),只有當ISR集合中全部的follower副本都拉取HW指定消息進行 同步後,leader副本會遞增HW的值,此時消費者纔可以消費到上一個HW之前的消息,此時即便leader副本損壞,也不會丟 數據；HW也是由leader副本管理的
LEO(Log End Offset)：所有副本都會有的一個offset標記,指向追加到當前副本的最後一個消息的offset,當生產者向 leader副本追加消息時候,leader副本的LEO標記會遞增;當follower副本成功從leader副本拉取消息並更新到本地時, follower副本的LEO就會增加
例子,針對offset=11的消息,ISR集合、HW和LEO是如何協調工作的：
① producer向此partition推送消息
② leader副本將消息追加到log中並遞增其LEO
③ follower副本從leader副本拉取消息進行同步
④ follower副本將拉取到的消息更新到本地log中並遞增自身LEO
⑤ 當ISR集合中所有副本都完成對offset=11的消息的同步,leader副本會遞增HW
這部分完~