前言
寫這篇文章的起因是由於之前的一篇關於Kafka異常消費，當時為了解決問題不得不使用臨時的方案。
總結起來歸根結底還是對Kafka不熟悉導致的，加上平時工作的需要，之后就花些時間看了Kafka相關的資料。
何時使用MQ
談到Kafka就不得不提到MQ，是屬於消息隊列的一種。作為一種基礎中間件在互聯網項目中有着大量的使用。
一種技術的產生自然是為了解決某種需求，通常來說是以下場景：
需要跨進程通信：B系統需要A系統的輸出作為輸入參數。
當A系統的輸出能力遠遠大於B系統的處理能力。
針對於第一種情況有兩種方案:
使用RPC遠程調用,A直接調用B。
使用MQ,A發布消息到MQ,B訂閱該消息。
當我們的需求是:A調用B實時響應，並且實時關心響應結果則使用RPC，這種情況就得使用同步調用。
反之當我們並不關心調用之后的執行結果，並且有可能被調用方的執行非常耗時，這種情況就非常適合用MQ來達到異步調用目的。
比如常見的登錄場景就只能用同步調用的方式，因為這個過程需要實時的響應結果，總不能在用戶點了登錄之后排除網絡原因之外再額外的等幾秒吧。
但類似於用戶登錄需要獎勵積分的情況則使用MQ會更好，因為登錄並不關系積分的情況，只需要發個消息到MQ,處理積分的服務訂閱處理即可，這樣還可以解決積分系統故障帶來的雪崩效應。
MQ還有一個基礎功能則是限流削峰，這對於大流量的場景如果將請求直接調用到B系統則非常有可能使B系統出現不可用的情況。這種場景就非常適合將請求放入MQ，不但可以利用MQ削峰還盡可能的保證系統的高可用。
Kafka簡介
本次重點討論下Kafka。
簡單來說Kafka是一個支持水平擴展，高吞吐率的分布式消息系統。
Kafka的常用知識:
Topic:生產者和消費者的交互都是圍繞着一個Topic進行的，通常來說是由業務來進行區分，由生產消費者協商之后進行創建。
Partition(分區):是Topic下的組成，通常一個Topic下有一個或多個分區，消息生產之后會按照一定的算法負載到每個分區，所以分區也是Kafka性能的關鍵。當發現性能不高時便可考慮新增分區。
備注：
其實就是初始化出三個消費者實例，用於三個線程消費。其中加入了一些統計，最后也是消費120009條數據結果如下。
由於是並行運行，可見消費120009條數據可以提高2秒左右，當數據以更高的數量級提升后效果會更加明顯。
但這也有一些弊端:
靈活度不高，當分區數量變更之后不能自適應調整。
消費邏輯和處理邏輯在同一個線程，如果處理邏輯較為復雜會影響效率，耦合也較高。當然這個處理邏輯可以再通過一個內部隊列發出去由另外的程序來處理也是可以的。
總結
Kafka的知識點還是較多，Kafka的使用也遠不這些。之后會繼續分享一些關於Kafka監控等相關內容。
項目地址：https://github.com/crossoverJie/SSM.git
原文：https://blog.csdn.net/zty1317313805/article/details/80269609