鴻蒙OS 4.0公測機(jī)型公布：甚至連nova6都支持
華為全新的HarmonyOS 4.0操作系統(tǒng)將于今天下午正式登場，官方在發(fā)布會(huì)之前也已經(jīng)正式給出了可升級的機(jī)型產(chǎn)品，這意味著這些機(jī)型會(huì)率先支持升級享用。這次的HarmonyOS 4.0支持
作者 ｜ vivo 互聯(lián)網(wǎng)服務(wù)器團(tuán)隊(duì)-Luo Mingbo
一、Kafka 集群部署架構(gòu)
為了讓讀者能與小編在后續(xù)的問題分析中有更好的共鳴，小編先與各位讀者朋友對齊一下我們 Kafka 集群的部署架構(gòu)及服務(wù)接入 Kafka 集群的流程。
為了避免超大集群我們按照業(yè)務(wù)維度將整個(gè)每天負(fù)責(zé)十萬億級消息的 Kafka 集群拆分成了多個(gè) Kafka 集群。拆分粒度太粗會(huì)導(dǎo)致單一集群過大，容易由于流量突變、資源隔離、限速等原因?qū)е录悍€(wěn)定性和可用性受到影響，拆分粒度太細(xì)又會(huì)因?yàn)榧禾嗖灰拙S護(hù)，集群內(nèi)資源較少應(yīng)對突發(fā)情況的抗風(fēng)險(xiǎn)能力較弱。
由于 Kafka 數(shù)據(jù)存儲(chǔ)和服務(wù)在同一節(jié)點(diǎn)上導(dǎo)致集群擴(kuò)縮容周期較長，遇到突發(fā)流量時(shí)不能快速實(shí)現(xiàn)集群擴(kuò)容扛住業(yè)務(wù)壓力，因此我們按照業(yè)務(wù)維度和數(shù)據(jù)的重要程度及是否影響商業(yè)化等維度進(jìn)行 Kafka 集群的拆分，同時(shí)在 Kafka 集群內(nèi)添加一層邏輯概念“資源組”，資源組內(nèi)的 Node 節(jié)點(diǎn)共享，資源組與資源組之間的節(jié)點(diǎn)資源相互隔離，確保故障發(fā)生時(shí)不會(huì)帶來雪崩效應(yīng)。
二、業(yè)務(wù)接入 Kafka 集群流程.在 Kafka 平臺注冊業(yè)務(wù)項(xiàng)目。若項(xiàng)目的業(yè)務(wù)數(shù)據(jù)較為重要或直接影響商業(yè)化，用戶需申請創(chuàng)建項(xiàng)目獨(dú)立的資源組，若項(xiàng)目數(shù)據(jù)量較小且對數(shù)據(jù)的完整性要求不那么高可以直接使用集群提供的公共資源組無需申請資源組。項(xiàng)目與邏輯概念資源組綁定。創(chuàng)建 topic，創(chuàng)建 topic 時(shí)使用 Kafka 平臺提供的接口進(jìn)行創(chuàng)建，嚴(yán)格遵守 topic 的分區(qū)分布只能在項(xiàng)目綁定的資源組管理的 broker 節(jié)點(diǎn)上。授權(quán)對 topic 的讀寫操作。
通過上述的架構(gòu)部署介紹及接入流程接入介紹相信大家有很多相關(guān)知識點(diǎn)都與小編對齊了。
從部署架構(gòu)圖我們可以清晰的了解到我們這套集群部署在服務(wù)端最小的資源隔離單元為“資源組”即在同一個(gè)資源組下的多個(gè)broker節(jié)點(diǎn)之間會(huì)有影響，不同的資源組下的broker節(jié)點(diǎn)做了邏輯隔離。
上述的相關(guān)知識點(diǎn)對齊后我們將開啟我們的故障排查之旅。
三、故障情況介紹
故障發(fā)生時(shí)，故障節(jié)點(diǎn)所在資源組的多個(gè) topic 流量幾乎全部掉零，生產(chǎn)環(huán)境我們對 Kafka 集群的磁盤指標(biāo)READ、WRITE、IO.UTIL、AVG.WAIT、READ.REQ、WRITE.REQ做了告警監(jiān)控，由于故障發(fā)生在凌晨，整個(gè)故障的處理過程持續(xù)實(shí)踐較長，導(dǎo)致了業(yè)務(wù)方長時(shí)間的topic流量整體掉零對業(yè)務(wù)造成不小的影響。
四、監(jiān)控指標(biāo)介紹4.1 流量監(jiān)控情況
1、故障節(jié)點(diǎn)在故障發(fā)生時(shí)網(wǎng)絡(luò)空閑率出現(xiàn)短暫的掉零情況，且與生產(chǎn)流量監(jiān)控指標(biāo)一致。一旦生產(chǎn)流量上升故障節(jié)點(diǎn)的網(wǎng)絡(luò)空閑率就同步掉零。
2、Grafana 監(jiān)控指標(biāo)中topic生產(chǎn)流量幾乎全部掉零。
3、Kafka 平臺項(xiàng)目監(jiān)控中也體現(xiàn)了當(dāng)前項(xiàng)目的多個(gè)topic生產(chǎn)流量指標(biāo)掉零。
4.2 磁盤指標(biāo)監(jiān)控
SDF 盤的IO.UTIL指標(biāo)達(dá)到100%， 80%左右我們認(rèn)為是服務(wù)可穩(wěn)定運(yùn)行的指標(biāo)閾值。
SDF 盤的AVG.WAIT指標(biāo)達(dá)到分鐘級等待，一般400ms左右的延遲我們認(rèn)為是服務(wù)可穩(wěn)定運(yùn)行的閾值。
4.3 Kafka 服務(wù)端日志及系統(tǒng)日志情況
Kafka集群controller節(jié)點(diǎn)的日志中出現(xiàn)Input/Output error的錯(cuò)誤日志。
Linux 系統(tǒng)日志中出現(xiàn)Buffer I/O error 的錯(cuò)誤日志
五、故障猜想及分析
從上述的指標(biāo)監(jiān)控中很明顯的可以得出結(jié)論，故障原因是由于 Kafka broker節(jié)點(diǎn)的sdf盤磁盤故障導(dǎo)致的，只需在對應(yīng)的 Kafka broker 節(jié)點(diǎn)上將sdf盤踢掉重啟即可恢復(fù)。那這樣就結(jié)束了嗎 ?of course not。
對 Kafka 有一定認(rèn)識的小伙伴應(yīng)該都知道，創(chuàng)建topic時(shí)topic的分區(qū)是均勻分布到集群內(nèi)的不同broker節(jié)點(diǎn)上的，即使內(nèi)部某一臺broker節(jié)點(diǎn)故障，其他分區(qū)應(yīng)該能正常進(jìn)行生產(chǎn)消費(fèi)，如果其他分區(qū)能進(jìn)行正常的生產(chǎn)和消費(fèi)就不應(yīng)該出現(xiàn)整個(gè)topic的流量幾乎全掉零的情況。
如上圖所示，topicA 的三個(gè)分區(qū)分別分布在 brokerA、brokerB、brokerC三個(gè)物理主機(jī)節(jié)點(diǎn)上。
生產(chǎn)者producer向TopicA發(fā)送消息時(shí)會(huì)分別與brokerA、brokerB、brokerC三個(gè)物理主機(jī)節(jié)點(diǎn)建立長鏈接進(jìn)行消息的發(fā)送，此時(shí)若 brokerB 節(jié)點(diǎn)發(fā)生故障無法向外部提供服務(wù)時(shí)按照我們的猜想應(yīng)該不會(huì)影響到brokerA和brokerC兩個(gè)節(jié)點(diǎn)繼續(xù)向producer提供接收消息的服務(wù)。
但從監(jiān)控指標(biāo)的數(shù)據(jù)展示來分析當(dāng)brokerB節(jié)點(diǎn)出現(xiàn)故障后topic整體流量掉零與我們的猜想大相徑庭。
既然是出現(xiàn)類似了服務(wù)雪崩的效應(yīng)導(dǎo)致了部分topic的整體流量幾乎掉零那么我們在猜想問題發(fā)生的原因時(shí)就可以往資源隔離的方向去思考，看看在整個(gè)過程中還有哪些地方涉及到資源隔離的環(huán)節(jié)進(jìn)行猜想。
Kafka 服務(wù)端我們按照資源組的方式做了 Kafka broker的邏輯隔離且從Grafana監(jiān)控上可以看出有一些topic的流量并沒有嚴(yán)重掉零的情況，那么我們暫時(shí)將分析問題的目光轉(zhuǎn)移到 Kafka client端，去分析 Kafka producer的發(fā)送消息的過程是否存在有資源隔離地方?jīng)]有做隔離導(dǎo)致了整體的雪崩效應(yīng)。
六、Kafka 默認(rèn)分區(qū)器的分區(qū)規(guī)則
對 Kafka 生產(chǎn)流程流程有一定了解的同學(xué)肯定知道，Kafka 作為了大數(shù)據(jù)生態(tài)中海量數(shù)據(jù)的消息中間件，為了解決海量數(shù)據(jù)的并發(fā)問題 Kafka 在設(shè)計(jì)之初就采用了客戶端緩沖消息，當(dāng)消息達(dá)到一定批量時(shí)再進(jìn)行批量消息的發(fā)送。
通過一次網(wǎng)絡(luò)IO將批量的數(shù)據(jù)發(fā)送到 Kafka 服務(wù)端。關(guān)于Kafka producer客戶端緩沖區(qū)的設(shè)計(jì)小編后續(xù)會(huì)單獨(dú)一個(gè)篇幅進(jìn)行深入的探索，鑒于篇幅問題不再此處進(jìn)行詳細(xì)分析。
基于此處的分析我們對一批消息發(fā)送到一個(gè)故障節(jié)點(diǎn)時(shí)的容錯(cuò)方案可以有以下猜想：
快速失敗，記錄故障節(jié)點(diǎn)信息。下次進(jìn)行消息路由時(shí)只路由到健康的節(jié)點(diǎn)上。快速釋放消息緩沖內(nèi)存。快速失敗，記錄故障節(jié)點(diǎn)信息，下次進(jìn)行消息路由時(shí)當(dāng)消息路由到故障節(jié)點(diǎn)上時(shí)直接報(bào)錯(cuò)，快速釋放緩沖區(qū)內(nèi)存。等待超時(shí)，當(dāng)次消息等待超時(shí)后，下次進(jìn)行消息路由時(shí)依然會(huì)出現(xiàn)路由到故障節(jié)點(diǎn)上的情況，且每次等待超時(shí)時(shí)間后才釋放占用的資源。
上述猜想中，如果是第一種情況，那么每次消息路由只路由到健康的節(jié)點(diǎn)上不會(huì)出現(xiàn)雪崩效應(yīng)耗盡客戶端緩沖區(qū)資源的情況;
第二種情況，當(dāng)消息路由到故障節(jié)點(diǎn)上時(shí)，直接拒絕分配緩沖區(qū)資源也不會(huì)造成雪崩效應(yīng);
第三種情況，每次需要在一個(gè)或多個(gè)超時(shí)時(shí)間后才能將故障節(jié)點(diǎn)所占用的客戶端緩沖區(qū)資源釋放，在海量消息發(fā)送的場景下一個(gè)超時(shí)時(shí)間周期內(nèi)故障節(jié)點(diǎn)上的消息足以將客戶端緩沖區(qū)資源耗盡，導(dǎo)致其他可用分區(qū)無法分配客戶端緩沖區(qū)資源導(dǎo)致出現(xiàn)雪崩效應(yīng)。
帶著上述的猜想打開kafka client producer的源代碼分析下defaultPartitioner的分區(qū)規(guī)則得到如下的分配邏輯：
發(fā)送消息時(shí)是否指定了分區(qū)，若指定了分區(qū)那消息就直接發(fā)往該分區(qū)無需重新路由分區(qū)。
消息是否指定了key，若消息指定了key，使用key的hash值與topic的分區(qū)數(shù)進(jìn)行模運(yùn)算，得出消息路由的分區(qū)號(對應(yīng)第三種猜想)。
消息未指定分區(qū)也未指定key，使用自增變量與topic的可用分區(qū)進(jìn)行模運(yùn)算，得出消息路由的分區(qū)號(對應(yīng)第一種猜想)。
七、總結(jié)從源碼中分析出若發(fā)送消息的時(shí)候指定了key，并使用的是 Kafka producer默認(rèn)的分區(qū)分配器請款下會(huì)出現(xiàn) Kafka producer 客戶端緩沖區(qū)資源被耗盡而出現(xiàn)topic所有分區(qū)雪崩效應(yīng)。跟業(yè)務(wù)系統(tǒng)同學(xué)了解了他們的發(fā)送邏輯確實(shí)在消息發(fā)送指定了key并使用的是 Kafka producer的默認(rèn)分區(qū)分配器。問題得到論證。八、建議若非必要發(fā)送消息時(shí)不要指定key，否則可能會(huì)出現(xiàn)topic所有分區(qū)雪崩效應(yīng)。若確實(shí)需要發(fā)送消息指定key，建議不要使用Kafka producer默認(rèn)的分區(qū)分配器，因?yàn)橹付╧ey的情況下使用 Kafka producer的默認(rèn)分區(qū)分配器會(huì)出現(xiàn)雪崩效應(yīng)。
本文鏈接：http://www.yifxia.cn/showinfo-119-2332-0.htmlKafka 萬億級消息實(shí)踐之資源組流量掉零故障排查分析
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號