Kafka 溫故(一)：Kafka背景及架構介紹

一.Kafka簡介       

Kafka是分佈式發佈-訂閱消息系統。它最初由LinkedIn公司開發，使用Scala語言編寫，以後成爲Apache項目的一部分。Kafka是一個分佈式的，可劃分的，多訂閱者，冗餘備份的持久性的日誌服務。它主要用於處理活躍的流式數據（實時性的計算）。

在大數據系統中，經常會碰到一個問題，整個大數據是由各個子系統組成，數據須要在各個子系統中高性能，低延遲的不停流轉。傳統的企業消息系統並非很是適合大規模的數據處理。爲了已在同時搞定在線應用（消息）和離線應用（數據文件，日誌）Kafka就出現了。Kafka能夠起到兩個做用：

1.下降系統組網複雜度。
2.下降編程複雜度，各個子系統不在是相互協商接口，各個子系統相似插口插在插座上，Kafka承擔高速數據總線的做用。

二.Kafka的主要特色

1.同時爲發佈和訂閱提供高吞吐量。據瞭解，Kafka每秒能夠生產約25萬消息（50 MB），每秒處理55萬消息（110 MB）。
2.可進行持久化操做。將消息持久化到磁盤，所以可用於批量消費，例如ETL，以及實時應用程序。經過將數據持久化到硬盤以及replication防止數據丟失。
3.分佈式系統，易於向外擴展，能夠和ZooKeeper結合。全部的producer、broker和consumer都會有多個，均爲分佈式的。無需停機便可擴展機器。
4.消息被處理的狀態是在consumer端維護，而不是由server端維護。當失敗時能自動平衡。
5.支持online和offline的場景。

三.爲什麼使用消息系統

能夠經過消息隊列作系統之間的通訊，即系統之間的相互協調和調用

注意：使用消息隊列和SOA架構的區別？
          1.SOA是直接調用的（能夠經過RPC和HTTPClient來直接調用）
          2.使用消息隊列是經過消息的傳遞，來完成兩個系統之間的整合和調用

帶來的好處：
1.解耦合
      使用了消息隊列後，兩個系統之間沒有直接的調用關係，只是經過消息的傳遞來交互，兩個系統之間沒有侵入性。

2.提升系統的響應速度

       例子：訂單處理
      
        訂單支付成功的方法(){
                一、修改訂單狀態
                二、計算會員積分
                三、通知物流進行配送
      }
    注： 
           1.原來系統中這個三個步驟要同時處理後再返回，這樣比較耗時；
           2.如今能夠先處理用戶最關心的，最急需看到的修改訂單狀態成功信息，這樣能夠先處理"修改訂單狀態",而後馬上返回給用戶，
              後面的「計算會員積分」，「通知物流進行配送」，放入消息隊列中交給後面的系統繼續處理。
冗餘
      有些狀況下，處理數據的過程會失敗。除非數據被持久化，不然將形成丟失。消息隊列把數據進行持久化直到它們已經被徹底處理，經過這一方式規避了數據丟失風險。許多消息隊列所採用的"插入-獲取-刪除"範式中，在把一個消息從隊列中刪除以前，須要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。

擴展性
     由於消息隊列解耦了你的處理過程，因此增大消息入隊和處理的頻率是很容易的，只要另外增長處理過程便可。不須要改變代碼、不須要調節參數。擴展就像調大電力按鈕同樣簡單。

靈活性 & 峯值處理能力
      在訪問量劇增的狀況下，應用仍然須要繼續發揮做用，可是這樣的突發流量並不常見；若是爲以能處理這類峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列可以使關鍵組件頂住突發的訪問壓力，而不會由於突發的超負荷的請求而徹底崩潰。

可恢復性
系統的一部分組件失效時，不會影響到整個系統。消息隊列下降了進程間的耦合度，因此即便一個處理消息的進程掛掉，加入隊列中的消息仍然能夠在系統恢復後被處理。

順序保證
在大多使用場景下，數據處理的順序都很重要。大部分消息隊列原本就是排序的，而且能保證數據會按照特定的順序來處理。Kafka保證一個Partition內的消息的有序性。

緩衝
在任何重要的系統中，都會有須要不一樣的處理時間的元素。例如，加載一張圖片比應用過濾器花費更少的時間。消息隊列經過一個緩衝層來幫助任務最高效率的執行———寫入隊列的處理會盡量的快速。該緩衝有助於控制和優化數據流通過系統的速度。

異步通訊
不少時候，用戶不想也不須要當即處理消息。消息隊列提供了異步處理機制，容許用戶把一個消息放入隊列，但並不當即處理它。想向隊列中放入多少消息就放多少，而後在須要的時候再去處理它們。

四.消息隊列的分類

 消息隊列的分類：點對點，發佈/訂閱

 1.點對點
       消息生產者生產消息發送到queue中，而後消息消費者從queue中取出而且消費消息

  注意（缺點）：

           1.消息被消費之後，queue中再也不有存儲，因此消費者不可肯消費到已經被消費的消息。

           2.queue中支持存在多個消費者，可是對一個消息而言，只會有一個消費者能夠消費。
 
          （當一個系統消費了該個消息後，其餘的系統不能再消費了）

 2.發佈/訂閱（最經常使用的）
         消息生產者（發佈）將消息發佈到topic中，同時有多個消息消費者（訂閱）消費該消息。和點對點方式不一樣，發佈到topic的消息會被全部訂閱的消費者消費。

五.常見的消息隊列對比    

   1.RabbitMQ：支持的協議多，很是重量級消息隊列，對路由(Routing)，負載均衡(Load balance)或者數據持久化都有很好的支持。

    2.ZeroMQ：號稱最快的消息隊列系統，尤爲針對大吞吐量的需求場景，擅長的高級/複雜的隊列，可是技術也複雜，而且只提供非持久性的隊列。

    3.ActiveMQ（JMS的實現）：Apache下的一個子項，相似ZeroMQ，可以以代理人和點對點的技術實現隊列 。

    4.Redis：是一個key-Value的NOSql數據庫，但也支持MQ功能，數據量較小，性能優於RabbitMQ，數據超過10K就慢的沒法忍受。

        
    注：消息隊列不多是單點的，也須要集羣。這樣就涉及到了，負載均衡和消息的持久化

 六.Kafka的測試效果

 

參考資料：

《百知教育》apache kafka