LinkedIn的工程師詳述了生産環境下Kafka的調試和最佳實踐

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

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

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

......由于日志壓縮程序已經停止一段時間了，有幾個較舊的偏移量仍然還在主題中。偏移緩存加載程序已經将它們加載到了緩存中。這本身是沒有問題的，因為日志中更多的最新偏移量最終會覆寫那些舊的條目。問題出在舊偏移量的清除程序是在偏移加載的過程中開始的，偏移加載的過程需要較長的時間。舊條目清除之後會在日志末尾追加标記。而與此同時，偏移量的加載過程仍在進行，并會加載最近的偏移量到緩存中，但它隻會在看到标記之後才會去除那些條目。這就解釋了為什麼偏移量實際上被丢失的原因。

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

koshy指出，

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

koshy還着重指出一些盡早發現偏移倒回的最佳實踐，包括：通過監控叢集中模糊不清的首席選舉率，基于消費者延遲的監控和告警進而避免誤報。監控日志壓縮的名額（特别是最大髒讀率傳感器的），以及偏移管理的名額（如偏移緩存大小、送出率、組數傳感器等）。偏移量自己被存在一個可複制、可分區、可壓縮的日志中，它們與内部的_consmer_offsets主題相關聯。koshy推薦在調試程序中盡早導出内部主題，進而避免日志壓縮删除那些潛在有用的資料。特定的主題由消息組成，任何的時間偏移送出請求都會被發送到偏移管理代理中。在這種情況下，消費者和代理的日志也是可能有用的。

本文轉自d1net（轉載）