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

基本概念

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

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

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

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

關于順序和分區(qū)

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

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

分區(qū)是為了提升消息處理的吞吐率而產生的，將一個 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 的實現是，在穩(wěn)定的情況下，維持固定的連接，每個 Consumer 穩(wěn)定的消費其中某幾個分區(qū)的消息，以上圖舉例，Consumer Group A 中的 C1 穩(wěn)定消費 P0、P3，C2 穩(wěn)定消費 P1、P2。這樣的連接分配可能會導致消息消費的不均勻分布，但好處是比較容易保證順序性。

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

關于副本

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

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

關于丟消息和重復收到消息

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

在有副本的情況下，Kafka 是可以保證消息不丟的，其前提是設置了同步復制，這也是 Kafka 的默認設置，但是可能出現重復發(fā)送消息，這個交給上層應用解決；在生產者中使用異步提交，可以保證不重復發(fā)送消息，但是有丟消息的可能，如果應用可以容忍，也可以接受。如果需要實現讀且只讀一次，就比較麻煩，需要更底層的 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/?

標簽： 服務器 互聯網 數據庫

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