Kafka如何進(jìn)行跨AZ部署最佳實(shí)踐

Kafka如何進(jìn)行跨AZ部署最佳實(shí)踐，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

跨AZ部署最佳實(shí)踐之Kafka

跨AZ部署是實(shí)現(xiàn)服務(wù)高可用較為有效的方法，同時(shí)也極具性價(jià)比。如果實(shí)現(xiàn)了跨AZ部署，不僅可以消除服務(wù)中的單點(diǎn)，同時(shí)還可以逐步建設(shè)如下能力：服務(wù)隔離，灰度發(fā)布，N+1冗余，可謂一舉多得。上一篇介紹了ES的跨AZ部署實(shí)踐，本文繼續(xù)介紹Kafka如何實(shí)現(xiàn)跨AZ部署。

實(shí)現(xiàn)方式

“broker.rack”是服務(wù)端Broker配置文件中的一個(gè)參數(shù)，類似于ES中的Rack或Zone，通過(guò)Tag的方式，將集群中的Broker進(jìn)行“分組”，在分配分區(qū)副本時(shí)實(shí)現(xiàn)跨Rack容錯(cuò)。此參數(shù)接受一個(gè)“string”類型的值，默認(rèn)為null；此外“broker.rack”不支持動(dòng)態(tài)更新，是只讀的，這意味著：

1. 更新Broker的broker.rack 需要重啟broker；

2. 跨AZ部署的集群，擴(kuò)縮容不需要對(duì)集群其他Broker進(jìn)行重啟

3. 生產(chǎn)環(huán)境的Kafka集群若要增加此配置實(shí)現(xiàn)跨AZ部署，需要對(duì)集群所有Broker進(jìn)行重啟。

具體配置示例如下：

broker.rack=my-rack-id

當(dāng)創(chuàng)建Topic時(shí)會(huì)受到broker.rack參數(shù)的約束，以確保分區(qū)副本能夠盡可能多的跨Rack，即n = min(#racks, replication-factor)，n指的是分區(qū)的副本將會(huì)分布在n個(gè)Rack。

那什么是盡可能呢？

這個(gè)是基于Kafka分區(qū)分配算法，具體實(shí)現(xiàn)可參考源碼中的函數(shù)(assignReplicasToBrokers)。

這里要說(shuō)的是，Kafka在為Topic分配分區(qū)時(shí)會(huì)根據(jù)如下幾個(gè)參數(shù)：replication-factor，partitions，兩個(gè)隨機(jī)參數(shù)(startIndex，fixedStartIndex)，各Broker上分區(qū)數(shù)量以及broker.rack將所有可用的Broker ID生成一個(gè)有序列表，列表會(huì)按照輪詢broker.rack的Broker產(chǎn)生的。假設(shè)：

rack1: 0 1
rack2: 2 3

則生成的列表會(huì)變成:[0, 2, 1, 3]。在分片分區(qū)時(shí)，當(dāng)Broker滿足如下兩個(gè)條件中的任意一個(gè)，副本將不會(huì)分配到該節(jié)點(diǎn)：

• 此Broker所在的broker.rack已經(jīng)存在該分區(qū)的副本，且存在broker.rack中沒(méi)有該分區(qū)副本。

• 此Broker中已經(jīng)存在該分區(qū)副本，并且還有其他Broker中沒(méi)有該分區(qū)的副本。

圖1 broker.rack參數(shù)分配機(jī)制部分源碼

通過(guò)上文的解釋，大家應(yīng)該對(duì)Kafka的副本分配機(jī)制有所了解，總的來(lái)說(shuō)：

1. 當(dāng)replication-factor<#broker.rack時(shí)，Topic的所有分區(qū)會(huì)優(yōu)先覆蓋到所有的broke.rack；

2. 當(dāng)replication-factor=#broker.rack時(shí)，每個(gè)broke.rack將存在一套完整的分區(qū)副本；

3. 當(dāng)replication-factor>#broker.rack時(shí)，至少一個(gè)broke.rack存在一套完整的分區(qū)副本；

4. 特別的，當(dāng)replication-factor=2#broker.rack時(shí)，Topic的分區(qū)會(huì)均勻分配在兩個(gè)AZ。

還有值得注意的是：

1. Kafka在進(jìn)行Leader選舉或Leader重平衡時(shí)，不關(guān)注broker.rack，即默認(rèn)情況下，Leader會(huì)分布在多個(gè)AZ。

2. Kafka不像ES，它不具備副本自動(dòng)轉(zhuǎn)移broker恢復(fù)的能力

那么，如何在一個(gè)AZ內(nèi)部，實(shí)現(xiàn)broker的高可用部署呢？本身維護(hù)真正意義上的機(jī)架分布難度很大，加上在虛擬化場(chǎng)景下，機(jī)架和虛擬機(jī)/docker中間還存在宿主機(jī)層，維護(hù)成本更高，所以建議使用云廠商提供的高可用組/置放群組來(lái)實(shí)現(xiàn)。

場(chǎng)景驗(yàn)證

梳理上文中提到影響影響分區(qū)分配的因素，排除兩個(gè)隨機(jī)參數(shù)(影響的僅僅是broker list的起始ID)和Broker上分區(qū)數(shù)量情況(這個(gè)參數(shù)影響的是AZ內(nèi)部的再平衡，本文的場(chǎng)景驗(yàn)證不關(guān)心AZ內(nèi)部的分區(qū)分配情況)。

每個(gè)AZ的broker數(shù)量是否一致，也僅僅影響到的是AZ內(nèi)部的分區(qū)情況，為了簡(jiǎn)化驗(yàn)證場(chǎng)景，我們暫不考慮每個(gè)AZ broker不一致的情況，所有可用的Broker ID 這個(gè)參數(shù)可以簡(jiǎn)化為“單AZ broker數(shù)量”這個(gè)參數(shù)代替。

剩余幾個(gè)因素和需要驗(yàn)證的值如下表所示：

表1 參數(shù)列表

要窮盡上表中的各種組合，共需要驗(yàn)證3*3*3*3=81種場(chǎng)景，為了排除偶然因素的影響，每種場(chǎng)景還需要重復(fù)多次試驗(yàn)，這樣做會(huì)非常繁瑣、且效率不高。

我們可以將參數(shù)看作“因素”，驗(yàn)證值看“水平”，每個(gè)因素取什么值是與其他因素?zé)o關(guān)。這正可以采用“正交試驗(yàn)”的思路（根據(jù)正交性從全面試驗(yàn)中挑選出部分有代表性的點(diǎn)進(jìn)行試驗(yàn)，是一種高效率、快速、經(jīng)濟(jì)的實(shí)驗(yàn)設(shè)計(jì)方法）。驗(yàn)證上表中的場(chǎng)景剛好可以用最常用的L9(3^4)型正交表(3水平4因素一般都用此表)，共需要驗(yàn)證9種場(chǎng)景即可，每種場(chǎng)景進(jìn)行10次驗(yàn)證，以排查偶然因素。

實(shí)際上只需驗(yàn)證7種場(chǎng)景即可，因?yàn)槠渲袃煞N場(chǎng)景不符合Kafka創(chuàng)建Topic的要求。通過(guò)Kafka Manager的可視化界面清晰的看到分區(qū)副本的分布情況，類似這樣的：

圖2 三分區(qū)兩副本2AZ時(shí)的分布情況，其中 broker id為0,1,2一個(gè)AZ，3,4,5一個(gè)AZ

圖3 三分區(qū)三副本2AZ時(shí)的分布情況，其中 broker id為0,1,2一個(gè)AZ，3,4,5一個(gè)AZ

采用L9(34)型的正交表，場(chǎng)景以及結(jié)論如下：

表2 正交場(chǎng)景表

可見(jiàn)，跨AZ部署的集群，若采取4副本可以做到AZ內(nèi)部以及跨AZ數(shù)據(jù)備份的能力。若一個(gè)AZ主要是為了容災(zāi)的話，可以通過(guò)Kafka的API（kafka-reassign-partitions.sh）將所有的Leader集中在一個(gè)AZ，從而降低跨AZ寫數(shù)據(jù)的延遲。不過(guò)，一般的，AZ之間的延遲往往很低是可接受的。

成本與網(wǎng)絡(luò)延遲

多AZ的部署架構(gòu)，主要是硬件成本，而考慮成本，需要結(jié)合數(shù)據(jù)重要性。若數(shù)據(jù)重要性較高，四副本的Topic配置是需要的，并且Kafka作為消息隊(duì)列，Messages的存儲(chǔ)本身并不重要，所以成本的影響不大。

第二個(gè)問(wèn)題就是網(wǎng)路延遲，我們通過(guò)壓測(cè)來(lái)驗(yàn)證網(wǎng)絡(luò)延遲會(huì)對(duì)Kafka帶來(lái)什么。在可用區(qū)A和可用區(qū)B創(chuàng)建一套集群：

1. 基準(zhǔn)集群為:在華北可用區(qū)A部署的2臺(tái)機(jī)器組成的集群

2. 跨AZ集群為在華北可用區(qū)A和可用區(qū)B部署的2臺(tái)機(jī)器組成的集群

兩個(gè)AZ直接的ping延遲和AZ內(nèi)部的ping延遲均值分別為:0.070ms和1.171ms。從三個(gè)角度驗(yàn)證網(wǎng)絡(luò)延遲的影響。

對(duì)消息寫入的影響

生產(chǎn)者向Kafka集群發(fā)送消息，又可分為同步(acks=all)和異步(acks=1)兩種方式，我們采用kafka自帶的壓測(cè)工具(/kafka-producer-perf-test.sh)對(duì)兩個(gè)集群進(jìn)行壓測(cè)。

在上述兩個(gè)集群各創(chuàng)建一個(gè)topic(--replication-factor 2 --partitions 1，leader位于可用區(qū)A上)

壓測(cè)機(jī)位于華北可用區(qū)A，每條消息的大小為300字節(jié)（為了體現(xiàn)網(wǎng)絡(luò)的問(wèn)題，弱化自身處理每條消息的能力），每秒發(fā)送10000條數(shù)據(jù)。

當(dāng)消息生產(chǎn)者已異步方式寫入時(shí)，即acks=1時(shí)，兩個(gè)集群的平均延遲幾乎沒(méi)有差別，壓測(cè)結(jié)果兩者分別是0.42 ms avg latency和0.51 ms avg latency。

壓測(cè)參數(shù)：

./kafka-producer-perf-test.sh --topic pressure1 --num-records 500000 --record-size 300 \

--throughput 10000 --producer-props bootstrap.servers=10.160.109.68:9092

基準(zhǔn)集群壓測(cè)結(jié)果：

跨AZ集群壓測(cè)結(jié)果：

當(dāng)消息采用同步機(jī)制時(shí)，消息的寫入有影響。影響還是有些大的，基準(zhǔn)集群為1.09 ms avg latency,跨AZ集群為8.17 ms avg latency：

壓測(cè)參數(shù)：

./kafka-producer-perf-test.sh --topic pressure --num-records 500000 --record-size 300 \

--throughput 10000 --producer-props acks=all bootstrap.servers=10.160.109.68:9092

基準(zhǔn)集群壓測(cè)結(jié)果：

下表是對(duì)比了當(dāng)消息大小為10,50…300時(shí)，同步寫時(shí)的平均延遲，發(fā)現(xiàn)，跨AZ集群/基準(zhǔn)集群大概能保持7倍的延遲差。

表4 步寫入時(shí)的數(shù)據(jù)對(duì)比

對(duì)集群自身的影響

選擇消息體大小為1000字節(jié)充分驗(yàn)證跨AZ場(chǎng)景下，網(wǎng)絡(luò)傳輸對(duì)集群數(shù)據(jù)同步的影響。對(duì)于基準(zhǔn)集群，我們將一臺(tái)Broker停掉，使用壓測(cè)工具異步寫入5000000條數(shù)據(jù)，然后啟動(dòng)停掉的Broker，獲得副本分區(qū)與leader完成同步的時(shí)間；同樣的，對(duì)跨AZ集群，停掉可用區(qū)B 中的Broker，也向leader寫入同樣的數(shù)據(jù)，獲得副本分區(qū)與leader完成同步的時(shí)間，并對(duì)兩者進(jìn)行比較。

基準(zhǔn)集群在26s完成了副本同步：

跨AZ集群在142s完成了副本同步，而且在同步期間，出現(xiàn)了與ZK連接超時(shí)的WARN。

可見(jiàn)，跨AZ集群在ping延遲下，對(duì)于消息體較大時(shí)，會(huì)出現(xiàn)一些潛在的問(wèn)題。

對(duì)Topic消費(fèi)的影響

消費(fèi)的延遲也主要集中在跨AZ的距離上，不過(guò)是可解的，消費(fèi)者組支持如下參數(shù)：

client.rack    #此參數(shù)接受一個(gè)string類型的值， 并與broker.rack的值保持一致。

最佳實(shí)踐--生產(chǎn)環(huán)境升級(jí)為多AZ部署

當(dāng)你的集群已經(jīng)運(yùn)行在生產(chǎn)環(huán)境上了，現(xiàn)在需要升級(jí)為跨AZ部署，那么應(yīng)該如何對(duì)現(xiàn)有集群進(jìn)行配置升級(jí)呢？

當(dāng)集群中存在有brocker.rack參數(shù)為null的節(jié)點(diǎn)時(shí)，哪怕只有一臺(tái)機(jī)器，默認(rèn)參數(shù)下創(chuàng)建topic會(huì)失敗，會(huì)出現(xiàn)如下報(bào)錯(cuò)：

通過(guò)參數(shù)--disable-rack-aware 可以忽略broker.rack參數(shù)進(jìn)行分區(qū)分配。生產(chǎn)環(huán)境的升級(jí)需要修改創(chuàng)建topic的方式，升級(jí)過(guò)程中對(duì)數(shù)據(jù)寫入和消費(fèi)沒(méi)有影響（對(duì)已經(jīng)存在的topic，Kafka也不會(huì)自動(dòng)的將分區(qū)重平衡）。

生產(chǎn)環(huán)境跨AZ升級(jí)的一般步驟如下：

1. 跨AZ創(chuàng)建測(cè)試集群，充分驗(yàn)證跨AZ對(duì)集群的影響，需要關(guān)注寫入吞吐量的影響（Topic是否需要增加分區(qū)），集群自身數(shù)據(jù)同步的資源消耗和消費(fèi)的跨AZ延遲情況；

2. 制定充分的回滾預(yù)案，并進(jìn)行回滾演練；

3. 增加“broker.rack”參數(shù)，在新的可用區(qū)對(duì)集群進(jìn)行擴(kuò)容；

4. 對(duì)集群原有節(jié)點(diǎn)，增加“broker.rack”參數(shù)，并需要滾動(dòng)重所有節(jié)點(diǎn);

5. 在Topic級(jí)別，通過(guò)手動(dòng)指定副本分配，在合適的時(shí)間對(duì)Topic進(jìn)行分區(qū)分配;

6. 按照需求，啟動(dòng)Topic的Leader重分配。

注意事項(xiàng)

1. Kafka的跨AZ部署的前提是需要有跨AZ部署的Zookeeper，不然當(dāng)ZK集群所在的AZ故障，Kafka集群也將不可用；

2. 對(duì)正在使用的Kafka集群進(jìn)行跨AZ部署，當(dāng)集群規(guī)模較大時(shí)，滾動(dòng)重啟集群操作時(shí)間跨度會(huì)很長(zhǎng)，并且需要人工對(duì)所有的Topic進(jìn)行分區(qū)遷移，若集群中Topic很多，此操作的工作量會(huì)很大；

3. 生產(chǎn)環(huán)境的跨AZ升級(jí)需要充分的驗(yàn)證，對(duì)生產(chǎn)環(huán)境消息體的大小進(jìn)行統(tǒng)計(jì)，特別的需要關(guān)注消息體大小大于80分位數(shù)，90分位數(shù)和95分位數(shù)下的數(shù)據(jù)同步對(duì)集群造成的延遲影響，以免在高并發(fā)寫入時(shí)拖垮集群。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。