現(xiàn)代的互聯(lián)網(wǎng)分布式系統(tǒng)，只要稍微大一些，就一定逃不開(kāi)3類中間件：遠(yuǎn)程調(diào)用（RPC）框架、消息隊(duì)列、數(shù)據(jù)庫(kù)訪問(wèn)中間件。Kafka 是消息隊(duì)列中間件的代表產(chǎn)品，用 Scala 語(yǔ)言實(shí)現(xiàn)，本文采用的是 Kafka_2.11 0.10.0.0 版本進(jìn)行實(shí)驗(yàn)。

基本概念

首先，Kafka 中有一些基本的概念需要熟悉?1?2。

• Topic，指消息的類別，每個(gè)消息都必須有；
• Producer，指消息的產(chǎn)生者，或者，消息的寫端；
• Consumer，指消息的消費(fèi)者，或者，消息的讀端；
• Producer Group，指產(chǎn)生者組，組內(nèi)的生產(chǎn)者產(chǎn)生同一類消息；
• Consumer Group，指消費(fèi)者組，組內(nèi)的消費(fèi)者消費(fèi)同一類消息；
• Broker，指消息服務(wù)器，Producer 產(chǎn)生的消息都是寫到這里，Consumer 讀消息也是從這里讀；
• Zookeeper，是 Kafka 的注冊(cè)中心，Broker 和 Consumer 之間的協(xié)調(diào)器，包含狀態(tài)信息、配置信息和一些 Topic 的信息；
• Partition，指消息的水平分區(qū)，一個(gè) Topic 可以有多個(gè)分區(qū)；
• Replica，指消息的副本，為了提高可用性，將消息副本保存在其他 Broker 上。

特別說(shuō)明，Broker 是指單個(gè)消息服務(wù)進(jìn)程，一般情況下，Kafka 是集群運(yùn)行的，Broker 只是集群中的一個(gè)服務(wù)進(jìn)程，而非代指整個(gè) Kafka 服務(wù)，可以簡(jiǎn)單將 Broker 理解成服務(wù)器（Server）。Kafka 引入的術(shù)語(yǔ)都比較常見(jiàn)，從字面上理解相對(duì)直觀。Kafka 的大致結(jié)構(gòu)圖是這樣：

Kafka 是 Pull 模式的消息隊(duì)列，即 Consumer 連到消息隊(duì)列服務(wù)上，主動(dòng)請(qǐng)求新消息，如果要做到實(shí)時(shí)性，需要采用長(zhǎng)輪詢，Kafka 在0.8的時(shí)候已經(jīng)支持長(zhǎng)輪詢模式。上圖中 Consumer 的連接箭頭方向可能會(huì)讓讀者誤以為是 Push 模式，特此注明。更多關(guān)于 Kafka 設(shè)計(jì)的文章可以參考官方文檔，或者一些比較好的博客文章?3。

關(guān)于順序和分區(qū)

Kafka 是一個(gè)力求保持消息順序性的消息隊(duì)列，但不是完全保證，其保證的是 Partition 級(jí)別的順序性，如下圖：

此圖是 Topic 的分區(qū) log 的示意圖，可見(jiàn)，每個(gè)分區(qū)上的 log 都是一個(gè)有序的隊(duì)列，所以，Kafka 是分區(qū)級(jí)別有序的。如果，某個(gè) Topic 只有一個(gè)分區(qū)，那么這個(gè) Topic 下的消息就都是有序的。

分區(qū)是為了提升消息處理的吞吐率而產(chǎn)生的，將一個(gè) Topic 中的消息分成幾份，分別給不同的 Broker 處理。如下圖：

此圖中有2個(gè) Broker，Server 1 和 Server 2，每個(gè) Broker 上有2個(gè)分區(qū)，總共4個(gè)分區(qū)，P0 ~ P3；有2個(gè) Consumer Group，Consumer Group A 有2個(gè) Consumer，Consumer Group B 有4個(gè) Consumer。Kafka 的實(shí)現(xiàn)是，在穩(wěn)定的情況下，維持固定的連接，每個(gè) Consumer 穩(wěn)定的消費(fèi)其中某幾個(gè)分區(qū)的消息，以上圖舉例，Consumer Group A 中的 C1 穩(wěn)定消費(fèi) P0、P3，C2 穩(wěn)定消費(fèi) P1、P2。這樣的連接分配可能會(huì)導(dǎo)致消息消費(fèi)的不均勻分布，但好處是比較容易保證順序性。

維持完全的順序性在分布式系統(tǒng)看來(lái)幾乎是無(wú)意義的。因?yàn)�，如果需要維持順序性，那么就只能有一條線程阻塞的處理順序消息，即，Producer -> MQ -> Consumer 必須線程上一一對(duì)應(yīng)。這與分布式系統(tǒng)的初衷是相違背的。但是局部的有序性，是可以維持的。比如，有30000條消息，每3條之間有關(guān)聯(lián)，1->2->3，4->5->6，……，但是全局范圍來(lái)看，并不需要保證 1->4->7，可以 7->4->1 的順序來(lái)執(zhí)行，這樣可以達(dá)到最大并行度10000，而這通常是現(xiàn)實(shí)中我們面對(duì)的情況。通常應(yīng)用中，將有先后關(guān)系的消息發(fā)送到相同的分區(qū)上，即可解決大部分問(wèn)題。

關(guān)于副本

副本是高可用 Kafka 集群的實(shí)現(xiàn)方式。假設(shè)集群中有3個(gè) Broker，那么可以指定3個(gè)副本，這3個(gè)副本是對(duì)等的，對(duì)于某個(gè) Topic 的分區(qū)來(lái)說(shuō)，其中一個(gè)是 Leader，即主節(jié)點(diǎn)，另外2個(gè)副本是 Follower，即從節(jié)點(diǎn)，每個(gè)副本在一個(gè) Broker 上。當(dāng) Leader 收到消息的時(shí)候，會(huì)將消息寫一份到副本中，通常情況，只有 Leader 處于工作狀態(tài)。在 Leader 發(fā)生故障宕機(jī)的時(shí)候，F(xiàn)ollwer 會(huì)取代 Leader 繼續(xù)傳送消息，而不會(huì)發(fā)生消息丟失。Kafka 的副本是以分區(qū)為單位的，也就是說(shuō)，即使是同一個(gè) Topic，其不同分區(qū)的 Leader 節(jié)點(diǎn)也不同。甚至，Kafka 傾向于用不同的 Broker 來(lái)做分區(qū)的 Leader，因?yàn)檫@樣能做到更好的負(fù)載均衡。

在副本間的消息同步，實(shí)際上是復(fù)制消息的 log，復(fù)制可以是同步復(fù)制，也可以是異步復(fù)制。同步復(fù)制是說(shuō)，當(dāng) Leader 收到消息后，將消息寫入從副本，只有在收到從副本寫入成功的確認(rèn)后才返回成功給 Producer；異步復(fù)制是說(shuō)，Leader 將消息寫入從副本，但是不等待從副本的成功確認(rèn)，直接返回成功給 Producer。同步復(fù)制效率較低，但是消息不會(huì)丟；異步復(fù)制效率高，但是在 Broker 宕機(jī)的時(shí)候，可能會(huì)出現(xiàn)消息丟失。

關(guān)于丟消息和重復(fù)收到消息

任何一個(gè) MQ 都需要處理丟消息和重復(fù)收到消息的，正常情況下，Kafka 可以保證：1. 不丟消息；2. 不重復(fù)發(fā)消息；3. 消息讀且只讀一次。當(dāng)然這都是正常情況，極端情況，如 Broker 宕機(jī)，斷電，這類情況下，Kafka 只能保證 1 或者 2，無(wú)法保證 3。

在有副本的情況下，Kafka 是可以保證消息不丟的，其前提是設(shè)置了同步復(fù)制，這也是 Kafka 的默認(rèn)設(shè)置，但是可能出現(xiàn)重復(fù)發(fā)送消息，這個(gè)交給上層應(yīng)用解決；在生產(chǎn)者中使用異步提交，可以保證不重復(fù)發(fā)送消息，但是有丟消息的可能，如果應(yīng)用可以容忍，也可以接受。如果需要實(shí)現(xiàn)讀且只讀一次，就比較麻煩，需要更底層的 API?4。

參考文章

1. http://kafka.apache.org/documentation.html?
2. http://www.jianshu.com/p/453c6e7ff81c?
3. http://www.infoq.com/cn/author/%E9%83%AD%E4%BF%8A#文章?
4. http://developer.51cto.com/art/201501/464491.htm?
5. https://segmentfault.com/q/1010000004292925?
6. http://www.cnblogs.com/gnivor/p/5318319.html?
7. http://www.cnblogs.com/davidwang456/p/4313784.html?
8. http://www.jianshu.com/p/8689901720fd?
9. http://zqhxuyuan.github.io/2016/05/26/2016-05-13-Kafka-Book-Sample/?
10. http://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/?

標(biāo)簽： 服務(wù)器 互聯(lián)網(wǎng) 數(shù)據(jù)庫(kù)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。