如何基于Kafka 打造高可靠、高可用消息平臺(tái)

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)如何基于Kafka 打造高可靠、高可用消息平臺(tái)，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Kafka 是當(dāng)前非常流行的一個(gè)消息系統(tǒng)，最初用作 LinkedIn 的活動(dòng)流式數(shù)據(jù)和運(yùn)營(yíng)數(shù)據(jù)處理管道的基礎(chǔ)?；顒?dòng)流式數(shù)據(jù)主要包括頁面訪問量PV、訪問內(nèi)容以及檢索內(nèi)容等。運(yùn)營(yíng)數(shù)據(jù)指的是服務(wù)器的性能數(shù)據(jù)（CPU、IO 使用率、請(qǐng)求時(shí)間、服務(wù)日志等等數(shù)據(jù)）。這些數(shù)據(jù)通常的處理方式是先把各種活動(dòng)以日志的形式寫入某種文件，然后周期性地對(duì)這些文件進(jìn)行統(tǒng)計(jì)分析。

近年來，隨著互聯(lián)網(wǎng)的快速發(fā)展，活動(dòng)和運(yùn)營(yíng)數(shù)據(jù)處理已經(jīng)成為網(wǎng)站軟件產(chǎn)品特性中一個(gè)至關(guān)重要的組成部分，需要一套龐大的基礎(chǔ)設(shè)施對(duì)其提供支持。

Kafka 是一個(gè)分布式、支持分區(qū)的、多副本的，基于 Zookeeper 協(xié)調(diào)的分布式消息系統(tǒng)，現(xiàn)已捐獻(xiàn)給 Apache 基金會(huì)。它最大的特性就是可以實(shí)時(shí)處理大量數(shù)據(jù)并且支持動(dòng)態(tài)水平擴(kuò)展，這樣的特性可以滿足各種需求場(chǎng)景：比如基于 Hadoop 的批處理系統(tǒng)、低延遲的實(shí)時(shí)系統(tǒng)、Storm/Spark 流式處理引擎，日志處理系統(tǒng)，消息服務(wù)等等。

Kafka 架構(gòu)如上圖所示，本質(zhì)就是生產(chǎn)-存儲(chǔ)-消費(fèi)，主要包含以下四個(gè)部分：

• Producer Cluster：生產(chǎn)者集群，負(fù)責(zé)發(fā)布消息到 Kafka broker，一般由多個(gè)應(yīng)用組成。

• Kafka Cluster：Kafka 服務(wù)器集群。這里就是 Kafka 最重要的一部分，這里負(fù)責(zé)接收生產(chǎn)者寫入的數(shù)據(jù)，并將其持久化到文件存儲(chǔ)里，最終將消息提供給 Consumer Cluster。

• Zookeeper Cluster：Zookeeper 集群。Zookeeper 負(fù)責(zé)維護(hù)整個(gè) Kafka 集群的 Topic 信息、Kafka Controller 等信息。

• Consumer Cluster：消費(fèi)者集群，負(fù)責(zé)從 Kafka broker 讀取消息，一般也由多個(gè)應(yīng)用組成，獲取自己想要的信息。

Kafka 相關(guān)概念解釋

• Broker Kafka 集群包含一個(gè)或多個(gè)服務(wù)器，這種服務(wù)器被稱為 broker；

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

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

• Producer 負(fù)責(zé)發(fā)布消息到 Kafka broker；

• Consumer 消息消費(fèi)者，向 Kafka broker 讀取消息的客戶端；

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

在 Kafka 架構(gòu)設(shè)計(jì)里，無論是生產(chǎn)者、還是消費(fèi)者、還是消息存儲(chǔ)，都可以動(dòng)態(tài)水平擴(kuò)展，從而提高整個(gè)集群的吞吐量、可擴(kuò)展性、持久性和容錯(cuò)性，Kafka生來就是一個(gè)分布式系統(tǒng)，這賦予了它以下特性：

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

• 可擴(kuò)展性：Kafka集群支持動(dòng)態(tài)水平擴(kuò)展。

• 持久性、可靠性：消息被持久化到本地磁盤，并且支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失。

• 容錯(cuò)性：允許集群中節(jié)點(diǎn)失敗（若副本數(shù)量為n,則允許n-1個(gè)節(jié)點(diǎn)失?。?/p>

• 高并發(fā)：支持?jǐn)?shù)千個(gè)客戶端同時(shí)讀寫。

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

消息系統(tǒng) ：異步解耦生產(chǎn)者和消費(fèi)者，削峰填谷波動(dòng)的流量峰值。

日志聚合：可以用 Kafka 收集各種服務(wù)的操作日志，通過 Kafka 以統(tǒng)一接口服務(wù)的方式開放給各種消費(fèi)者，可以使用 Hadoop 等其他系統(tǒng)化的存儲(chǔ)和分析系統(tǒng)對(duì)聚合的日志進(jìn)行統(tǒng)計(jì)分析。

用戶活動(dòng)跟蹤： Kafka 經(jīng)常被用來記錄 web 用戶或者 app 用戶的各種活動(dòng)，如瀏覽網(wǎng)頁、搜索、點(diǎn)擊等活動(dòng)，這些活動(dòng)信息被各個(gè)服務(wù)器發(fā)布到 Kafka 中，然后訂閱者通過訂閱這些 topic 來做實(shí)時(shí)的監(jiān)控分析，做離線分析和挖掘。

運(yùn)營(yíng)指標(biāo)：Kafka 也經(jīng)常用來記錄運(yùn)營(yíng)監(jiān)控?cái)?shù)據(jù)。包括收集各種分布式應(yīng)用的數(shù)據(jù)，生產(chǎn)各種操作的集中反饋，比如報(bào)警和監(jiān)控。

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

京東智聯(lián)云消息隊(duì)列 Kafka 版不僅托管了開源的 Apache Kafka，做到了用戶原有業(yè)務(wù)代碼無需改造，即可無縫遷移上云，并且還增強(qiáng)了對(duì)于 Kafka 集群的創(chuàng)建、管理、運(yùn)維和監(jiān)控，用戶通過京東智聯(lián)云消息隊(duì)列 Kafka 版部署，可以獲得以下優(yōu)勢(shì)：

多版本創(chuàng)建

支持Kafka V0.10、V1.0、V2.4多版本創(chuàng)建，并且支持預(yù)付費(fèi)和后付費(fèi)兩種模式。三個(gè)大版本的支持方便使用kafka的用戶無縫遷移上云，后付費(fèi)的模式支持用戶進(jìn)行測(cè)試試用，不必產(chǎn)生機(jī)器成本的費(fèi)用，免去多次部署的麻煩。

彈性擴(kuò)容

輕松擴(kuò)展，方便快捷。用戶可根據(jù)資源使用情況按需擴(kuò)容，不影響現(xiàn)有業(yè)務(wù)的同時(shí)以滿足業(yè)務(wù)增長(zhǎng)需求。避免了用戶自行搭建Kafka進(jìn)行擴(kuò)容的復(fù)雜操作和業(yè)務(wù)風(fēng)險(xiǎn)。

管理組件

用戶創(chuàng)建的每個(gè) Kafka 集群都配置了 Kafka Manager，方便用戶進(jìn)行界面化、可視化的集群管理，免去了API調(diào)用或者命令行工具的復(fù)雜操作。

運(yùn)維監(jiān)控

集群級(jí)別免運(yùn)維，配備健康檢查，不健康的狀態(tài)自動(dòng) failover，無需用戶運(yùn)維，即可保證服務(wù)可用性。并且對(duì)集群狀態(tài)進(jìn)行監(jiān)控，支持多維度的監(jiān)控預(yù)警。免去了服務(wù)不可用但是使用方無感知的擔(dān)憂。

下面我們看一下通過京東智聯(lián)云消息隊(duì)列 Kafka，是如何構(gòu)建高可靠高吞吐 Kafak 服務(wù)的？

1

 提高京東智聯(lián)云 Kafka 的吞吐量 

Kafka 中主題 topic 作為主要接受消息的載體，一般會(huì)分成一個(gè)或多個(gè)分區(qū) partition，每個(gè) partiton 相當(dāng)于是一個(gè)子 queue，多個(gè) partition 就相當(dāng)于多個(gè)子 queue 在同時(shí)工作進(jìn)行寫盤和交互處理，因此增加 partition 可以增加單個(gè)主題 topic 的吞吐量。

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

Kafka 中的主題都是由消費(fèi)組 consumer group 來消費(fèi)的。如果這個(gè) consumer group 里面 consumer 的數(shù)量小于 topic 里面 partition 的數(shù)量，就會(huì)有 consumer thread 同時(shí)處理多個(gè) partition。如果這個(gè) consumer group 里面 consumer 的數(shù)量大于 topic 里面 partition 的數(shù)量，多出的 consumer thread 就會(huì)閑置，剩下的是一個(gè) consumer thread 處理一個(gè) partition，這就造成了資源的浪費(fèi)，因?yàn)橐粋€(gè) partition 不可能被兩個(gè) consumer thread 去處理。

建議：

1）增加分區(qū)數(shù) partition 可以有效提高消息的吞吐量，并且分區(qū)數(shù)最好是集群處理節(jié)點(diǎn) broker 的整數(shù)倍，這樣每個(gè)副本分配到的分區(qū)數(shù)比較均勻；

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

3）增加生產(chǎn)者 producer 和消費(fèi)者 consumer 的數(shù)量，并且消費(fèi)者的數(shù)量最好可以和分區(qū)數(shù)相等。

2

 提高京東智聯(lián)云 Kafka 的可靠性

Kafka 主題 topic 的副本數(shù)即備份 replica 的個(gè)數(shù)。如果副本數(shù)為 1 , 即使 Kafka 節(jié)點(diǎn)機(jī)器有多個(gè)，當(dāng)該副本所在的機(jī)器宕機(jī)后，對(duì)應(yīng)的數(shù)據(jù)也會(huì)訪問失敗。但副本數(shù)不是越多越好，副本數(shù)不能多于 Kafka 中處理節(jié)點(diǎn) broker 的數(shù)量，更多的副本數(shù)在進(jìn)行數(shù)據(jù)同步的時(shí)候會(huì)影響服務(wù)的性能。

當(dāng)主題有了多副本之后，發(fā)送消息時(shí)候副本數(shù)據(jù)同步策略也影響著數(shù)據(jù)的高可靠性，主要由 ack 這個(gè)參數(shù)來控制。

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

• 當(dāng) ack=2，表示 producer 寫 leader 和其他一個(gè) follower 成功的時(shí)候，broker 就返回成功，無論其他的 partition follower 是否寫成功；

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

可見當(dāng) ack=-1 時(shí)候，數(shù)據(jù)的可靠性肯定是最好的，但是這會(huì)影響到服務(wù)的可用，因?yàn)楸仨毸械?follower 都寫入成功才算成功，一個(gè) follow 出現(xiàn)問題就會(huì)導(dǎo)致服務(wù)不可用。

建議：

1）當(dāng)創(chuàng)建 Kafka 主題時(shí)，如果對(duì)數(shù)據(jù)可靠性有要求建議設(shè)置主題 topic 的副本數(shù)不少于三副本；

2）設(shè)置發(fā)送消息 ack 參數(shù)的時(shí)候，建議設(shè)置半數(shù)以上的副本成功就算發(fā)送成功即可，這樣可以兼顧消息的可靠性也不會(huì)降低服務(wù)的可用性；

3）發(fā)送消息的時(shí)候選擇同步或者異步的方式，關(guān)心消息的發(fā)送結(jié)果并且對(duì)于發(fā)送失敗的消息進(jìn)行處理。

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