Kafka是什麼?爲何要用？

Kafka是什麼?爲何要用？

Kafka 是什麼？

毫無疑問，你如今對 Apache Kafka 必定充滿了各類好奇，那麼今天就容許我先來嘗試回答下" Kafka 是什麼"這個問題。那麼，Kafka 是什麼呢？用一句話歸納一下：Apache Kafka 是一款開源的消息引擎系統。

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

而消息中間件的提法有過分誇張「中間件」之嫌，讓人搞不清楚這個中間件究竟是作什麼的。像 Kafka 這一類的系統國外有專屬的名字叫 Messaging System，國內不少文獻將其簡單翻譯成消息系統。我我的認爲並非很恰當，由於它片面強調了消息主體的做用，而忽視了這類系統引覺得豪的消息傳遞屬性，就像引擎同樣，具有某種能量轉換傳輸的能力，因此我以爲翻譯成消息引擎反倒更加貼切。

仍是拉回來繼續聊消息引擎系統，那這類系統是作什麼用的呢？我先來個官方嚴肅版本的答案。
根據維基百科的定義，消息引擎系統是一組規範。企業利用這組規範在不一樣系統之間傳遞語義準確的消息，實現鬆耦合的異步式數據傳遞。

果真是官方定義，有板有眼。
若是以爲難於理解，那麼能夠試試我下面這個民間版：
系統 A 發送消息給消息引擎系統，系統 B 從消息引擎系統中讀取 A 發送的消息。

最基礎的消息引擎就是作這點事的！不管是上面哪一個版本，它們都提到了兩個重要的事實：

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

既然消息引擎是用於在不一樣系統之間傳輸消息的，那麼如何設計待傳輸消息的格式歷來都是一等一的大事。試問一條消息如何作到信息表達業務語義而無歧義，同時它還要能最大限度地提供可重用性以及通用性？稍微停頓幾秒去思考一下，若是是你，你要如何設計你的消息編碼格式。

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

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

• 點對點模型：也叫消息隊列模型。若是拿上面那個「民間版」的定義來講，那麼系統 A發送的消息只能被系統 B 接收，其餘任何系統都不能讀取 A 發送的消息。平常生活的例子好比電話客服就屬於這種模型：同一個客戶呼入電話只能被一位客服人員處理，第二個客服人員不能爲該客戶服務。
• 發佈 / 訂閱模型：與上面不一樣的是，它有一個主題（Topic）的概念，你能夠理解成邏輯語義相近的消息容器。該模型也有發送方和接收方，只不過提法不一樣。發送方也稱爲發佈者（Publisher），接收方稱爲訂閱者（Subscriber）。和點對點模型不一樣的是，這個模型可能存在多個發佈者向相同的主題發送消息，而訂閱者也可能存在多個，它們都能接收到相同主題的消息。生活中的報紙訂閱就是一種典型的發佈 / 訂閱模型。

比較酷的是 Kafka 同時支持這兩種消息引擎模型，後面我會分享 Kafka 是如何作到這一點的。

提到消息引擎系統，你可能會問 JMS 和它是什麼關係。JMS 是 Java Message Service，它也是支持上面這兩種消息引擎模型的。嚴格來講它並不是傳輸協議而僅僅是一組 API 罷了。不過多是 JMS 太有名氣以致於不少主流消息引擎系統都支持 JMS 規範，好比ActiveMQ、RabbitMQ、IBM 的 WebSphere MQ 和 Apache Kafka。

固然 Kafka 並未徹底遵守 JMS 規範，相反，它另闢蹊徑，探索出了一條特有的道路。

好了，目前咱們僅僅是瞭解了消息引擎系統是作什麼的以及怎麼作的，但還有個重要的問題是爲何要使用它。

爲何要使用它

依舊拿上面「民間版」舉例，咱們不由要問，爲何系統 A 不能直接發送消息給系統 B，中間還要隔一個消息引擎呢？

答案就是「削峯填谷」。這四個字簡直比消息引擎自己還要有名氣。

我翻了不少文獻，最多見的就是這四個字。所謂的「削峯填谷」就是指緩衝上下游瞬時突發流量，使其更平滑。特別是對於那種發送能力很強的上游系統，若是沒有消息引擎的保護，「脆弱」的下游系統可能會直接被壓垮致使全鏈路服務「雪崩」。

可是，一旦有了消息引擎，它可以有效地對抗上游的流量衝擊，真正作到將上游的「峯」填滿到「谷」中，避免了流量的震盪。消息引擎系統的另外一大好處在於發送方和接收方的鬆耦合，這也在必定程度上簡化了應用的開發，減小了系統間沒必要要的交互。

說了這麼多，可能你對「削峯填谷」並無太多直觀的感覺。

解決此問題的一個常見作法是咱們對上游系統進行限速，但這種作法對上游系統而言顯然是不合理的，畢竟問題並不出如今它那裏。因此更常見的辦法是引入像 Kafka 這樣的消息引擎系統來對抗這種上下游系統 TPS 的錯配以及瞬時峯值流量。
仍是這個例子，當引入了 Kafka 以後。上游訂單服務再也不直接與下游子服務進行交互。相似地，下游的各個子服務訂閱 Kafka 中的對應主題，並實時從該主題的各自分區（Partition）中獲取到訂單消息進行處理，從而實現了上游訂單服務與下游訂單處理服務的解耦。Kafka 可以將瞬時增長的訂單流量所有以消息形式保存在對應的主題中，既不影響上游服務的 TPS，同時也給下游子服務留出了充足的時間去消費它們。這就是 Kafka 這類消息引擎系統的最大意義所在。

最後我想送給你一句話：聰明人也要下死功夫。當我感到浮躁的時候它能幫我靜下心來踏踏實實作事情。但願這句話對你也有所啓發。切記：聰明人要下死功夫！