你是一個(gè)程序員，假設(shè)你維護(hù)了兩個(gè)服務(wù) A 和 B。B 服務(wù)每秒只能處理 100 個(gè)消息，但 A 服務(wù)卻每秒發(fā)出 200 個(gè)消息，B 服務(wù)哪里頂?shù)米。址昼姳粔嚎濉Ｄ敲磫?wèn)題就來(lái)了，有沒(méi)有辦法讓 B 在不被壓垮的同時(shí)，還能處理掉 A 的消息？當(dāng)然有，沒(méi)有什么是加一層中間層不能解決的，如果有，那就再加一層。這次我們要加的中間層是消息隊(duì)列 Kafka。

Kafka

什么是消息隊(duì)列

為了保護(hù) B 服務(wù)，我們很容易想到可以在 B 服務(wù)的內(nèi)存中加入一個(gè)隊(duì)列。

消息隊(duì)列在B進(jìn)程里

說(shuō)白了，它其實(shí)是個(gè)鏈表，鏈表的每個(gè)節(jié)點(diǎn)就是一個(gè)消息。每個(gè)節(jié)點(diǎn)有一個(gè)序號(hào)，我們叫它 Offset，記錄消息的位置。B 服務(wù)依據(jù)自己的處理能力，消費(fèi)鏈表里的消息。能處理多少是多少，不斷更新已處理 Offset 的值。

Offset是什么

但這有個(gè)問(wèn)題，來(lái)不及處理的消息會(huì)堆積在內(nèi)存里，如果 B 服務(wù)更新重啟，這些消息就都丟了。這個(gè)好解決，將隊(duì)列挪出來(lái)，變成一個(gè)單獨(dú)的進(jìn)程。就算 B 服務(wù)重啟，也不會(huì)影響到了隊(duì)列里的消息。

消息隊(duì)列單獨(dú)一個(gè)進(jìn)程

這樣一個(gè)簡(jiǎn)陋的隊(duì)列進(jìn)程，其實(shí)就是所謂的消息隊(duì)列。而像 A 服務(wù)這樣負(fù)責(zé)發(fā)數(shù)據(jù)到消息隊(duì)列的角色，就是生產(chǎn)者，像 B 服務(wù)這樣處理消息的角色，就是消費(fèi)者。

生產(chǎn)者和消費(fèi)者

但這個(gè)消息隊(duì)列屬實(shí)過(guò)于簡(jiǎn)陋，像什么高性能，高擴(kuò)展性，高可用，它是一個(gè)都不沾。我們來(lái)看下怎么優(yōu)化它。

高性能

B 服務(wù)由于性能較差，消息隊(duì)列里會(huì)不斷堆積數(shù)據(jù)，為了提升性能，我們可以擴(kuò)展更多的消費(fèi)者, 這樣消費(fèi)速度就上去了，相對(duì)的我們就可以增加更多生產(chǎn)者，提升消息隊(duì)列的吞吐量。

增加生產(chǎn)者和消費(fèi)者

隨著生產(chǎn)者和消費(fèi)者都變多，我們會(huì)發(fā)現(xiàn)它們會(huì)同時(shí)爭(zhēng)搶同一個(gè)消息隊(duì)列，搶不到的一方就得等待，這不純純浪費(fèi)時(shí)間嗎！有解決方案嗎？有！首先是對(duì)消息進(jìn)行分類，每一類是一個(gè) topic，然后根據(jù) topic 新增隊(duì)列的數(shù)量，生產(chǎn)者將數(shù)據(jù)按 topic 投遞到不同的隊(duì)列中，消費(fèi)者則根據(jù)需要訂閱不同的 topic。這就大大降低了 topic 隊(duì)列的壓力。

多個(gè)topic

但單個(gè) topic 的消息還是可能過(guò)多，我們可以將單個(gè)隊(duì)列，拆成好幾段，每段就是一個(gè) partition分區(qū)，每個(gè)消費(fèi)者負(fù)責(zé)一個(gè) partition。這就大大降低了爭(zhēng)搶，提升了消息隊(duì)列的性能。

partition

高擴(kuò)展性

隨著 partition 變多，如果 partition 都在同一臺(tái)機(jī)器上的話，就會(huì)導(dǎo)致單機(jī) cpu 和內(nèi)存過(guò)高，影響整體系統(tǒng)性能。

于是我們可以申請(qǐng)更多的機(jī)器，將 partition 分散部署在多臺(tái)機(jī)器上，這每一臺(tái)機(jī)器，就代表一個(gè) broker。我們可以通過(guò)增加 broker 緩解機(jī)器 cpu 過(guò)高帶來(lái)的性能問(wèn)題。

broker

高可用

到這里，其實(shí)還有個(gè)問(wèn)題，如果其中一個(gè) partition 所在的 broker 掛了，那 broker 里所有 partition 的消息就都沒(méi)了。這高可用還從何談起？有解決方案嗎？有，連你喜歡的女生都知道手機(jī)里多聊幾個(gè)沸羊羊，你卻不知道要給 partition 加備胎嗎？我們可以給 partition 多加幾個(gè)副本，也就是 replicas，將它們分為 Leader 和 Follower。Leader 負(fù)責(zé)應(yīng)付生產(chǎn)者和消費(fèi)者的讀寫請(qǐng)求，而 Follower 只管同步 Leader 的消息。

replicas

將 Leader 和 Follower 分散到不同的 broker 上，這樣 Leader 所在的 broker 掛了，也不會(huì)影響到 Follower 所在的 broker, 并且還能從 Follower 中選舉出一個(gè)新的 Leader partition 頂上。這樣就保證了消息隊(duì)列的高可用。

高可用

持久化和過(guò)期策略

剛剛提到的是幾個(gè) broker 掛掉的情況，那搞大點(diǎn)，假設(shè)所有 broker 都掛了，那豈不是數(shù)據(jù)全丟了？為了解決這個(gè)問(wèn)題，我們不能光把數(shù)據(jù)放內(nèi)存里，還要持久化到磁盤中，這樣哪怕全部 broker 都掛了，數(shù)據(jù)也不會(huì)全丟，重啟服務(wù)后，也能從磁盤里讀出數(shù)據(jù)，繼續(xù)工作。

持久化

但問(wèn)題又來(lái)了，磁盤總是有限的，這一直往里寫數(shù)據(jù)遲早有一天得炸。所以我們還可以給數(shù)據(jù)加上保留策略，也就是所謂的 retention policy，比如磁盤數(shù)據(jù)超過(guò)一定大小或消息放置超過(guò)一定時(shí)間就會(huì)被清理掉。

consumer group

到這里，這個(gè)消息隊(duì)列好像就挺完美了。但其實(shí)還有個(gè)問(wèn)題，按現(xiàn)在的消費(fèi)方式，每次新增的消費(fèi)者只能跟著最新的消費(fèi) Offset 接著消費(fèi)。如果我想讓新增的消費(fèi)者從某個(gè) Offset 開始消費(fèi)呢？聽起來(lái)這個(gè)需求很刁鉆？我舉個(gè)例子你就明白了。

哪怕 B 服務(wù)有多個(gè)實(shí)例，但本質(zhì)上，它只有一個(gè)消費(fèi)業(yè)務(wù)方，新增實(shí)例一般也是接著之前的 offset 繼續(xù)消費(fèi)。假設(shè)現(xiàn)在來(lái)了個(gè)新的業(yè)務(wù)方，C 服務(wù)，它想從頭開始消費(fèi)消息隊(duì)列里的數(shù)據(jù)，這時(shí)候就不能跟在 B 服務(wù)的 offset 后邊繼續(xù)消費(fèi)了。

所以我們還可以給消息隊(duì)列加入消費(fèi)者組（consumer group）的概念，B 和 C 服務(wù)各自是一個(gè)獨(dú)立的消費(fèi)者組，不同消費(fèi)者組維護(hù)自己的消費(fèi)進(jìn)度，互不打攪。

消費(fèi)者組互相獨(dú)立

ZooKeeper

相信你也發(fā)現(xiàn)了，組件太多了，而且每個(gè)組件都有自己的數(shù)據(jù)和狀態(tài)，所以還需要有個(gè)組件去統(tǒng)一維護(hù)這些組件的狀態(tài)信息，于是我們引入 ZooKeeper 組件。它會(huì)定期和 broker 通信，獲取 整個(gè) kafka 集群的狀態(tài)，以此判斷 某些 broker 是不是跪了，某些消費(fèi)組消費(fèi)到哪了。

加入ZooKeeper

Kafka 是什么

好了，到這里，當(dāng)初那個(gè)簡(jiǎn)陋的消息隊(duì)列，就成了一個(gè)高性能，高擴(kuò)展性，高可用，支持持久化的超強(qiáng)消息隊(duì)列，沒(méi)錯(cuò)，它就是我們常說(shuō)的消息隊(duì)列 Kafka，上面涉及到各種概念，比如 partition 和 broker 什么的，都出自它。

Kafka是什么

kafka 的應(yīng)用場(chǎng)景

消息隊(duì)列是架構(gòu)中最常見的中間件之一，使用場(chǎng)景之多，堪稱萬(wàn)金油！比如上游流量忽高忽低，想要削峰填谷，提升 cpu/gpu 利用率，用它。又比如系統(tǒng)過(guò)大，消息流向盤根錯(cuò)節(jié)，想要拆解組件，降低系統(tǒng)耦合，還是用它。再比如秒殺活動(dòng)，請(qǐng)求激增，想要保護(hù)服務(wù)的同時(shí)又盡量不影響用戶，還得用它。當(dāng)然，凡事無(wú)絕對(duì)，方案還得根據(jù)實(shí)際情況來(lái)定，做架構(gòu)做到最后，都是在做折中。

Kafka的應(yīng)用場(chǎng)景

總結(jié)

• ? kafka 是消息隊(duì)列，像消息隊(duì)列投遞消息的是生產(chǎn)者，消費(fèi)消息的是消費(fèi)者。增加生產(chǎn)者和消費(fèi)者的實(shí)例個(gè)數(shù)可以提升系統(tǒng)吞吐。多個(gè)消費(fèi)者可以組成一個(gè)消費(fèi)者組，不同消費(fèi)者組維護(hù)自己的消費(fèi)進(jìn)度，互不打攪。
• ? kafka 將消息分為多個(gè) topic，每個(gè) topic 內(nèi)部拆分為多個(gè) partition，每個(gè) partition 又有自己的副本，不同的 partition 會(huì)分布在不同的 broker 上，提升性能的同時(shí)，還增加了系統(tǒng)可用性和可擴(kuò)展性。