溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關Kafka集群消息積壓問題及怎么樣處理，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
通常情況下，企業中會采取輪詢或者隨機的方式，通過Kafka的producer向Kafka集群生產數據，來盡可能保證Kafk分區之間的數據是均勻分布的。
在分區數據均勻分布的前提下，如果我們針對要處理的topic數據量等因素，設計出合理的Kafka分區數量。對于一些實時任務，比如Spark Streaming/Structured-Streaming、Flink和Kafka集成的應用，消費端不存在長時間"掛掉"的情況即數據一直在持續被消費，那么一般不會產生Kafka數據積壓的情況。
Kafka消息積壓的典型場景：
比如，我們寫的實時應用因為某種原因掛掉了，并且這個任務沒有被監控程序監控發現通知相關負責人，負責人又沒有寫自動拉起任務的腳本進行重啟。
Kafka單分區生產消息的速度qps通常很高，如果消費者因為某些原因（比如受業務邏輯復雜度影響，消費時間會有所不同），就會出現消費滯后的情況。
那么，針對上述的情況，有什么好的辦法處理數據積壓呢？
一般情況下，針對性的解決辦法有以下幾種：
a.任務重新啟動后直接消費最新的消息，對于"滯后"的歷史數據采用離線程序進行"補漏"。
此外，建議將任務納入監控體系，當任務出現問題時，及時通知相關負責人處理。當然任務重啟腳本也是要有的，還要求實時框架異常處理能力要強，避免數據不規范導致的不能重新拉起任務。
b.任務啟動從上次提交offset處開始消費處理
看完上述內容，你們對Kafka集群消息積壓問題及怎么樣處理有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
