在本文中，LinkedIn的軟體工程師Joel Koshy詳細闡述了他和一個工程師團隊是如何解決生產環境下Kafka的兩次事故的。這兩次事故是由於多個產品缺陷、特殊的客戶行為以及監控缺失的交錯影響導致的。

第一個缺陷是在LinkedIn的變更請求跟蹤系統中觀察到的，部署平臺認為這是從服務發出的重複郵件。Koshy指出，其根本原因是由於訊息格式的改變，和隨後快取載入在偏移管理器的終止，而這個偏移管理器已經被設定了一箇舊的偏移量。由於這個主題分割槽上的低資料容量，日誌壓縮和清除觸發器在部署的主題上從來沒有被觸發過。這導致一箇舊的偏移量被當作消費者的起點，同時也使得以前已經消費過的訊息被重新讀取，並觸發了重複的電子郵件。

第二個缺陷是在一個數據部署管道中，它裡面的Hadoop推送作業器會發送資料到Kafka的非生產環境，然後通過Kafka叢集複製到生產叢集。在發現取回的偏移量沒有有效檢查點的時候，複製就被卡住了。它表明前一個檢查的偏移量被丟掉了。Koshy是這樣描述根本原因的：

……由於日誌壓縮排程已經停止一段時間了，有幾個較舊的偏移量仍然還在主題中。偏移快取載入程序已經將它們載入到了快取中。這本身是沒有問題的，因為日誌中更多的最新偏移量最終會覆蓋那些舊的條目。問題出在舊偏移量的清除程序是在偏移載入的過程中開始的，偏移載入的過程需要較長的時間。舊條目清除之後會在日誌末尾追加標記。而與此同時，偏移量的載入過程仍在進行，並會載入最近的偏移量到快取中，但它只會在看到標記之後才會去除那些條目。這就解釋了為什麼偏移量實際上被丟失的原因。

Kafka代理之間不清楚首席代理選舉的規則，這會導致處於分割槽的首席代理在完成複製延遲過程中的失敗會引起偏移量倒轉。Kafka訊息的消費者發出讀取指定偏移量的請求。消費者會對主題分割槽檢查它們的偏移量，因此它們可以從最後一次檢查點（消費者需要重啟的點）重新開始。檢查可以發生在很多時候，包括消費者失敗、重啟或者分割槽被加到主題裡以及在消費者例項之間的分割槽分發規則需要改變的時候。如果一個消費者獲取這個代理的主題日誌之外的偏移關鍵字，它會收到OffsetOutOfRange的錯誤。消費者需要根據它們auto.offset.reset配置，來重新設定它們的偏移為最新或最早的有效偏移。

Koshy指出，

重置為最早的偏移會引起重複消費，而重置為最新的偏移意味著可能會丟失在偏移復位和下一次讀取之間已經到達的訊息。

Koshy還著重指出一些儘早發現偏移倒回的最佳實踐，包括：通過監控叢集中模糊不清的首席選舉率，基於消費者延遲的監控和告警從而避免誤報。監控日誌壓縮的指標（特別是最大髒讀率感測器的），以及偏移管理的指標（如偏移快取大小、提交率、組數感測器等）。偏移量自己被存在一個可複製、可分割槽、可壓縮的日誌中，它們與內部的_consmer_offsets主題相關聯。Koshy推薦在除錯程序中儘早匯出內部主題，從而避免日誌壓縮刪除那些潛在有用的資料。特定的主題由訊息組成，任何的時間偏移提交請求都會被髮送到偏移管理代理中。在這種情況下，消費者和代理的日誌也是可能有用的。

文章出處：聊聊架構

文/Joel Koshy