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

第一個缺陷是在LinkedIn的變更請求跟蹤系統(tǒng)中觀察到的，部署平臺認為這是從服務(wù)發(fā)出的重復(fù)郵件。Koshy指出，其根本原因是由于消息格式的改變，和隨后緩存加載在偏移管理器的終止，而這個偏移管理器已經(jīng)被設(shè)置了一個舊的偏移量。由于這個主題分區(qū)上的低數(shù)據(jù)容量，日志壓縮和清除觸發(fā)器在部署的主題上從來沒有被觸發(fā)過。這導(dǎo)致一個舊的偏移量被當作消費者的起點，同時也使得以前已經(jīng)消費過的消息被重新讀取，并觸發(fā)了重復(fù)的電子郵件。

第二個缺陷是在一個數(shù)據(jù)部署管道中，它里面的Hadoop推送作業(yè)器會發(fā)送數(shù)據(jù)到Kafka的非生產(chǎn)環(huán)境，然后通過Kafka集群復(fù)制到生產(chǎn)集群。在發(fā)現(xiàn)取回的偏移量沒有有效檢查點的時候，復(fù)制就被卡住了。它表明前一個檢查的偏移量被丟掉了。Koshy是這樣描述根本原因的：

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

Kafka代理之間不清楚首席代理選舉的規(guī)則，這會導(dǎo)致處于分區(qū)的首席代理在完成復(fù)制延遲過程中的失敗會引起偏移量倒轉(zhuǎn)。Kafka消息的消費者發(fā)出讀取指定偏移量的請求。消費者會對主題分區(qū)檢查它們的偏移量，因此它們可以從最后一次檢查點（消費者需要重啟的點）重新開始。檢查可以發(fā)生在很多時候，包括消費者失敗、重啟或者分區(qū)被加到主題里以及在消費者實例之間的分區(qū)分發(fā)規(guī)則需要改變的時候。如果一個消費者獲取這個代理的主題日志之外的偏移關(guān)鍵字，它會收到OffsetOutOfRange的錯誤。消費者需要根據(jù)它們auto.offset.reset配置，來重新設(shè)置它們的偏移為最新或最早的有效偏移。

Koshy指出，

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

Koshy還著重指出一些盡早發(fā)現(xiàn)偏移倒回的最佳實踐，包括：通過監(jiān)控集群中模糊不清的首席選舉率，基于消費者延遲的監(jiān)控和告警從而避免誤報。監(jiān)控日志壓縮的指標（特別是最大臟讀率傳感器的），以及偏移管理的指標（如偏移緩存大小、提交率、組數(shù)傳感器等）。偏移量自己被存在一個可復(fù)制、可分區(qū)、可壓縮的日志中，它們與內(nèi)部的_consmer_offsets主題相關(guān)聯(lián)。Koshy推薦在調(diào)試進程中盡早導(dǎo)出內(nèi)部主題，從而避免日志壓縮刪除那些潛在有用的數(shù)據(jù)。特定的主題由消息組成，任何的時間偏移提交請求都會被發(fā)送到偏移管理代理中。在這種情況下，消費者和代理的日志也是可能有用的。