Kafka is a distributed,partitioned,replicated commit logservice。它提供了類似於JMS的特性，但是在設計實現上完全不同，此外它並不是JMS規範的實現。今天就讓我們一起來看看關於Kafka 的精華問答吧。
1
Q：什麼是Kafka？
A :Kafka是一種分佈式的，基於發佈/訂閱的消息系統。主要設計目標如下：
以時間複雜度為O(1)的方式提供消息持久化能力，並保證即使對TB級以上數據也能保證常數時間的訪問性能
高吞吐率。即使在非常廉價的商用機器上也能做到單機支持每秒100K條消息的傳輸
支持Kafka Server間的消息分區，及分佈式消息消費，同時保證每個partition內的消息順序傳輸
同時支持離線數據處理和實時數據處理
2
Q：Kafka有哪些特性？
A：- 高吞吐量、低延遲：kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒，每個topic可以分多個partition, consumer group 對partition進行consume操作。
- 可擴展性：kafka集群支持熱擴展
- 持久性、可靠性：消息被持久化到本地磁盤，並且支持數據備份防止數據丟失
- 容錯性：允許集群中節點失敗（若副本數量為n,則允許n-1個節點失敗）
- 高併發：支持數千個客戶端同時讀寫
3
Q：Kafka的使用場景有哪些？
A： 1、Messaging
對於一些常規的消息系統,kafka是個不錯的選擇;partitons/replication和容錯,可以使kafka具有良好的擴展性和性能優勢.不過到目前為止,我們應該很清楚認識到,kafka並沒有提供JMS中的"事務性""消息傳輸擔保(消息確認機制)""消息分組"等企業級特性;kafka只能使用作為"常規"的消息系統,在一定程度上,尚未確保消息的發送與接收絕對可靠(比如,消息重發,消息發送丟失等)
2、Websit activity tracking
kafka可以作為"網站活性跟蹤"的最佳工具;可以將網頁/用戶操作等信息發送到kafka中.並實時監控,或者離線統計分析等
3、Log Aggregation
kafka的特性決定它非常適合作為"日誌收集中心";application可以將操作日誌"批量""異步"的發送到kafka集群中,而不是保存在本地或者DB中;kafka可以批量提交消息/壓縮消息等,這對producer端而言,幾乎感覺不到性能的開支.此時consumer端可以使hadoop等其他系統化的存儲和分析系統.
4
Q：為什麼要用Message Queue
A：
解耦 在項目啟動之初來預測將來項目會碰到什麼需求，是極其困難的。消息隊列在處理過程中間插入了一個隱含的、基於數據的接口層，兩邊的處理過程都要實現這一接口。這允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束
冗餘 有時在處理數據的時候處理過程會失敗。除非數據被持久化，否則將永遠丟失。消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失 風險。在被許多消息隊列所採用的”插入-獲取-刪除”範式中，在把一個消息從隊列中刪除之前，需要你的處理過程明確的指出該消息已經被處理完畢，確保你的 數據被安全的保存直到你使用完畢。
擴展性 因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的；只要另外增加處理過程即可。不需要改變代碼、不需要調節參數。擴展就像調大電力按鈕一樣簡單。
靈活性 & 峰值處理能力 在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量並不常見；如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵組件頂住增長的訪問壓力，而不是因為超出負荷的請求而完全崩潰。
可恢復性 當體系的一部分組件失效，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復後被處理。而這種允許重試或者延後處理請求的能力通常是造就一個略感不便的用戶和一個沮喪透頂的用戶之間的區別。
送達保證 消息隊列提供的冗餘機制保證了消息能被實際的處理，只要一個進程讀取了該隊列即可。在此基礎上，IronMQ提供了一個”只送達一次”保證。無論有多少進 程在從隊列中領取數據，每一個消息只能被處理一次。這之所以成為可能，是因為獲取一個消息只是”預定”了這個消息，暫時把它移出了隊列。除非客戶端明確的 表示已經處理完了這個消息，否則這個消息會被放回隊列中去，在一段可配置的時間之後可再次被處理。
順序保證 在許多情況下，數據處理的順序都很重要。消息隊列本來就是排序的，並且能保證數據會按照特定的順序來處理。IronMO保證消息漿糊通過FIFO（先進先出）的順序來處理，因此消息在隊列中的位置就是從隊列中檢索他們的位置。
緩衝 在任何重要的系統中，都會有需要不同的處理時間的元素。例如,加載一張圖片比應用過濾器花費更少的時間。消息隊列通過一個緩衝層來幫助任務最高效率的執行—寫入隊列的處理會盡可能的快速，而不受從隊列讀的預備處理的約束。該緩衝有助於控制和優化數據流經過系統的速度。
理解數據流 在一個分佈式系統裡，要得到一個關於用戶操作會用多長時間及其原因的總體印象，是個巨大的挑戰。消息系列通過消息被處理的頻率，來方便的輔助確定那些表現不佳的處理過程或領域，這些地方的數據流都不夠優化。
異步通信 很多時候，你不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許你把一個消息放入隊列，但並不立即處理它。你想向隊列中放入多少消息就放多少，然後在你樂意的時候再去處理它們。
5
Q：Leader副本和Follower副本
A：由於KafKa副本的存在，就需要保證一個分區的多個副本之間數據的一致性，KafKa會選擇該分區的一個副本作為Leader副本，而該分區其他副本作為Follower副本，只有Leader副本才負責處理客戶端讀/寫請求，Follower副本從Leader副本同步數據。如果Leader副本失效，通過相應的選舉算法將從其他Follower副本中選出新的Leader副本。
小夥伴們衝鴨，後臺留言區等著你！
關於kafka，今天你學到了什麼？還有哪些不懂的？除此還對哪些話題感興趣？快來留言區打卡啦！留言方式：打開第XX天，答：……
同時歡迎大家蒐集更多問題，投稿給我們！風裡雨裡留言區裡等你~
福利
1、掃描添加小編微信，備註“姓名+公司職位”，加入【雲計算學習交流群】，和志同道合的朋友們共同打卡學習！
2、公眾號後臺回覆：白皮書，獲取IDC最新數據白皮書整理資料！
太形象了！什麼是邊緣計算？最有趣的解釋沒有之一！
互聯網出海十年
華為員工年薪 200 萬！真相讓人心酸！
天才程序員：25 歲進貝爾實驗室，32 歲創建信息論 琥珀 極客寶寶 5天前
安全顧問反水成黑客, 靠瞎猜盜得5000萬美元的以太幣, 一個區塊鏈大盜的另類傳奇
人造器官新突破！美國科學家3D打印出會“呼吸”的肺 | Science
真香，朕在看了！
閱讀更多 科技百分百 的文章
