1、消息引擎系統前端
這類系統引覺得豪的消息傳遞屬性，像引擎同樣，具有某種能量轉換傳輸的能力java
消息引擎系統是一組規範，企業利用這組規範在不一樣系統之間傳遞語義準確的消息，實現鬆耦合的異步式數據傳遞。通俗地講就是系統A發送消息給消息引擎系統，系統B從消息引擎系統讀取系統A的消息數據庫
既然消息引擎系統是用於不一樣系統之間傳輸消息的，如何設計待傳輸消息的格式，提供可重用性及通用性。kafka使用的是二進制的字節序列，固然消息仍是結構化的，只是在使用以前都要將其轉換成二進制的字節序列。安全
消息引擎系統還要設定具體的傳輸協議，即我用什麼方法把消息傳輸出去：性能優化
一、點對點模型：也叫消息隊列模型，系統A發送的消息只能被系統B接收，其餘任何系統都不能讀取A發送的消息服務器
二、發佈/訂閱模型：一個主題(Topic)，能夠理解爲消息容器。多個發佈者向相同的主題發送消息，而訂閱者也可能存在多個，它們都能接收到相同主題的消息微信
kafka同時支持這兩種消息引擎模型網絡
做用：削峯填谷和鬆耦合架構
一、削峯填谷就是指緩衝上下游瞬時突發流量，使其平滑。一旦有了消息引擎系統，它可以有效地對抗上游的流量衝擊，真正作到將上游的「峯」填滿到「谷」中，避免了流量的震盪框架
二、發送方和接收方的鬆耦合，簡化了應用的開發，減小了系統間沒必要要的交互
相似於秒殺這樣的業務時，上游訂單流量會瞬時增長，可能出現的結果就是直接壓垮下游子系統服務（調用支付寶和微信接口、查詢登陸信息、商品信息等）。當引入kafka後，上游訂單服務再也不直接與下游子服務進行交互。當新訂單生成後它僅僅是向kafka broker發送一條訂單消息便可。下游各個子服務訂閱對應的主題，並實時從該主題的各自分區（Partition）中獲取訂單消息進行處理，從而實現上游訂單服務與下游訂單處理服務解耦。這樣當出現秒殺業務時，kafka可以將瞬時增長的訂單流量所有以消息形式保存在對應的主題中，既不影響上游服務的TPS，同時給下游子服務留出充足的時間消費它們。
2、kafka術語
kafka屬於分佈式的消息引擎系統，它的主要功能是提供一套完備的消息發佈與訂閱解決方案。在kafka中，發佈訂閱的對象是主題（Topic），你能夠爲每一個業務、每一個應用甚至是每類數據都建立專屬的主題。
客戶端：
一、生產者（Producer）
向主題發佈消息的客戶端應用程序，生產者程序一般持續不斷地向一個或多個主題發送消息。
二、消費者（Consumer）
訂閱主題消息的客戶端應用程序，消費者也可以同時訂閱多個主題的消息。
咱們把生產者和消費者統稱爲客戶端（Clients），你能夠同時運行多個生產者和消費者實例，這些實例會不斷地向kafka集羣中的多個主題生產和消費消息。
服務端：
kafka的服務器端由被稱爲Broker的服務進程構成，即一個kafka集羣由多個Broker組成，Broker負責接收和處理客戶端發送過來的請求，以及對消息進行持久化。
雖然多個Broker進程可以運行在同一臺機器上，但更常見的作法是將不一樣的Broker分散運行在不一樣的機器上，這樣若是集羣中某一臺機器宕機，即便在它上面運行的全部Broker進程都掛掉了，其餘機器上的Broker也依然可以對外提供服務。這其實就是kafka提供高可用的手段之一。
實現高可用的另外一個手段就是備份機制（Replication）。就是把相同的數據拷貝到多臺機器上，而這些相同的數據拷貝在kafka中被稱爲副本（Replica）。副本的數量是能夠配置的，這些副本保存着相同的數據，但卻有不一樣的角色和做用。
kafka定義了兩類副本：領導者副本（Leader Replica）和追隨者副本（Follower Replica）。前者對外提供服務，這裏的對外指的是與客戶端程序進行交互；而後者只是被動地追隨領導者副本而已，不能與外界進行交互。可是好比MySQL的從庫是能夠處理讀操做的，可是在kafka中追隨者副本不會對外提供服務。
副本的工做機制：生成者老是向領導者副本寫消息；而消費者老是從領導者副本讀消息。至於追隨者副本，只作一件事就是向領導者副本發送請求，請求領導者把最新生產的消息發給它，這樣它能保持與領導者的同步。
伸縮性即所謂的Scalability，是分佈式系統中很是重要且必需要謹慎對待的問題。什麼是伸縮性？如kafka，雖然有了領導者副本和追隨者副本，但若是領導者副本積累了太多的數據以致於單臺Broker機器都沒法容納，此時該怎麼辦？一個很天然的想法就是可否把數據分割成多份保存在不一樣的Broker上，kafka就是這麼設計的，這種機制就是所謂的分區（Partitioning）。
kafka中的分區機制指的是將每一個主題劃分紅多個分區，每一個分區是一組有序的消息日誌。生成者生成的每條消息只會被髮送到一個分區中，也就是說若是向一個雙分區的主題發送一條消息，這條消息要麼在分區0中，要麼在分區1中。kafka的分區編號是從0開始的，若是主題有100個分區，那麼它們的分區號就是從0到99。
實際上，副本是在分區這個層級定義的。每一個分區下能夠配置若干個副本，其中只能有一個領導者副本和N-1個追隨者副本。生產者向分區寫入消息，每條消息在分區中的位置信息由一個叫位移（Offset）的數據來表徵。分區位移老是從0開始，假設一個生產者向一個空分區寫入了10條消息，那麼這10條消息的位移依次是0、一、二、.....、9。
kafka的三層消息架構：
- 第一層是主題層，每一個主題能夠配置M個分區，而每一個分區又能夠配置N個副本
- 第二層是分區層，每一個分區的N個副本只能有一個領導者副本，對外提供服務；其餘N-1個副本是追隨者副本，只是提供數據冗餘做用。
- 第三層是消息層，分區中包含若干條消息，每條消息的位移從0開始，依次遞增。
- 最後，客戶端程序只能與分區的領導者副本進行交互
kafka Broker如何持久化數據：
kafka使用消息日誌（Log）來保存數據，一個日誌就是磁盤上一個只能追加寫消息的物理文件。由於只能追加寫入，故避免了緩慢的隨機I/O操做，改成性能較好的順序I/O寫操做，這也是實現kafka高吞吐量特性的一個重要手段。若是不停地向一個日誌寫入消息，最終也會耗盡全部磁盤空間，所以kafka必然要按期地刪除消息以回收磁盤。
kafka經過日誌段機制刪除消息。在kafka底層，一個日誌又進一步細分紅多個日誌段，消息被追加寫到當前最新的日誌段中，當寫滿了一個日誌段後，kafka會自動切分出一個新的日誌段，並將老的日誌段封存起來。kafka在後臺還有定時任務會按期地檢查老的日誌段是否可以被刪除，從而實現回收磁盤空間的目的。
消費者組：
在kafka中實現點對點模型的方法就是引入消費者組。所謂的消費者組，指的是多個消費者實例（能夠是運行消費者應用的進程，也能夠是一個線程，它們都稱爲一個消費者實例）共同組成一個組來消費一組主題。這組主題中的每一個分區都只會被組內的一個消費者實例消費，其餘消費者實例不能消費它。引入消費者組主要是爲了提高消費者端的吞吐量，多個消費者實例同時消費，加速整個消費端的吞吐量。
kafka的重平衡：
消費者組裏面的全部消費者實例不只瓜分訂閱主題的數據，並且它們還能彼此協助。假設某個實例掛掉了，kafka會自動檢測到，而後把這個掛掉的實例以前負責的分區轉移給其餘消費者。可是因爲重平衡引起的消費者問題比比皆是，目前社區上不少的重平衡Bug都無力解決。
消費者位移：
每一個消費者在消費消息的過程當中必然須要有一個字段記錄它當前消費到了分區的哪一個位置上，這個字段就是消費者位移（Consumer Offset）。注意，這和上面所說的位移徹底不是一個概念。上面的位移表徵的是分區內的消息位置，它是不變的，即一旦消息被成功寫入到一個分區上，它的位移值就是固定的了。而消費者位置則不一樣，它多是隨時變化的，畢竟它是消費者消費進度的指示器。每一個消費者有着本身的消費者位移，所以必定要區分開兩個位移。我我的把消息在分區中的位置稱爲分區位移，而把消費者端的位移稱爲消費者位移。
總結：
- 消息：Record。這裏的消息就是指kafka處理的主要對象。
- 主題：Topic。主題是承載消息的邏輯容器，在實際使用中多用來區分具體的業務。
- 分區：Partition。一個有序不變的消息敘序列。每一個主題下能夠有多個分區。
- 消息位移：Offset。表示分區中每條消息的位置信息，是一個單調遞增且不變的值。
- 副本：Repilca。kafka中同一條消息可以被拷貝到多個地方以提供數據冗餘，這些地方就是所謂副本。副本分爲領導者副本和追隨者副本，各自有不一樣的角色劃分。副本是在分區層級下的，每一個分區可配置多個副本實現高可用。
- 生產者：Producer。向主題發佈新消息的應用程序。
- 消費者：Consumer。從主題訂閱新消息的應用程序。
- 消費者位移：Consumer Offset。表徵消費者消費進度，每一個消費者都有本身的消費者位移。
- 消費者組：Consumer Group。多個消費者實例共同組成的一個組，同時消費多個分區以實現高吞吐。
- 重平衡：Rebalance。消費者組內某個消費者實例掛掉後，其餘消費者實例自動從新分配訂閱主題分區的過程。這也是kafka消費者端實現高可用的重要手段。
概念圖：
3、kafka是消息引擎系統，也是一個分佈式流處理平臺
kafka是Linkedin公司內部孵化的項目，Linkedin最開始有強烈的數據強實時處理方面的需求，其內部的諸多子系統要執行多種類型的數據處理與分析，主要包括業務系統和應用程序性能監控，以及用戶行爲數據處理等。
當時他們碰到的主要問題包括：
一、數據正確性不足。
二、系統高度定製化，維護成本高。各個業務子系統都須要對接數據收集模塊，引入了大量的定製開銷和人工成本。
爲了解決這些問題，Linkedin工程師嘗試過使用ActiveMQ來解決這些問題，但效果並不理想，顯然是須要有一個系統，而這個系統就是kafka。
kafka在設計之初就旨在提供三個方面的特性：
一、提供一套API實現生產者和消費者；
二、下降網絡傳輸和磁盤存儲開銷；
三、實現高伸縮性架構。
開源以後的kafka被愈來愈多的公司應用到它們企業內部的數據管道中，特別是在大數據工程領域，kafka在承接上下游、串聯數據流管道方面發揮了重要做用：全部的數據幾乎都要從一個系統流入kafka而後再流向下游的另外一個系統中。這樣的方式引起了一個思考：與其我把數據從一個系統傳遞到下一個系統中作處理，我爲什麼不本身實現一套流處理框架呢？基於這個考量，kafka社區於0.10.0.0版本正式推出了流處理組件kafka streams，也正是從這個版本開始，kafka正式變身爲分佈式的流處理平臺，而不只僅是消息引擎系統了。今天kafka是和Apache Storm、Apace Spark和Apace Flink同等級的實時流處理平臺。
kafka與其餘主流大數據流式計算框架相比，優點在兩個方面：
一、更容易實現端到端的正確性（Correctness）。實現正確性是流處理可以匹敵批處理的基石。正確性一直是批處理的強項，而實現正確性的基石則是要求框架能提供精確一次（Exactly-once）處理語義，即處理一條消息有且只有一次機會可以影響系統的狀態。目前主流的大數據流處理框架都宣稱實現了精確一次處理語義，但這是有限定條件的，即它們只能實現框架內的的精確一次處理語義，沒法實現端到端的。由於當這些框架與外部消息引擎系統結合使用時，它們沒法影響到外部系統的處理語義，因此若是你搭建了一套環境使得Spark從kafka讀取消息以後進行有狀態的數據計算，最後再寫回kafka，那麼你只能保證在Spark內部，這條消息對於狀態的影響只有一次。可是計算結果有可能屢次寫入到kafka，由於它們不能控制kafka的語義處理。相反地，由於kafka全部的數據流轉和計算都在kafka內部完成，故kafka能夠實現端到端的精確一次處理語義。
二、它本身對於流式計算的定位。kafka Streams是一個用於搭建實時流處理的客戶端庫而不是一個完整的功能系統。即你不能指望着kafka提供相似於集羣調度、彈性部署等開箱即用的運維特性，你須要本身選擇適合的工具或系統來幫助kafka流處理應用實現這些功能。對於大型公司的流處理平臺必定是大規模部署的，所以具有集羣調度功能以及靈活的部署方案是不可或缺的。可是對於中小企業，它們的流處理數據量並不巨大，邏輯也並不複雜，部署幾臺或十臺機器足以應付。在這樣的需求下，搭建重量級的完整平臺實在是殺雞焉用牛刀，而這時使用kafka流處理組件是很是合適的。
總結：Apace Kafka從一個優秀的消息引擎系統起家，逐漸演變成如今分佈式的流處理平臺。不只要熟練掌握它做爲消息引擎系統的非凡特性及使用技巧，最好還要多瞭解下其流處理組件的設計與案例應用。
4、kafka的版本選擇
你可能據說過Apache Storm、Apache Spark Streaming和Apache Flink，它們在大規模流處理領域但是響噹噹的名字。而kafka畢竟是從消息引擎半路出家轉型成流處理平臺，它在流處理方面的表現還須要通過時間的檢驗。
kafka的流處理生態圈：
kafka Streams組件提供實時處理流數據的能力。
kafka Connect經過一個個具體的鏈接器（Connector），串聯起上下游的外部系統。
kafka的版本：
這裏不是指它的版本，而是指存在多個組織或公司發佈不一樣的kafka
一、Apache Kafka
最「正宗」的kafka，自kafka開源伊始，它便在Apache基金會孵化並最終畢業成爲頂級項目，它也被稱爲社區版kafka。它是後面其餘全部版本的基礎，Apache Kafka 是咱們學習和使用kafka的基礎。
特色：
（1）優點：它依然是開發人數最多、版本迭代速度最快的kafka。若是你使用碰到任何問題並提交問題到社區，社區都會比較及時地響應你。這對於咱們普通使用者來講無疑是很是友好的。
（2）劣勢：它僅僅提供最最基礎的組件，特別是前面提到的Kafka Connect而言，社區版只提供一種鏈接器，即讀寫磁盤文件的；鏈接器，而沒有與其餘外部系統交互的鏈接器。另外沒有提供任何監控框架或工具，顯然在線上環境不加監控確定是不可行的，你必然須要藉助第三方的監控框架實現對kafka的監控。目前有一些開源的監控框架能夠幫助用於監控kafka（好比kafka manager）
選擇場景：
若是你僅僅須要一個消息引擎系統亦或是簡單的流處理應用場景，同時須要對系統有較大把握度，那麼推薦使用Apache Kafka
二、Confluent Kafka
Confluent公司是kafka的3個創始人離開Linkedin創辦的，專一於提供基於kafka的企業級流處理解決方案。它主要從事商業化kafka工具開發，並在此基礎上發佈了Confluent Kafka。Confluent Kafka提供了一些Apache Kafka沒有的高級特性，好比跨數據中心備份、Schema註冊中心以及集羣監控工具等。
特色：
（1）優點：目前分爲免費版和企業版，前者和Apache Kafka很是像，除了常規的組件外，免費版還包含Schema註冊中心和REST proxy兩大功能，前者是幫助你集中管理kafka消息格式以實現數據前向/後向兼容，後者用開放HTTP接口的方式容許你經過網絡訪問kafka的各類功能，這兩個是Apache Kafka所沒有的。除此以外，免費版包含了更多的鏈接器，能夠無償使用。至於企業版，它提供的功能就更多了。最有用的當屬跨數據中心備份和集羣監控兩大功能，多個數據中心之間數據的同步以及對集羣的監控從來都是kafka的痛點。
（2）劣勢：Confluent公司暫時沒有發展國內業務，相關的資料以及技術支持都很欠缺，因此目前Confluent Kafka在國內的普及率比較低
選擇場景：
若是你須要用到kafka的一些高級特性，那麼推薦使用Confluent Kafka
三、Cloudera/Hortonworks Kafka
Cloudera提供的 CDH 和Hortonworks提供的 HDP 是很是著名的大數據平臺，裏面集成了目前主流的大數據框架，可以幫助用戶實現從分佈式存儲、集羣調度、流處理到機器學習、實時數據庫等全方位的數據處理。無論是CDH仍是HDP裏面都集成了Apache Kafka，所以我把這兩款產品中的kafka稱爲CDH Kafka和HDK Kafka。2018年10月兩家公司合併，共同打造世界領先的數據平臺。
特色：
（1）優點：經過便捷化的界面操做將kafka的安裝、運維、管理、監控所有統一在控制檯中，使用很是方便，全部的操做均可以在前端UI界面上完成，而沒必要去執行復雜的kafka命令。
（2）劣勢：這樣作的結果是直接下降你對kafka集羣的掌控程度，畢竟對下層kafka集羣一無所知。還有在於它的滯後性，因爲它有本身的發佈週期，可能包含的kafka版本不是最新的。
選擇場景：
若是你須要快速地搭建消息引擎系統，或者你須要搭建的是多框架構成的數據平臺且kafka只是其中一個組件，那麼推薦使用這些大數據雲公司提供的kafka。
不少小公司都以爲CDH很方便，安裝以後什麼都有了
5、Apache Kafka版本號
kafka在實際應用時，如何評判當前業務需求須要使用哪一個kafka版本，這就首先須要瞭解各個版本之間的差別和功能變化。並不是使用最新版本在任何場景下都適用。
kafka版本命令：
在官網下載時，會看到這樣的版本：
前面的版本號是編譯kafka源碼的Scala編譯器版本，kafka服務器端的代碼徹底由Scala語言編寫。對於上面kafka-2.11-2.1.1，真正的kafka版本號實際是2.1.1，那麼這個2.1.1又表示什麼？前面的2表示大版本號（Major Version）；中間的1表示小版本號或次版本號（Minor Version）；最後的1表示修訂版本號（Patch號）。kafka社區在發佈1.0.0版本後，宣佈kafka版本命名規則正式從4位演進到3位，好比0.11.0.0版本就是4位版本號。總結來講，kafka版本號由3部分構成，即大版本號-小版本號-Patch號。
kafka版本演進：
目前總共演進了7個大版本，分別0.七、0.八、0.九、0.十、0.十一、1.0和2.0，其中的小版本和Patch本不少。若是你要向架構師轉型或者已然是架構師，那麼熟悉哪些版本引入了哪些重大的功能改進，那麼這些能夠幫助你進行技術選型、架構評估的重要依據。
一、0.7版本
最先開源時的的版本，只提供了最基礎的消息隊列功能，甚至連副本機制都沒有，實在沒有理由使用這個版本。
二、0.8版本
正式引入了副本機制，至此成爲了一個真正意義上完備的分佈式高可靠消息隊列解決方案。那時候生成和消費消息使用的仍是老版本的客戶端API，所謂的老版本是指當你用它們的API開發生成者和消費者應用時，你須要指定ZooKeeper的地址而非Broker的地址。老版本客戶端有不少的問題，特別是生產者API，它默認使用同步方式發送消息，可見其吞吐量必定不會過高。雖然它也支持異步的方式，但實際場景中可能會形成消息的丟失，所以0.8.2.0版本引入了新版本Producer API，即須要指定Broker地址的Producer。建議至少升級到0.8.2.2，由於該版本中老版本消費者API是比較穩定的，另外在該版本中，不要使用新版本Producer API，此時它的Bug還很是多。
三、0.9版本
這是一個重量級的大版本更迭，增長了基礎的安全認證/權限功能，同時使用java重寫了新版消費者API，還引入了Kafka Connect組件用於實現高性能的數據抽取。新版本Producer API在這個版本中算比較穩定了。和0.8.2引入新API相似，不要使用新版本Consumer API，由於Bug超多。
四、0.10版本
是里程碑式的大版本，由於該版本引入了kafka Streams。從這個版本起，kafka升級成分佈式流處理平臺，雖然此時的kafka Streams還基本不能線上部署使用。0.10大版本包含兩個小版本：0.10.1和0.10.2，它們主要功能變動都是在kafka Streams組件上。若是把kafka用做消息引擎，實際上該版本並無太多的功能提高。自0.10.2.2版本起，新版本Consumer API算是比較穩定了，還有該版本修復了一個可能致使Producer性能下降的Bug。基於性能若是你還在使用0.10大版本，你也應該升級到0.10.2.2。
五、0.11版本
引入兩個重量級的功能變動：
一個是提供冪等性Producer API以及事務API（kafka實現流處理結果正確性的基石）。此時的事務API存在一些Bug，不算穩定，另外事務API主要是爲Kafka Streams應用服務的。
另外一個是對kafka消息格式作了重構。可是由於格式變動引發消息格式轉換而致使的性能問題在生產環境中家常便飯，全部要謹慎對待0.11版本這個變化。
該版本中各個大功能組件都變得很是穩定了，國內該版本的用戶也不少，應該算是目前最流行的版本之一了。0.11.0.3這個版本的消息引擎功能已經很是完善了。
六、1.0和2.0版本
這兩個大版本主要是Kafka Streams的各類改進，在消息引擎方面並未引入太多的重大功能特性。若是你是Kafka Streams的用戶，至少選擇2.0.0版本吧。若是你在乎的依然是消息引擎，那麼這兩個大版本都是適合於生產環境的。
最後建議，不論你用哪一個版本，都請儘可能保持服務器端版本和客戶端版本一致，不然你將損失不少Kafka爲你提供的性能優化收益。