Kafka和Redis如何解決流處理挑戰

danny_2018發表於2022-08-19

雖然流可以是處理大量資料的有效方式,但它們也有自己的挑戰。讓我們看看其中的一些。

1. 如果消費者無法像製作人建立塊那樣快速處理塊,會發生什麼?一個例子:如果消費者比生產者慢50%,會怎麼樣?如果我們從一個10GB的檔案開始,這意味著當生產者處理完所有10GB時,消費者只處理了5GB。剩餘的5GB在等待處理時會發生什麼情況?突然之間,分配給仍然需要處理的資料的50到100位元組必須擴充套件到5GB。

圖1:如果消費者的速度比生產者慢,則需要額外的記憶體。

2. 這只是一個噩夢場景。還有其他的。例如,如果消費者在處理一條生產線時突然失效,會發生什麼情況?你需要一種跟蹤正在處理的行的方法,以及一種允許重新讀取該行和隨後的所有行的機制。

圖2:當消費者失效時。

3. 最後,如果你需要能夠處理不同的事件並將其傳送給不同的消費者,會發生什麼?此外,如果增加額外的複雜性,一個消費者的程式依賴於另一個消費者,那麼就有相互依賴的程式,會怎麼樣?一個真正的風險是,你最終會遇到一個複雜的、緊耦合的、難以管理的單體系統——隨著不斷新增和刪除不同的生產者和消費者,這些需求將不斷變化。

舉個例子(圖3),假設我們有一家大型零售店,擁有數千臺伺服器,支援透過網路應用和移動應用進行購物。

假設我們正在處理三種與支付、庫存和Web伺服器日誌相關的資料,每種資料都有一個相應的消費者:“支付處理器”、“庫存處理器”和“Web伺服器事件處理器”。此外,兩個消費者之間存在著重要的相互依賴關係。在處理庫存之前,需要先驗證付款。最後,每種型別的資料都有不同的目的地。如果是支付事件,則將輸出傳送到所有系統,如資料庫、電子郵件系統、CRM等。如果是Web伺服器事件,則僅將其傳送到資料庫。如果是庫存事件,則將其傳送到資料庫和CRM。

你可以想象,這很快就會變得非常複雜和混亂。這還不包括我們需要為每個消費者處理的慢消費者和容錯問題。

圖3:緊耦合的挑戰,因為有多個生產者和消費者。

當然,所有這些都假設你正在處理一個單體架構,你有一臺伺服器接收和處理所有事件。你將如何處理微服務架構?在這種情況下,許多小型伺服器,即微服務,將處理事件,它們都需要能夠相互通訊。突然間,你不僅僅有多個生產者和消費者,它們還分散在多個伺服器上。

微服務的一個關鍵好處是,它們解決了根據不斷變化的需求擴充套件特定服務的問題。不幸的是,微服務只解決了一些問題。我們的生產者和消費者之間仍然存在緊耦合,我們保留了庫存微服務和支付服務之間的依賴關係。我們在最初的流媒體示例中指出的問題仍然存在:

——我們還沒有弄清楚當消費者崩潰時該怎麼辦。

——我們還沒有找到一種管理慢消費者、不會迫使我們大幅擴大緩衝區規模的方法。

——我們還沒有辦法確保資料不會丟失。

這些只是一些主要挑戰。讓我們看看如何解決這些問題。

圖4:微服務世界中緊耦合的挑戰

專用流處理系統

正如我們所看到的,流可以非常適合處理大量資料,但也帶來了一系列挑戰。為了解決這些挑戰,引入了新的專用系統,如Apache Kafka和Redis Streams。在Kafka和Redis流的世界中,伺服器不再像流那樣位於中心,其他一切都圍繞著它們。

資料工程師和資料架構師經常共享這種以流為中心的世界觀。當流成為中心時,一切都是流水線型的,這並不奇怪。

圖5顯示了前面看到的緊耦合示例的直接對映。讓我們看看它在高層次上是如何工作的。

——在這裡,流和資料(事件)是一等公民,而不是處理它們的系統。

——任何有興趣傳送資料(生產者)、接收資料(消費者)或同時傳送和接收資料(生產者和消費者)的系統都連線到流處理系統。

——由於生產者和消費者是解耦的,因此可以隨意新增其他消費者或生產者。你可以聽任何你想聽的事件。這使得它非常適合微服務架構。

——如果消費者速度較慢,則可以透過新增更多消費者來增加消費。

——如果一個消費者依賴於另一個消費者,你可以簡單地監聽該消費者的輸出流,然後進行處理。例如,在上圖中,庫存服務在處理庫存事件之前從庫存流(紫色)和支付處理流(橙色)的輸出接收事件。這就是解決相互依賴問題的方法。

——流中的資料是持久的(與在資料庫中一樣)。任何系統都可以隨時訪問任何資料。如果由於某種原因資料沒有被處理,你可以重新處理它。

許多流挑戰一度看似艱鉅,甚至無法克服,但只要把流放在中心,就可以輕易解決。這就是為什麼越來越多的人在他們的資料層中使用Kafka和Redis Streams,這也是為什麼資料工程師將流視為世界的中心。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31547898/viewspace-2911155/,如需轉載,請註明出處,否則將追究法律責任。

相關文章