協同消費庫（consumerlibrary) 是並行對 loghub 中日誌進行消費的高階模式，提供了消費組（consumergroup）概念對實時消費端進行抽象與管理。spark streaming、storm、即將推出的 flink sdk 都是基於這種模式的包裝。
通過 consumerlib 實現不丟、保序、去重
consumerlib 使用
檢視協同消費進度
consumergroup 是乙個消費者組，包含多個 consumer，每個 consumer 消費 logstore 中的一部分 shard。
shard 的資料模型可以簡單理解成乙個佇列，新寫入的資料被加到隊尾，佇列中的每條資料都會對應乙個資料寫入時間，下圖是 shard 的資料模型。
要理解報警首先要理解下面幾個概念：
消費過程：消費者從隊頭開始順序讀取資料的過程。
消費進度：消費者當前讀取的資料對應的寫入時間。
消費落後時長：當前消費進度和佇列中最新的資料寫入時間的差值，單位為秒。
consumergroup 的消費落後時長取其包含的所有 shard 的消費落後時長的最大值，當超過使用者預設閾值時，就認為消費落後太多，需要報警。
登入 日誌服務管理控制台，單擊需要監控的 logstore 的監控圖示。
找到消費落後時長圖表，單擊進入雲監控控制台。
該圖展示了 logstore 下所有 consumergroup 的消費落後時長，單位為秒。紅框中圖例便是所有的 consumergroup，單擊右上角 建立報警規則 進入規則建立頁面。
建立針對 consumergroup spamdetector-report-c 的報警規則，5min 內只要有一次大於等於 600 秒就報警。設定生效時間和報警通知聯絡人，儲存規則。
上面的操作完成後便成功建立了報警規則。有關報警規則配置的任何問題，可以直接提工單到雲監控。
kafka消費延遲或者重複消費原因
由於專案中需要使用kafka作為訊息佇列，並且專案是基於spring boot來進行構建的，所以專案採用了spring kafka作為原生kafka的乙個擴充套件庫進行使用。先說明一下版本 用過kafka的人都知道，對於使用kafka來說，producer的使用相對簡單一些，只需要把資料按照指定的格...
kafka消費延遲問題查詢
最近線上偶爾爆出kafka消費延遲，但是系統的資料量並不大，為什麼會延遲呢？具體分析如下。基本思路 1.檢視機器中資料積壓情況，是否是因為資料量過大導致的消費延遲。2.統計資料傳送kafka成功到資料消費出來 還未做業務處理 的耗時。3.統計資料消費出來並完成業務處理的耗時。可以看出該group中有...
RocketMQ 9 訊息堆積與消費延遲
訊息處理流程中，如果consumer的消費速度跟不上producer的傳送速度，mq中未處理的訊息會越來越多 進的多出的少 這部分訊息就被稱為堆積訊息。訊息出現堆積進而會造成訊息的消費延遲。以下場景需要重點關注訊息堆積和消費延遲問題 consumer使用長輪詢pull模式消費訊息時，分為以下兩個階段...