kafka深入研究之路(2) kafka簡介與專業術語解釋說明

目錄：
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