在本文中，LinkedIn的軟件工程師Joel Koshy詳細闡述了他和一個工程師團隊是如何解決生產環境下Kafka的兩次事故的。這兩次事故是由于多個產品缺陷、特殊的客戶行為以及監控缺失的交錯影響導致的。
第一個缺陷是在LinkedIn的變更請求跟蹤系統中觀察到的，部署平臺認為這是從服務發出的重復郵件。Koshy指出，其根本原因是由于消息格式的改變，和隨后緩存加載在偏移管理器的終止，而這個偏移管理器已經被設置了一個舊的偏移量。由于這個主題分區上的低數據容量，日志壓縮和清除觸發器在部署的主題上從來沒有被觸發過。這導致一個舊的偏移量被當作消費者的起點，同時也使得以前已經消費過的消息被重新讀取，并觸發了重復的電子郵件。
第二個缺陷是在一個數據部署管道中，它里面的Hadoop推送作業器會發送數據到Kafka的非生產環境，然后通過Kafka集群復制到生產集群。在發現取回的偏移量沒有有效檢查點的時候，復制就被卡住了。它表明前一個檢查的偏移量被丟掉了。Koshy是這樣描述根本原因的：
……由于日志壓縮進程已經停止一段時間了，有幾個較舊的偏移量仍然還在主題中。偏移緩存加載進程已經將它們加載到了緩存中。這本身是沒有問題的，因為日志中更多的最新偏移量最終會覆蓋那些舊的條目。問題出在舊偏移量的清除進程是在偏移加載的過程中開始的，偏移加載的過程需要較長的時間。舊條目清除之后會在日志末尾追加標記。而與此同時，偏移量的加載過程仍在進行，并會加載最近的偏移量到緩存中，但它只會在看到標記之后才會去除那些條目。這就解釋了為什么偏移量實際上被丟失的原因。
Kafka代理之間不清楚首席代理選舉的規則，這會導致處于分區的首席代理在完成復制延遲過程中的失敗會引起偏移量倒轉。Kafka消息的消費者發出讀取指定偏移量的請求。消費者會對主題分區檢查它們的偏移量，因此它們可以從最后一次檢查點（消費者需要重啟的點）重新開始。檢查可以發生在很多時候，包括消費者失敗、重啟或者分區被加到主題里以及在消費者實例之間的分區分發規則需要改變的時候。如果一個消費者獲取這個代理的主題日志之外的偏移關鍵字，它會收到OffsetOutOfRange的錯誤。消費者需要根據它們auto.offset.reset配置，來重新設置它們的偏移為最新或最早的有效偏移。
Koshy指出，
重置為最早的偏移會引起重復消費，而重置為最新的偏移意味著可能會丟失在偏移復位和下一次讀取之間已經到達的消息。
Koshy還著重指出一些盡早發現偏移倒回的最佳實踐，包括：通過監控集群中模糊不清的首席選舉率，基于消費者延遲的監控和告警從而避免誤報。監控日志壓縮的指標（特別是最大臟讀率傳感器的），以及偏移管理的指標（如偏移緩存大小、提交率、組數傳感器等）。偏移量自己被存在一個可復制、可分區、可壓縮的日志中，它們與內部的_consmer_offsets主題相關聯。Koshy推薦在調試進程中盡早導出內部主題，從而避免日志壓縮刪除那些潛在有用的數據。特定的主題由消息組成，任何的時間偏移提交請求都會被發送到偏移管理代理中。在這種情況下，消費者和代理的日志也是可能有用的。
文章出處：聊聊架構
文/Joel?Koshy
本文鏈接：http://www.thecarconnectin.com/8266.html
網友評論comments