755
kafka詳解四：Kafka的設計思想、理念
本節主要從整體角度介紹Kafka的設計思想，其中的每個理念都可以深入研究，以後我可能會發專題文章做深入介紹，在這裏隻做較概括的描述以便大家更好的理解Kafka的獨特之處。本節主要涉及到如下主要內容：
- Kafka設計基本思想
- Kafka中的數據壓縮
- Kafka消息轉運過程中的可靠性
- Kafka集群鏡像複製
- Kafka 備份機製
由於對JMS日常管理的過度開支和傳統JMS可擴展性方麵的局限，LinkedIn(https://yq.aliyun.com/articles/www.linkedin.com)開發了Kafka以滿足他們對實時數據流的監控以及對CPU、IO利用率等指標的高要求。在Linkedin開發Kafka之初，把關注重點集中在了這幾個方麵：
- 為生產者和消費者提供一個通用的API
- 消息的持久化
- 高吞吐量，可以滿足百萬級別消息處理
- 對分布式和高擴展性的支持
二、基本思想
一個最基本的架構是生產者發布一個消息到Kafka的一個主題（topic），這個主題即是由扮演KafkaServer角色的broker提供，消費者訂閱這個主題，然後從中獲取消息，下麵這個圖可以更直觀的描述這個場景：
上圖所示的架構分為三部分：Producers、Kafka broker、consumers，它們分別運行在不同的節點。
下麵概括介紹一下Kafka一些設計思想：
consumer group：各個consumer可以組成一個組，每個消息隻能被組中的一個consumer消費，如果一個消息可以被多個consumer消費的話，那麼這些consumer必須在不同的組。
消息狀態：在Kafka中，消息的狀態被保存在consumer中，broker不會關心哪個消息被消費了被誰消費了，隻記錄一個offset值（指向partition中下一個要被消費的消息位置），這就意味著如果consumer處理不好的話，broker上的一個消息可能會被消費多次。
消息持久化：Kafka中會把消息持久化到本地文件係統中，並且保持極高的效率。
消息有效期：Kafka會長久保留其中的消息，以便consumer可以多次消費，當然其中很多細節是可配置的。
批量發送：Kafka支持以消息集合為單位進行批量發送，以提高push效率。
push-and-pull:Kafka中的Producer和consumer采用的是push-and-pull模式，即Producer隻管向broker push消息，consumer隻管從broker pull消息，兩者對消息的生產和消費是異步的。
Kafka集群中broker之間的關係：不是主從關係，各個broker在集群中地位一樣，我們可以隨意的增加或刪除任何一個broker節點。
負載均衡方麵：Kafka提供了一個 metadata API來管理broker之間的負載（對Kafka0.8.x而言，對於0.7.x主要靠zookeeper來實現負載均衡）。
同步異步：Producer采用異步push方式，極大提高Kafka係統的吞吐率（可以通過參數控製是采用同步還是異步方式）。
分區機製partition：Kafka的broker端支持消息分區，Producer可以決定把消息發到哪個分區，在一個分區中消息的順序就是Producer發送消息的順序，一個主題中可以有多個分區，具體分區的數量是可配置的。分區的意義很重大，後麵的內容會逐漸體現。
離線數據裝載：Kafka由於對可拓展的數據持久化的支持，它也非常適合向Hadoop或者數據倉庫中進行數據裝載。
插件支持：現在不少活躍的社區已經開發出不少插件來拓展Kafka的功能，如用來配合Storm、Hadoop、flume相關的插件。
三、消息壓縮
我們上麵已經知道了Kafka支持以集合為單位發送消息，在此基礎上，Kafka還支持對消息集合進行壓縮，Producer端可以通過GZIP或Snappy格式對消息集合進行壓縮。Producer端進行壓縮之後，在Consumer端需進行解壓。壓縮的好處就是減少傳輸的數據量，減輕對網絡傳輸的壓力，在對大數據處理上，瓶頸往往體現在網絡上而不是CPU（壓縮和解壓會耗掉部分CPU資源）。
那麼如何區分消息是壓縮的還是未壓縮的呢，Kafka在消息頭部添加了一個描述壓縮屬性字節，這個字節的後兩位表示消息的壓縮采用的編碼，如果後兩位為0，則表示消息未被壓縮。
四、消息轉運過程中的可靠性
在消息係統中，保證消息在生產和消費過程中的可靠性是十分重要的，在實際消息傳遞過程中，可能會出現如下三中情況：
- 一個消息發送失敗
- 一個消息被發送多次
- 最理想的情況：exactly-once ,一個消息發送成功且僅發送了一次
有許多係統聲稱它們實現了exactly-once，但是它們其實忽略了生產者或消費者在生產和消費過程中有可能失敗的情況。比如雖然一個Producer成功發送一個消息，但是消息在發送途中丟失，或者成功發送到broker，也被consumer成功取走，但是這個consumer在處理取過來的消息時失敗了。
從Producer端看：Kafka是這麼處理的，當一個消息被發送後，Producer會等待broker成功接收到消息的反饋（可通過參數控製等待時間），如果消息在途中丟失或是其中一個broker掛掉，Producer會重新發送（我們知道Kafka有備份機製，可以通過參數控製是否等待所有備份節點都收到消息）。
從Consumer端看：前麵講到過partition，broker端記錄了partition中的一個offset值，這個值指向Consumer下一個即將消費message。當Consumer收到了消息，但卻在處理過程中掛掉，此時Consumer可以通過這個offset值重新找到上一個消息再進行處理。Consumer還有權限控製這個offset值，對持久化到broker端的消息做任意處理。
五、mirror一個Kafka集群
關於Kafka集群的mirror，參考下麵這幅圖：
六、備份機製
備份機製是Kafka0.8版本的新特性，備份機製的出現大大提高了Kafka集群的可靠性、穩定性。有了備份機製後，Kafka允許集群中的節點掛掉後而不影響整個集群工作。一個備份數量為n的集群允許n-1個節點失敗。在所有備份節點中，有一個節點作為lead節點，這個節點保存了其它備份節點列表，並維持各個備份間的狀體同步。下麵這幅圖解釋了Kafka的備份機製：
想更深入的了解Kafka請參閱我的另一篇文章：《Kafka設計與原理詳解》
轉發請說明出處，原文鏈接：https://blog.csdn.net/suifeng3051/article/details/37606001
最後更新：2017-04-03 05:39:04