如何基于Kafka 打造高可靠、高可用消息平臺

這期內容當中小編將會給大家帶來有關如何基于Kafka 打造高可靠、高可用消息平臺，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Kafka 是當前非常流行的一個消息系統，最初用作 LinkedIn 的活動流式數據和運營數據處理管道的基礎。活動流式數據主要包括頁面訪問量PV、訪問內容以及檢索內容等。運營數據指的是服務器的性能數據（CPU、IO 使用率、請求時間、服務日志等等數據）。這些數據通常的處理方式是先把各種活動以日志的形式寫入某種文件，然后周期性地對這些文件進行統計分析。

近年來，隨著互聯網的快速發展，活動和運營數據處理已經成為網站軟件產品特性中一個至關重要的組成部分，需要一套龐大的基礎設施對其提供支持。

Kafka 是一個分布式、支持分區的、多副本的，基于 Zookeeper 協調的分布式消息系統，現已捐獻給 Apache 基金會。它最大的特性就是可以實時處理大量數據并且支持動態水平擴展，這樣的特性可以滿足各種需求場景：比如基于 Hadoop 的批處理系統、低延遲的實時系統、Storm/Spark 流式處理引擎，日志處理系統，消息服務等等。

Kafka 架構如上圖所示，本質就是生產-存儲-消費，主要包含以下四個部分：

• Producer Cluster：生產者集群，負責發布消息到 Kafka broker，一般由多個應用組成。

• Kafka Cluster：Kafka 服務器集群。這里就是 Kafka 最重要的一部分，這里負責接收生產者寫入的數據，并將其持久化到文件存儲里，最終將消息提供給 Consumer Cluster。

• Zookeeper Cluster：Zookeeper 集群。Zookeeper 負責維護整個 Kafka 集群的 Topic 信息、Kafka Controller 等信息。

• Consumer Cluster：消費者集群，負責從 Kafka broker 讀取消息，一般也由多個應用組成，獲取自己想要的信息。

Kafka 相關概念解釋

• Broker Kafka 集群包含一個或多個服務器，這種服務器被稱為 broker；

• Topic 每條發布到 Kafka 集群的消息都有一個類別，這個類別被稱為 Topic。（物理上不同 Topic 的消息分開存儲，邏輯上一個 Topic 的消息雖然保存于一個或多個 broker 上但用戶只需指定消息的 Topic 即可生產或消費數據而不必關心數據存于何處）；

• Partition 是物理上的概念，每個 Topic 包含一個或多個 Partition；

• Producer 負責發布消息到 Kafka broker；

• Consumer 消息消費者，向 Kafka broker 讀取消息的客戶端；

• Consumer Group 每個 Consumer 屬于一個特定的 Consumer Group（可為每個 Consumer 指定 group name，若不指定 group name 則屬于默認的 group）。

在 Kafka 架構設計里，無論是生產者、還是消費者、還是消息存儲，都可以動態水平擴展，從而提高整個集群的吞吐量、可擴展性、持久性和容錯性，Kafka生來就是一個分布式系統，這賦予了它以下特性：

• 高吞吐量、低延遲：Kafka可以以較低的資源消耗處理每秒上百MB的消息吞吐量，而它的延遲最低只有幾毫秒。

• 可擴展性：Kafka集群支持動態水平擴展。

• 持久性、可靠性：消息被持久化到本地磁盤，并且支持數據備份防止數據丟失。

• 容錯性：允許集群中節點失敗（若副本數量為n,則允許n-1個節點失敗）。

• 高并發：支持數千個客戶端同時讀寫。

目前越來越多的開源分布式處理系統如 Cloudera、Apache Storm、Spark、Flink 等都支持與 Kafka 集成，Kafka 可被廣泛應用于以下場景中：

消息系統 ：異步解耦生產者和消費者，削峰填谷波動的流量峰值。

日志聚合：可以用 Kafka 收集各種服務的操作日志，通過 Kafka 以統一接口服務的方式開放給各種消費者，可以使用 Hadoop 等其他系統化的存儲和分析系統對聚合的日志進行統計分析。

用戶活動跟蹤： Kafka 經常被用來記錄 web 用戶或者 app 用戶的各種活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個服務器發布到 Kafka 中，然后訂閱者通過訂閱這些 topic 來做實時的監控分析，做離線分析和挖掘。

運營指標：Kafka 也經常用來記錄運營監控數據。包括收集各種分布式應用的數據，生產各種操作的集中反饋，比如報警和監控。

流式處理：Kafka 可以很好地支持離線數據、流式數據的處理，并能夠方便地進行數據聚合、分析等操作。比如 Spark streaming 和 Storm。

京東智聯云消息隊列 Kafka 版不僅托管了開源的 Apache Kafka，做到了用戶原有業務代碼無需改造，即可無縫遷移上云，并且還增強了對于 Kafka 集群的創建、管理、運維和監控，用戶通過京東智聯云消息隊列 Kafka 版部署，可以獲得以下優勢：

多版本創建

支持Kafka V0.10、V1.0、V2.4多版本創建，并且支持預付費和后付費兩種模式。三個大版本的支持方便使用kafka的用戶無縫遷移上云，后付費的模式支持用戶進行測試試用，不必產生機器成本的費用，免去多次部署的麻煩。

彈性擴容

輕松擴展，方便快捷。用戶可根據資源使用情況按需擴容，不影響現有業務的同時以滿足業務增長需求。避免了用戶自行搭建Kafka進行擴容的復雜操作和業務風險。

管理組件

用戶創建的每個 Kafka 集群都配置了 Kafka Manager，方便用戶進行界面化、可視化的集群管理，免去了API調用或者命令行工具的復雜操作。

運維監控

集群級別免運維，配備健康檢查，不健康的狀態自動 failover，無需用戶運維，即可保證服務可用性。并且對集群狀態進行監控，支持多維度的監控預警。免去了服務不可用但是使用方無感知的擔憂。

下面我們看一下通過京東智聯云消息隊列 Kafka，是如何構建高可靠高吞吐 Kafak 服務的？

1

 提高京東智聯云 Kafka 的吞吐量 

Kafka 中主題 topic 作為主要接受消息的載體，一般會分成一個或多個分區 partition，每個 partiton 相當于是一個子 queue，多個 partition 就相當于多個子 queue 在同時工作進行寫盤和交互處理，因此增加 partition 可以增加單個主題 topic 的吞吐量。

在物理結構上，每個 partition 對應一個物理的文件，Kafka 中會把消息持久化到本地文件系統中，并且保持 o(1) 極高的效率。磁盤的 IO 讀寫是非常耗資源的性能，所以提高磁盤的 iops 和吞吐量，可以提高消息寫入磁盤的速度，相應的提高吞吐。

Kafka 中的主題都是由消費組 consumer group 來消費的。如果這個 consumer group 里面 consumer 的數量小于 topic 里面 partition 的數量，就會有 consumer thread 同時處理多個 partition。如果這個 consumer group 里面 consumer 的數量大于 topic 里面 partition 的數量，多出的 consumer thread 就會閑置，剩下的是一個 consumer thread 處理一個 partition，這就造成了資源的浪費，因為一個 partition 不可能被兩個 consumer thread 去處理。

建議：

1）增加分區數 partition 可以有效提高消息的吞吐量，并且分區數最好是集群處理節點 broker 的整數倍，這樣每個副本分配到的分區數比較均勻；

2）采用高 iops 和高吞吐的磁盤規格和 SSD 類型的磁盤；

3）增加生產者 producer 和消費者 consumer 的數量，并且消費者的數量最好可以和分區數相等。

2

 提高京東智聯云 Kafka 的可靠性

Kafka 主題 topic 的副本數即備份 replica 的個數。如果副本數為 1 , 即使 Kafka 節點機器有多個，當該副本所在的機器宕機后，對應的數據也會訪問失敗。但副本數不是越多越好，副本數不能多于 Kafka 中處理節點 broker 的數量，更多的副本數在進行數據同步的時候會影響服務的性能。

當主題有了多副本之后，發送消息時候副本數據同步策略也影響著數據的高可靠性，主要由 ack 這個參數來控制。

• 當 ack=1，表示 producer 寫 leader 成功后，broker 就返回成功，無論其他的 follower 是否寫成功；

• 當 ack=2，表示 producer 寫 leader 和其他一個 follower 成功的時候，broker 就返回成功，無論其他的 partition follower 是否寫成功；

• 當 ack=-1，表示只有 producer 全部寫成功的時候，才算成功，kafka broker才返回成功信息。

可見當 ack=-1 時候，數據的可靠性肯定是最好的，但是這會影響到服務的可用，因為必須所有的 follower 都寫入成功才算成功，一個 follow 出現問題就會導致服務不可用。

建議：

1）當創建 Kafka 主題時，如果對數據可靠性有要求建議設置主題 topic 的副本數不少于三副本；

2）設置發送消息 ack 參數的時候，建議設置半數以上的副本成功就算發送成功即可，這樣可以兼顧消息的可靠性也不會降低服務的可用性；

3）發送消息的時候選擇同步或者異步的方式，關心消息的發送結果并且對于發送失敗的消息進行處理。

上述就是小編為大家分享的如何基于Kafka 打造高可靠、高可用消息平臺了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。