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、計算會員積分
3、通知物流進行配送
}
注：
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