目錄：
1、kafka簡介 什麼是kafka？ 設計目標是什麼？
2、kafka的優缺點
3、kafka中專業術語解釋說明
官方網站： http://kafka.apache.org/intro
kafka中文教程 http://orchome.com/kafka/index
1/ kafka 簡介
Kafka是最初由Linkedin公司開發，是一個分佈式、分區的、多副本的、多訂閱者，基於zookeeper協調的分佈式日誌系統（也可以當做MQ系統），常見可以用於web/nginx日誌、訪問日誌，消息服務等等，Linkedin於2010年貢獻給了Apache基金會併成爲頂級開源項目。//發展近十年的項目 目前很成熟了
主要應用場景是：日誌收集系統和消息系統。
Kafka主要設計目標如下：
（1）以時間複雜度爲O(1)的方式提供消息持久化能力，即使對TB級以上數據也能保證常數時間的訪問性能。
（2）高吞吐率。即使在非常廉價的商用機器上也能做到單機支持每秒100K條消息的傳輸。
（3）支持Kafka Server間的消息分區，及分佈式消費，同時保證每個partition內的消息順序傳輸。
（4）同時支持離線數據處理和實時數據處理。
（5）Scale out:支持在線水平擴展
Kafka就是一種發佈-訂閱模式 在發佈-訂閱消息系統中，消息被持久化到一個topic中。與點對點消息系統不同的是，消費者可以訂閱一個或多個topic，消費者可以消費該topic中所有的數據，同一條數據可以被多個消費者消費，數據被消費後不會立馬刪除。在發佈-訂閱消息系統中，消息的生產者稱爲發佈者，消費者稱爲訂閱者。 // 發佈者發送到topic的消息，只有訂閱了topic的訂閱者纔會收到消息。
爲什麼要使用kafka？
1、作爲緩存
2、解（系統）耦合
3、時間小於10ms 基本上是一種實時的
他能簡化，我們系統的設計，提示公司的開發速度，和效率
2/kafka優點
1、解耦
//S 系統與 A、B、C 系統緊密耦合。由於需求變動，A 系統修改了相關代碼，S 系統也需要調整 A 相關的代碼。 過幾天，C 系統需要刪除，S 緊跟着刪除 C 相關代碼；又過了幾天，需要新增 D 系統，S 系統又要添加與 D 相關的代碼；再過幾天，程序猿瘋了 這樣各個系統緊密耦合，不利於維護，也不利於擴展。現在引入 MQ，A 系統變動，A 自己修改自己的代碼即可；C 系統刪除，直接取消訂閱；D 系統新增，訂閱相關消息即可。這樣通過引入消息中間件，使各個系統都與 MQ 交互，從而避免它們之間的錯綜複雜的調用關係。
2、冗餘（副本）
//有些情況下，處理數據的過程會失敗。除非數據被持久化，否則將造成丟失。消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險。許多消息隊列所採用的"插入-獲取-刪除"範式中，在把一個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。
3、擴展性
//因爲消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調節參數。擴展就像調大電力按鈕一樣簡單。
4、靈活性&峯值處理能力(削峯)
//數據庫的處理能力是有限的，在峯值期，過多的請求落到後臺，一旦超過系統的處理能力，可能會使系統掛掉。 系統的處理能力是 2k/s，MQ 處理能力是 8k/s，峯值請求 5k/s，MQ 的處理能力遠遠大於數據庫，在高峯期，請求可以先積壓在 MQ 中，系統可以根據自身的處理能力以 2k/s 的速度消費這些請求。這樣等高峯期一過，請求可能只有 100/s，系統可以很快的消費掉積壓在 MQ 中的請求。
5、可恢復性
//系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復後被處理。
6、順序保證
//在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，並且能保證數據會按照特定的順序來處理。Kafka保證一個Partition內的消息的有序性。
7、緩衝
//在任何重要的系統中，都會有需要不同的處理時間的元素。例如，加載一張圖片比應用過濾器花費更少的時間。消息隊列通過一個緩衝層來幫助任務最高效率的執行———寫入隊列的處理會儘可能的快速。該緩衝有助於控制和優化數據流經過系統的速度。 在用戶請求和數據庫之間 MQ起到很大到緩衝作用 在削峯上有很大到體現
8、異步通信
//很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但並不立即處理它。想向隊列中放入多少消息就放多少，然後在需要的時候再去處理它們。
優點小結：
1、單機吞吐量：
10萬級別，這是kafka最大的優勢，就是他的吞吐量高，一般配合大數據類的系統來進行實施數據計算，日誌採集等場景
2、topic數據對吞吐量的影響：
topic從幾十個到上百個不等，但是topic越多，會很大程度的影響吞吐量，所以在同等機器下，kafka經量保證topic數量不要過度。如果要支撐大規模的topic的話，需要增加更多的集羣資源。
3、時效性：
延遲控制在ms以內
4、可用性：
非常高，kafka是分佈是的，一個數據多個副本，少數機器的宕機，不會丟數據，不會導致不可用
5、消息可靠性
經過參數優化配置，消息可以做到0丟失
6、功能支持
功能較爲簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用，是事實上的標準
優劣勢總結
kafka的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供較高的吞吐量，ms級別的延遲，較高的可用性以及可靠性，而且是分佈式的，可以任意的擴展，同時kafka也是做好的是支撐少量的topic數量即可，保證其吞吐量，而且kafka唯一的一點劣勢就是可能出現就消息的重複消費(爲什麼會出現消息到重複消費，見後期博客內容)，那麼對數據準確性會產生影響，在大數據領域中以及日誌收集中，這點輕微可以忽略。 kafka的特性就是天然適合大數據實時計算以及日誌的收集。
3/kafka中專業術語解釋說明(相關概念)
在深入理解kafka之前，有必要先了解和弄懂kafka中會出現到的相關術語概念：
1、Broker：Kafka 集羣中包含的服務器。
//一個安裝kafka的服務器節點 Kafka 集羣包含一個或多個服務器，服務器節點稱爲broker。
broker存儲topic的數據。如果某topic有N個partition，集羣有N個broker，那麼每個broker存儲該topic的一個partition。
如果某topic有N個partition，集羣有(N+M)個broker，那麼其中有N個broker存儲該topic的一個partition，剩下的M個broker不存儲該topic的partition數據。
如果某topic有N個partition，集羣中broker數目少於N個，那麼一個broker存儲該topic的一個或多個partition。在實際生產環境中，儘量避免這種情況的發生，這種情況容易導致Kafka集羣數據不均衡。
比如我們有5個broker節點 那麼儘量創建的topic的partition分區個數爲5的倍數 10 20 30... 50都可以 這樣可以讓kafka的數據均勻分佈
2、Producer：消息生產者。
//生產者即數據的發佈者，該角色將消息發佈到Kafka的topic中。broker接收到生產者發送的消息後，broker將該消息追加到當前用於追加數據的segment文件中。生產者發送的消息，存儲到一個partition中，生產者也可以指定數據存儲的partition。
3、Consumer：消息消費者。
//消費者可以從broker中讀取數據。消費者可以消費多個topic中的數據。
4、Consumer Group：每個 Consumer 都屬於一個 Consumer Group，每條消息只能被 Consumer Group 中的一個 Consumer 消費，但可以被多個 Consumer Group 消費。
//每個Consumer屬於一個特定的Consumer Group（可爲每個Consumer指定group name，若不指定group name則屬於默認的group）。
5、Topic：消息的類別。每條消息都屬於某個 Topic，不同的 Topic 之間是相互獨立的，即 Kafka 是面向 Topic 的。
//每條發佈到Kafka集羣的消息都有一個類別，這個類別被稱爲Topic。（物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處） 類似於數據庫的表名
6、Partition：每個 Topic 分爲多個 Partition，Partition 是 Kafka 分配的單位。Kafka 物理上的概念，相當於一個目錄，目錄下的日誌文件構成這個 Partition。
//topic中的數據分割爲一個或多個partition。每個topic至少有一個partition。每個partition中的數據使用多個segment文件存儲。partition中的數據是有序的，不同partition間的數據丟失了數據的順序。如果topic有多個partition，消費數據時就不能保證數據的順序。在需要嚴格保證消息的消費順序的場景下，需要將partition數目設爲1。
7、Replica：Partition 的副本，保障 Partition 的高可用。
//每個topic將被分成多個partition(區),此外kafka還可以配置partitions需要備份的個數(replicas)
8、Leader：Replica 中的一個角色， Producer 和 Consumer 只跟 Leader 交互。
//每個partition有多個副本，其中有且僅有一個作爲Leader，Leader是當前負責數據的讀寫的partition。
9、Follower：Replica 中的一個角色，從 Leader 中複製數據。
//Follower跟隨Leader，所有寫請求都通過Leader路由，數據變更會廣播給所有Follower，Follower與Leader保持數據同步。如果Leader失效，則從Follower中選舉出一個新的Leader。當Follower與Leader掛掉、卡住或者同步太慢，leader會把這個follower從“in sync replicas”（ISR）列表中刪除，重新創建一個Follower。
基於replicated方案,那麼就意味着需要對多個備份進行調度;每個partition都有一個server爲"leader";leader負責所有的讀寫操作,如果leader失效,那麼將會有其他follower來接管(成爲新的leader);follower只是單調的和leader跟進,同步消息即可..由此可見作爲leader的server承載了全部的請求壓力,因此從集羣的整體考慮,有多少個partitions就意味着有多少個"leader",kafka會將"leader"均衡的分散在每個實例上,來確保整體的性能穩定.
其中partition leader的位置(host:port)註冊在zookeeper中
10、Controller（調節器）：Kafka 集羣中的其中一個服務器，用來進行 Leader Election（leader 選舉） 以及各種 Failover（故障轉移）。
//Controller（調節器） 節點都分片在 zk中記載 在哪個broker節點上 以及 controller 創建的時間 //查看方式 get /kafkagroup/controller
11、Zookeeper：Kafka 通過 Zookeeper 來存儲集羣的 Meta 信息。(問題：kafka的哪些元數據信息在zk中，見後期博客)
12、Coordinator：類似 Broker 中選了一個 Controller 出來，消費也要從 Broker 中選一個 Coordinator，用於分配 Partition。
————————————————————————————————————————————————————————————————————————————————————————————————————————————————
參考鏈接：
kafka基本原理重要概念優缺點 https://blog.51cto.com/12445535/2353399
架構成長之路：Kafka設計原理看了又忘，忘了又看？一文讓你掌握 https://www.toutiao.com/i6714606866355192328/
Kafka學習之路 （一）Kafka的簡介 https://www.cnblogs.com/qingyunzong/p/9004509.html
消息隊列kafka特性 https://blog.csdn.net/qq_36236890/article/details/81174504