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

基本概念

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

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

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

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

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

Kafka 是一個力求保持消息順序性的消息隊列，但不是完全保證，其保證的是 Partition 級別的順序性，如下圖：

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

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

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

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

關(guān)于副本

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

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

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

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

在有副本的情況下，Kafka 是可以保證消息不丟的，其前提是設(shè)置了同步復(fù)制，這也是 Kafka 的默認設(shè)置，但是可能出現(xiàn)重復(fù)發(fā)送消息，這個交給上層應(yīng)用解決；在生產(chǎn)者中使用異步提交，可以保證不重復(fù)發(fā)送消息，但是有丟消息的可能，如果應(yīng)用可以容忍，也可以接受。如果需要實現(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/?

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

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