kafka(一)-為什麼選擇kafka
作為開發人員，我們在選擇一個框架或者工具時，我們都需要考慮些什麼，我們不是頭腦發熱，一拍腦袋就它了，我們首先要認清這個框架或工具的作用是什麼，能給我們帶來什麼樣的好處，同時也要考慮帶來什麼樣的負面結果，我們在使用時才能更好的揚其長避其短，kafka大家可能都不陌生，到底我們為什麼選擇kafka呢？
1.首先kafka是一個訊息佇列，作為訊息佇列一般會在很多場景中用到，如：
應用解耦
在系統互動時，有時我們很難一次性就設計出非常完善的介面，可能會隨著業務發展，這些互動介面也會不斷的變遷，如果我們的系統較多，系統間互動也較多，維護起來可能就是噩夢，這是可能就需要考慮引入一種基於資料的介面層(訊息佇列)，這樣各個系統可以獨立的擴充套件或修改自己的處理過程，只要保證他們準守實現設計的資料格式約束。解耦的同時也提高了系統的穩定性（某個元件失效不會影響其他部分正常執行）和擴充套件性（可以橫向擴充套件系統以增加處理訊息的能力）。
非同步處理
有時候我們的業務邏輯可能涉及到很多步驟，而且這些步驟可能上下關聯性不是很強，如果我們序列執行時，總耗時=每個步驟耗時之和，如果我們讓每個步驟並行處理，總耗時< 每個步驟耗時之和，在這裡我們就可以引入訊息佇列，將每個處理步驟傳送到訊息佇列，並且針對每個處理步驟都有對應的執行緒去監聽，這樣就能達到序列執行非同步化轉為並行執行，從而提高系統的的吞吐量。
流量削峰
在秒殺或搶購活動中，一般會因為流量暴增，應用因處理不過來而掛掉，此時一般會引入訊息佇列，這樣流量會先進入訊息佇列，我們的應用再根據自己的實際處理能力來消費這些訊息，從而達到緩解流量暴增對系統構成的壓力
日誌處理
有時我們需要採集日誌，系統執行中會產生大量的日誌，尤其是在流量高峰時，而這項日誌需要儲存在其他地方，一般進行其他的計算或處理，日誌在寫入磁碟此時，由於磁碟IO速度可能不是很快，會對系統造成壓力，這時我們就可以引入比較高效能的訊息佇列(kafka往往會被用到)，訊息佇列可以起到緩衝作用。
訊息通訊
訊息佇列一般都內建了高效的通訊機制，有點對點通訊，也有釋出訂閱式通訊，因此也可以用在純的訊息通訊。
冗餘儲存
訊息佇列一般會把訊息儲存起來，只有消費完成後，才把訊息刪除，這樣就防止了某些時候因為處理異常，而導致訊息丟失的問題
2.在眾多的訊息中介軟體中，為什麼選擇kafka
Kafka最早是由LinkedIn公司開發的，作為其自身業務訊息處理的基礎，後LinkedIn公司將Kafka捐贈給Apache，現在已經成為Apache的一個頂級專案了，Kafka作為一個高吞吐的分散式的訊息系統，是一個高效能跨語言分散式釋出/訂閱訊息佇列系統。主要特性
- 快速持久化：可以在O(1)的系統開銷下進行訊息持久化；
- 高吞吐：在一臺普通的伺服器上既可以達到10W/s的吞吐速率；
- 完全的分散式系統：Broker、Producer和Consumer都原生自動支援分散式，自動實現負載均衡；
- 支援同步和非同步複製兩種高可用機制；
- 支援資料批量傳送和拉取；
- 零拷貝技術(zero-copy)：減少IO操作步驟，提高系統吞吐量；
- 資料遷移、擴容對使用者透明；
- 無需停機即可擴充套件機器；
- 其他特性：豐富的訊息拉取模型、高效訂閱者水平擴充套件、實時的訊息訂閱、億級的訊息堆積能力、定期刪除機制；
優點
- 客戶端語言豐富：支援Java、.Net、PHP、Ruby、Python、Go等多種語言；
- 高效能：單機寫入TPS約在100萬條/秒，訊息大小10個位元組；
- 提供完全分散式架構，並有replica機制，擁有較高的可用性和可靠性，理論上支援訊息無限堆積；
- 支援批量操作；
- 消費者採用Pull方式獲取訊息。訊息有序，通過控制能夠保證所有訊息被消費且僅被消費一次；
- 有優秀的第三方KafkaWeb管理介面Kafka-Manager；
- 在日誌領域比較成熟，被多家公司和多個開源專案使用。
缺點
- Kafka單機超過64個佇列/分割槽時，Load時會發生明顯的飆高現象。佇列越多，負載越高，傳送訊息響應時間變長；
- 使用短輪詢方式，實時性取決於輪詢間隔時間；
- 消費失敗不支援重試；
- 支援訊息順序，但是一臺代理宕機後，就會產生訊息亂序；
- 社群更新較慢。
附和其他MQ速度對比：
