kafka(一)-為什么選擇kafka

作為開發人員，我們在選擇一個框架或者工具時，我們都需要考慮些什么，我們不是頭腦發熱，一拍腦袋就它了，我們首先要認清這個框架或工具的作用是什么，能給我們帶來什么樣的好處，同時也要考慮帶來什么樣的負面結果，我們在使用時才能更好的揚其長避其短，kafka大家可能都不陌生，到底我們為什么選擇kafka呢？

1.首先kafka是一個消息隊列，作為消息隊列一般會在很多場景中用到，如：

應用解耦

在系統交互時，有時我們很難一次性就設計出非常完善的接口，可能會隨着業務發展，這些交互接口也會不斷的變遷，如果我們的系統較多，系統間交互也較多，維護起來可能就是噩夢，這是可能就需要考慮引入一種基於數據的接口層(消息隊列)，這樣各個系統可以獨立的擴展或修改自己的處理過程，只要保證他們准守實現設計的數據格式約束。解耦的同時也提高了系統的穩定性（某個組件失效不會影響其他部分正常運行）和擴展性（可以橫向擴展系統以增加處理消息的能力）。

異步處理

有時候我們的業務邏輯可能涉及到很多步驟，而且這些步驟可能上下關聯性不是很強，如果我們串行執行時，總耗時=每個步驟耗時之和，如果我們讓每個步驟並行處理，總耗時< 每個步驟耗時之和，在這里我們就可以引入消息隊列，將每個處理步驟發送到消息隊列，並且針對每個處理步驟都有對應的線程去監聽，這樣就能達到串行執行異步化轉為並行執行，從而提高系統的的吞吐量。

流量削峰

在秒殺或搶購活動中，一般會因為流量暴增，應用因處理不過來而掛掉，此時一般會引入消息隊列，這樣流量會先進入消息隊列，我們的應用再根據自己的實際處理能力來消費這些消息，從而達到緩解流量暴增對系統構成的壓力

日志處理

有時我們需要采集日志，系統運行中會產生大量的日志，尤其是在流量高峰時，而這項日志需要存儲在其他地方，一般進行其他的計算或處理，日志在寫入磁盤此時，由於磁盤IO速度可能不是很快，會對系統造成壓力，這時我們就可以引入比較高性能的消息隊列(kafka往往會被用到)，消息隊列可以起到緩沖作用。

消息通信

消息隊列一般都內置了高效的通信機制，有點對點通信，也有發布訂閱式通信，因此也可以用在純的消息通訊。

冗余存儲

消息隊列一般會把消息存儲起來，只有消費完成后，才把消息刪除，這樣就防止了某些時候因為處理異常，而導致消息丟失的問題

2.在眾多的消息中間件中，為什么選擇kafka

Kafka最早是由LinkedIn公司開發的，作為其自身業務消息處理的基礎，后LinkedIn公司將Kafka捐贈給Apache，現在已經成為Apache的一個頂級項目了，Kafka作為一個高吞吐的分布式的消息系統，是一個高性能跨語言分布式發布/訂閱消息隊列系統。

主要特性

1. 快速持久化：可以在O(1)的系統開銷下進行消息持久化；
2. 高吞吐：在一台普通的服務器上既可以達到10W/s的吞吐速率；
3. 完全的分布式系統：Broker、Producer和Consumer都原生自動支持分布式，自動實現負載均衡；
4. 支持同步和異步復制兩種高可用機制；
5. 支持數據批量發送和拉取；
6. 零拷貝技術(zero-copy)：減少IO操作步驟，提高系統吞吐量；
7. 數據遷移、擴容對用戶透明；
8. 無需停機即可擴展機器；
9. 其他特性：豐富的消息拉取模型、高效訂閱者水平擴展、實時的消息訂閱、億級的消息堆積能力、定期刪除機制；

優點

1. 客戶端語言豐富：支持Java、.Net、PHP、Ruby、Python、Go等多種語言；
2. 高性能：單機寫入TPS約在100萬條/秒，消息大小10個字節；
3. 提供完全分布式架構，並有replica機制，擁有較高的可用性和可靠性，理論上支持消息無限堆積；
4. 支持批量操作；
5. 消費者采用Pull方式獲取消息。消息有序，通過控制能夠保證所有消息被消費且僅被消費一次；
6. 有優秀的第三方KafkaWeb管理界面Kafka-Manager；
7. 在日志領域比較成熟，被多家公司和多個開源項目使用。

缺點

1. Kafka單機超過64個隊列/分區時，Load時會發生明顯的飆高現象。隊列越多，負載越高，發送消息響應時間變長；
2. 使用短輪詢方式，實時性取決於輪詢間隔時間；
3. 消費失敗不支持重試；
4. 支持消息順序，但是一台代理宕機后，就會產生消息亂序；
5. 社區更新較慢。

附和其他MQ速度對比：