今天就跟大家聊聊有關(guān)如何驗證 Kafka 系統(tǒng)的可靠性,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結(jié)了以下內(nèi)容,希望大家根據(jù)這篇文章可以有所收獲。
成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比蒼南網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式蒼南網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們,業(yè)務(wù)覆蓋蒼南地區(qū)。費用合理售后完善,十余年實體公司更值得信賴。
當(dāng)通過 Kafka 構(gòu)建的系統(tǒng)需要提供特定的可靠性,我們對 Kafka 做了相應(yīng)配置,對生產(chǎn)者和消費者的應(yīng)用做了必要的處理之后,如何驗證整個系統(tǒng)確實實現(xiàn)了期望的可靠性呢?
1. 概述
仍然是那句話,可靠性不是一個可以輕易獲得的東西,驗證的方法也不簡單,分為三個階段:
在沒有生產(chǎn)者和消費者參與的情況下,對 Kafka 的配置進(jìn)行驗證,確認(rèn) Kafka 的表現(xiàn)與預(yù)期一致;
加入生產(chǎn)者和消費者的應(yīng)用,確認(rèn)生產(chǎn)者和消費者的表現(xiàn)和預(yù)期一致;
應(yīng)用上線后,對應(yīng)用和 Kafka 的指標(biāo)、日志等進(jìn)行監(jiān)控,發(fā)現(xiàn)與可靠性有關(guān)的問題,進(jìn)行修復(fù)。
2. 驗證配置
驗證:其實就是測試,實際效果和預(yù)期效果是否一致,因此在驗證前必須確認(rèn)期望看到的結(jié)果,如果這一步有誤差,驗證可能很難成功。
驗證配置不是指用肉眼去確認(rèn)配置文件是否正確,而是使用 Kafka 提供的工具,Kafka 在 org.apacha.kafka.tools 包下有兩個類:VerifiableProducer 和 VerifiableConsumer,這兩個類既可以通過命令行運行,也可以在各種測試框架中使用。
VerifiableProducer 可以按照我們指定的參數(shù)來發(fā)送一定數(shù)量的消息,消息內(nèi)容為從 1 開始遞增的數(shù)字,參數(shù)包括 acks,重試次數(shù)和發(fā)送速率等等,運行時會打印每條消息發(fā)送成功或失敗。VerifiableConsumer 消費 VerifiableProducer 生產(chǎn)的消息,按照消費順序打印消息內(nèi)容,并且打印提交 offset 和分區(qū)重分配的消息。
下面來實戰(zhàn)一下,先看下這兩個命令行工具都有哪些參數(shù):
因為我也是第一次使用,所以我就隨便選幾個參數(shù)設(shè)置一下:
使用 VerifiableProducer 發(fā)送數(shù)據(jù):
然后用 VerifiableConsumer 接收收據(jù):
因為將 max-messages 設(shè)置為 10,而 topic 中只有 5 條消息,所以沒有退出。
以上只是演示,因為 broker 只有一臺,而且非常穩(wěn)定,實際測試時需要構(gòu)建更復(fù)雜的場景:
leader 選舉,關(guān)掉 leader 所在的 broker,producer 和 consumer 需要多長時間恢復(fù)?
controller 選舉,重啟 controller,整個系統(tǒng)需要多長時間恢復(fù)?
滾動重啟,一臺一臺的重啟 broker,能否做到一條消息都不丟失?
臟 leader 選舉,當(dāng)發(fā)生了臟 leader 選舉時,producer 和 consumer 會發(fā)生什么,能否接受后果?
根據(jù)實際的需要去構(gòu)建測試場景,當(dāng)測試都通過之后可以進(jìn)入下一步。
3. 驗證應(yīng)用
其實這一步的驗證方法和上一步非常類似,唯一的區(qū)別是:生產(chǎn)者和消費者替換成了自己開發(fā)的應(yīng)用代碼,保持 Kafka 的配置不變,啟動應(yīng)用中的生產(chǎn)和消費者,在構(gòu)建的場景中測試,比如:
生產(chǎn)者和消費者與 Kafka 集群斷開網(wǎng)絡(luò)
發(fā)生了 leader 選舉
broker 進(jìn)行滾動重啟
消費者進(jìn)行滾動重啟
生產(chǎn)者進(jìn)行滾動重啟
如果測試結(jié)果不符合預(yù)期,找到原因,修復(fù)它,全部驗證通過后,進(jìn)入下一步。
4. 線上監(jiān)控
這一步非常重要,因為萬一前兩步有所疏漏,或者來不及做,監(jiān)控可以確保及時發(fā)現(xiàn)問題,避免損失。
監(jiān)控的內(nèi)容可以包括:JMX、日志以及其它更復(fù)雜的自定義的指標(biāo)。
JMX 監(jiān)控
Kafka 自帶了 JMX 監(jiān)控,對于broker,生產(chǎn)者和消費者,分別有不同的指標(biāo)可以關(guān)注。
對于 broker,值得監(jiān)控的指標(biāo)很多,比如達(dá)不到 ISR 最小副本數(shù)的分區(qū)個數(shù),正在同步的分區(qū)副本數(shù),下線分區(qū)數(shù),controller 數(shù)量,失敗的生產(chǎn)請求數(shù),leader 選舉次數(shù)和時間等等,都很重要。
對于生產(chǎn)者,兩個和可靠性相關(guān)的指標(biāo)是每條消息的平均錯誤率和平均重試率,這兩個指標(biāo)如果上升了,表明系統(tǒng)肯定是出了問題。
對于消費者,最重要的指標(biāo)是消費 lag,它表明了這個消費者當(dāng)前消費到的位置落后于這個 topic 的各個分區(qū)最新消息有多遠(yuǎn),理想情況是在 0 和一個很小的值之間波動,如果增大到一定的閾值,則需要進(jìn)行處理。
日志監(jiān)控
Kafka 的日志監(jiān)控和其它應(yīng)用的日志監(jiān)控區(qū)別不大,關(guān)注日志中出現(xiàn)的 WARN 和 ERROR,任何異常都有可能影響可靠性。
其它監(jiān)控
如果不滿足于 JMX 監(jiān)控和日志監(jiān)控,可以自己擴(kuò)展或增加其它的監(jiān)控,JMX 報告的指標(biāo)是可以擴(kuò)展的,日志的內(nèi)容也是可以增加的,但可能需要修改源碼。
監(jiān)控系統(tǒng)
一般來說,Kafka 的監(jiān)控任務(wù)應(yīng)當(dāng)由專門的監(jiān)控和運維故障管理系統(tǒng)來完成,我用過兩個系統(tǒng)來監(jiān)控 Kafka:小米的 Open-Falcon 和 InfluxData 的 Telegraf + InfluxDB + Grafana 套件。都還行,可以比較靈活的定制想要監(jiān)控的內(nèi)容,同時支持多種報警方式,比如 Open-Falcon 支持郵件和微信報警,而 Grafana 的頁面美觀性相當(dāng)不錯,其它應(yīng)當(dāng)還有不少,但是我沒有用過就不胡扯了。
看完上述內(nèi)容,你們對如何驗證 Kafka 系統(tǒng)的可靠性有進(jìn)一步的了解嗎?如果還想了解更多知識或者相關(guān)內(nèi)容,請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道,感謝大家的支持。
當(dāng)前名稱:如何驗證Kafka系統(tǒng)的可靠性
當(dāng)前鏈接:http://m.rwnh.cn/article48/pgsjhp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供搜索引擎優(yōu)化、企業(yè)網(wǎng)站制作、App設(shè)計、靜態(tài)網(wǎng)站、ChatGPT、網(wǎng)站設(shè)計
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)