2019-04-09
本篇文章系本人就當前所掌握的知識關於 訊息佇列 與 kafka 知識點的一些簡要介紹，不保證文章所述內容的絕對、完全正確性。筆者這裡所提到的 訊息系統 可不是那些社交**上用於站內交流的訊息系統。
在網際網路中，但凡涉及到訊息傳遞的過程，都可以稱之為是乙個訊息系統，規模或大或小而已。舉個例子：12306 購票過程就包含了訊息系統，客戶的查詢、下單等請求都被封裝成訊息傳遞到伺服器上並被處理。還有**京東的購物流程，學校圖書館的借閱系統等等都涉及到訊息系統。訊息系統在網際網路中的應用是非常廣泛的。
在乙個訊息系統中，伺服器端即 訊息處理端 是至關重要的。且不管你配備什麼配置的硬體，它的處理能力始終是有上限的。如果單位時間內訊息產生的數量超過了伺服器所能處理的數量，那我們的系統就肯定要出問題了。當然我們可以通過多部署幾台伺服器以分布式的方式來分攤訊息壓力來解決，但成本是個大問題啊。訊息爆發的情況總是少數，你看**一年就搞一次購物節，12306 一年也就那麼幾次搶票高峰期。因此，為我們的訊息系統引入 訊息佇列 就是乙個最佳選擇了。
我們可以簡單地把它理解成是訊息系統中 介於 客戶端與服務端之間的乙個訊息中轉站。訊息佇列在訊息系統中主要有以下 3 個作用
1. 應用解耦
2. 流量削峰
3. 非同步訊息
應用解耦
相信你一定還記得軟體設計的原則就是：高內聚，低耦合。 在沒有引入訊息佇列模組時，應用模組之間通常都是直接進行訊息傳遞過程的。我們以 12306 購票過程為例，使用者購票下單的過程與車票庫存直接相關。當使用者下單購票時，會同時呼叫車票庫存模組，使車票餘量減少。這樣就使得下單模組與車票庫存模組存在強耦合關係。當車票庫存模組服務不穩定時，例如，剛好要下單時庫存模組就暫停服務了，這樣一來就可能直接引發下單失敗等一系列不良體驗。而若加入了訊息佇列，下單請求將會直接傳送到訊息佇列中暫存，待到車票庫存模組恢復工作後再主動去消費下單請求。
流量削峰
這個就是前面提到的 「訊息爆發」 的情況了，俗稱 「流量爆發」 。這種情況常見於電商**的秒殺活動裡。在引入了訊息佇列以後，所有來自客戶端的請求都被積壓在訊息佇列裡，任憑你產生了多大的瞬時流量，我伺服器就按照我所能處理的速率按順序來逐條消費這些請求。這樣就可以保證我們的伺服器在任何情況下都能正常服務，只是將這種流量爆增的代價轉架到客戶端頭上使他們多排排隊而已。
非同步訊息
這種情況主要是應用於請求需要等待反饋結果情況。當有一條請求被發起時，各響應模組對請求的處理也是需要時間的，若所依賴的模組再多一點，響應時延可能就會很長了。那我們知道：使用者都是急躁的！ 所以我們可以通過引入訊息佇列的方式來非同步處理請求訊息。一種常用的方式是，使用者通過網頁下達了一條指令，當後台接收到這條指令並將它壓到訊息佇列時就立即返回 「成功」 的提示，隨後再等待各模組去執行這一指令。這種方式可以大大提公升使用者體驗。
前面介紹了這麼多訊息佇列的好處，並且現在的互聯***佇列的使用也確實是非常廣泛。但訊息佇列也是有缺點的，它最大的乙個缺點就是會增加 「系統複雜度」 。對於乙個系統來講，模組越少越簡單，執行起來出現故障的機率就越小，換句話說就是越容易穩定。而我們引入訊息佇列這一行為，至少是給我們的系統增加了乙個模組，這必然會提公升系統複雜度。另乙個缺點是你不可避免要面對訊息佇列模組故障的問題。當訊息佇列模組故障了，你的整個訊息系統也就癱瘓了。不過總體而言，引入訊息佇列還是弊大於利的。
訊息佇列框架還是不少的，不同的訊息佇列框架有各自不同的適用場景。在大資料領域裡要數 kafka 比較熱門。
kafka 是由 linkedin 團隊開發的一款發布/訂閱模型的分布式流處理平台，主要用於對資料流的儲存與處理。於 2012 年成為 apache 頂級專案之一。kafka 既然被當作訊息佇列來使用，那麼它的核心功能自然就是 高效能的訊息傳送與消費 了。同時 kafka 還是乙個依賴於 zookeeper 的分布式訊息佇列。
發布/訂閱模型可以簡單理解為就是一種 「一對多」 的訊息推送系統。訊息的傳送者不會直接將訊息發給訊息接收者。而是訊息傳送者首先以某種方式將訊息分類，由訊息接收者主動訂閱某種分類下的訊息。當這一操作完成後，有新訊息到來時，訊息傳送者才會將新訊息推送給所有訂閱了該型別訊息的接收者。
從訊息流向角度來看，kafka 中共有 3 個角色
1. producer
2. topic
3. consumer
producer
即訊息的生產者。
topic
訊息的分類。在 kafka 中，不同型別的訊息以 topic 劃分。例如在某電商**中，下單訊息被劃為乙個 topic ，取消訂單被劃分為另乙個 topic 等等。在某種程度上也可以將 topic 理解為是乙個 佇列 。所有的訊息都是以先進先出的形式被儲存在乙個 topic 中的。
consumer
即訊息的消費者。
從訊息管理的角度來看，可以分為 3 個角色
1. topic
2. partition
3. replication
topic
上面已經有解釋。
partition
如果乙個 topic 規模過大，則可以將它拆分成多個 partition 以儲存在不同的節點上。可以理解為 topic 是由 1 ~ n 個 partition 組成的。
replication
replication 即是 partition 的副本。它是為了提高 topic 的可用性而設立的乙個角色。其意義與 hdfs 中的副本是一樣的。
值得一提的是，對於同乙個 topic 中的多個 partition 副本中，會有其中乙個 partition 副本是 leader 副本，其餘的是 follower 副本。消費者只與 leader 副本互動。
從集群的角度看，可以分成 2 種角色
1. broker
2. cluster
broker
通常一台 kafka 伺服器就是乙個 broker ，而乙個 broker 裡又可以包含多個 topic 。
cluster
多台 broker 構成乙個 kafka 集群。
從消費者的角度看，可以分為 2 類
1. consumer
2. consumer group
consumer
消費者。
consumer group
消費者組。多個消費者可以劃分到乙個消費者組裡。若某個消費者組訂閱了某個 topic ，則有新訊息到來時，只會傳送給這個消費者組中的乙個消費者而不是發給所有消費者。
綜上所述，可以作出如下圖所示的 kafka 架構圖
kafka 架構簡圖
2019-04-09
訊息佇列 訊息佇列 kafka
kafka是乙個分布式的基於發布 訂閱模式的訊息佇列，主要用於大資料實時處理領域。要理解kafka首先要有分布式的概念，要有訊息佇列的概念。分布式系統最大的優勢就是解耦和削峰，這種情況下，a系統生成了乙個訊息，b系統非同步獲取，那麼就需要乙個存放訊息的訊息佇列 mq 相比較傳統的訊息佇列，訊息被消費...
訊息佇列 Kafka學習
kafka是乙個分布式的訊息佇列，學習見apache kafka文件，中文翻譯見kafka分享，乙個簡單的入門例子見kafka 入門例項。本文只針對自己感興趣的點記錄下。producer consumer 訊息的生成者和使用者。broker kafka server充當broker角色，起到訊息佇列...
訊息佇列 Kafka學習
kafka是乙個分布式的訊息佇列，學習見apache kafka文件，中文翻譯見kafka分享，乙個簡單的入門例子見kafka 入門例項。本文只針對自己感興趣的點記錄下。producer consumer 訊息的生成者和使用者。broker kafka server充當broker角色，起到訊息佇列...