Kafka 初識

1.Kafka 是什麼？

用一句話歸納一下：Apache Kafka 是一款開源的消息引擎系統。

 

假若「消息引擎系統「這個詞對你來講有點陌生的話，那麼「消息隊列「、「消息中間件」的提法想必你必定是有所耳聞的。不過說實話我更願意使用消息引擎系統這個稱謂，由於消息隊列給出了一個很不明確的暗示，彷彿 Kafka 是利用隊列的方式構建的；而消息中間件的提法有過分誇張「中間件」之嫌，讓人搞不清楚這個中間件究竟是作什麼的。

像 Kafka 這一類的系統國外有專屬的名字叫 Messaging System，國內不少文獻將其簡單翻譯成消息系統。我我的認爲並非很恰當，由於它片面強調了消息主體的做用，而忽視了這類系統引覺得豪的消息傳遞屬性，就像引擎同樣，具有某種能量轉換傳輸的能力，因此我以爲翻譯成消息引擎反倒更加貼切。

2.這類系統是作什麼用的？

　　先來個官方嚴肅版本的答案。

　　根據維基百科的定義：消息引擎系統是一組規範。企業利用這組規範在不一樣系統之間傳遞語義準確的消息，實現鬆耦合的異步式數據傳遞。
果真是官方定義，有板有眼。

　　若是以爲難於理解，那麼能夠試試我下面這個民間版：
       系統 A 發送消息給消息引擎系統，系統 B 從消息引擎系統中讀取 A 發送的消息。
　　最基礎的消息引擎就是作這點事的！

　　不管是上面哪一個版本，它們都提到了兩個重要的事實：

• 消息引擎傳輸的對象是消息；
• 如何傳輸消息屬於消息引擎設計機制的一部分。

 

3.它如何設計消息（消息的格式）？

　　既然消息引擎是用於在不一樣系統之間傳輸消息的，那麼如何設計待傳輸消息的格式歷來都是一等一的大事。

　　試問一條消息如何作到信息表達業務語義而無歧義，同時它還要能最大限度地提供可重用性以及通用性？

　　一個比較容易想到的是使用已有的一些成熟解決方案，好比使用 CSV、XML 亦或是 JSON；又或者你可能熟知國外大廠開源的一些序列化框架，好比 Google 的 Protocol Buffer 或 Facebook 的 Thrift。這些都是很酷的辦法。那麼如今我告訴你 Kafka 的選擇：它使用的是純二進制的字節序列。固然消息仍是結構化的，只是在使用以前都要將其轉換成二進制的字節序列。

 

4.傳輸消息的方式？
　　消息設計出來以後還不夠，消息引擎系統還要設定具體的傳輸協議，即我用什麼方法把消息傳輸出去。常見的有兩種方法：

• 點對點模型：也叫消息隊列模型。若是拿上面那個「民間版「的定義來講，那麼系統 A 發送的消息只能被系統 B 接收，其餘任何系統都不能讀取 A 發送的消息。平常生活的例子好比電話客服就屬於這種模型：同一個客戶呼入電話只能被一位客服人員處理，第二個客服人員不能爲該客戶服務。

 

• 發佈 / 訂閱模型：與上面不一樣的是，它有一個主題（Topic）的概念，你能夠理解成邏輯語義相近的消息容器。該模型也有發送方和接收方，只不過提法不一樣。發送方也稱爲發佈者（Publisher），接收方稱爲訂閱者（Subscriber）。和點對點模型不一樣的是，這個模型可能存在多個發佈者向相同的主題發送消息，而訂閱者也可能存在多個，它們都能接收到相同主題的消息。生活中的報紙訂閱就是一種典型的發佈 / 訂閱模型。比較酷的是 Kafka 同時支持這兩種消息引擎模型。

　　提到消息引擎系統，你可能會問 JMS 和它是什麼關係。JMS 是 Java Message Service，它也是支持上面這兩種消息引擎模型的。嚴格來講它並不是傳輸協議而僅僅是一組 API 罷了。不過多是 JMS 太有名氣以致於不少主流消息引擎系統都支持 JMS 規範，好比 ActiveMQ、RabbitMQ、IBM 的 WebSphere MQ 和 Apache Kafka。固然 Kafka 並未徹底遵守 JMS 規範，相反，它另闢蹊徑，探索出了一條特有的道路。

 

5.爲何要用用它？
　　好了，目前咱們僅僅是瞭解了消息引擎系統是作什麼的以及怎麼作的，但還有個重要的問題是爲何要使用它。
依舊拿上面「民間版「舉例，咱們不由要問，爲何系統 A 不能直接發送消息給系統 B，中間還要隔一個消息引擎呢？
答案就是「削峯填谷」。這四個字簡直比消息引擎自己還要有名氣。

　　所謂的「削峯填谷」就是指緩衝上下游瞬時突發流量，使其更平滑。特別是對於那種發送能力很強的上游系統，若是沒有消息引擎的保護，「脆弱」的下游系統可能會直接被壓垮致使全鏈路服務「雪崩」。可是，一旦有了消息引擎，它可以有效地對抗上游的流量衝擊，真正作到將上游的「峯」填滿到「谷」中，避免了流量的震盪。消息引擎系統的另外一大好處在於發送方和接收方的鬆耦合，這也在必定程度上簡化了應用的開發，減小了系統間沒必要要的交互。

　　說了這麼多，可能你對「削峯填谷」並無太多直觀的感覺。舉個例子來講明一下 Kafka 在這中間是怎麼去」抗「峯值流量的吧。好比購買課程，每門課程都有一個專門的訂閱按鈕，點擊以後進入到付費頁面。這個簡單的流程中就可能包含多個子服務，好比點擊訂閱按鈕會調用訂單系統生成對應的訂單，而處理該訂單會依次調用下游的多個子系統服務 ，好比調用支付寶和微信支付的接口、查詢你的登陸信息、驗證課程信息等。顯然上游的訂單操做比較簡單，它的 TPS 要遠高於處理訂單的下游服務，所以若是上下游系統直接對接，勢必會出現下游服務沒法及時處理上游訂單從而形成訂單堆積的情形。特別是當出現相似於秒殺這樣的業務時，上游訂單流量會瞬時增長，可能出現的結果就是直接壓跨下游子系統服務。
解決此問題的一個常見作法是咱們對上游系統進行限速，但這種作法對上游系統而言顯然是不合理的，畢竟問題並不出如今它那裏。因此更常見的辦法是引入像 Kafka 這樣的消息引擎系統來對抗這種上下游系統 TPS 的錯配以及瞬時峯值流量。

　　仍是這個例子，當引入了 Kafka 以後。上游訂單服務再也不直接與下游子服務進行交互。當新訂單生成後它僅僅是向 Kafka Broker 發送一條訂單消息便可。相似地，下游的各個子服務訂閱 Kafka 中的對應主題，並實時從該主題的各自分區（Partition）中獲取到訂單消息進行處理，從而實現了上游訂單服務與下游訂單處理服務的解耦。這樣當出現秒殺業務時，Kafka 可以將瞬時增長的訂單流量所有以消息形式保存在對應的主題中，既不影響上游服務的 TPS，同時也給下游子服務留出了充足的時間去消費它們。這就是 Kafka 這類消息引擎系統的最大意義所在。

 

　　對Kafka的初識就到這裏。謝謝閱讀。