Redis流與Kafka相比如何？

Redis流 VS Kafka

Kafka以解決大規(guī)模數(shù)據(jù)處理問題而聞名，并被廣泛部署在許多知名公司的基礎設施中。早在2015年，LinkedIn有60個集群，總共有1100個Broker，每秒處理1300萬條信息。

但事實證明，規(guī)模并不是Kafka唯一擅長的事情。它所提倡的編程范式--分區(qū)、有序、事件處理--對于你可能面臨的許多問題都是一個很好的解決方案。例如，如果事件代表的是要被索引到搜索數(shù)據(jù)庫的行，那么最后的修改就是最后的索引，這一點很重要，否則搜索將無限期地返回陳舊的數(shù)據(jù)。同樣，如果事件代表用戶行為，處理第二個事件（"用戶升級賬戶"）可能依賴于第一個（"用戶創(chuàng)建賬戶"）。這種范式與傳統(tǒng)的作業(yè)隊列系統(tǒng)不同，在傳統(tǒng)的作業(yè)隊列中，事件是由許多工作者同時從隊列中彈出的，這很簡單，可擴展，但它破壞了任何排序保證。假設你想要有序的處理，但也許你不想使用Kafka，因為它是一個難以操作或昂貴的重型系統(tǒng)的聲譽。Redis現(xiàn)在有了5.0版本發(fā)布的"流 "數(shù)據(jù)結構，與之相比如何？它是否解決了同樣的問題？

Kafka的架構

我們先來看看Kafka的基本架構。基本的數(shù)據(jù)結構是主題。它是一個按時間排序的記錄序列，只需追加。使用這種數(shù)據(jù)結構的好處在Jay Kreps的經(jīng)典博文The Log中得到了很好的描述。

主題Topic被分區(qū)，以使它們能夠擴展：每個主題可以被托管在單獨的Kafka實例上。每個分區(qū)中的記錄都被分配了連續(xù)的ID，稱為偏移量，它可以唯一地識別分區(qū)中的每個記錄。消費者按順序處理記錄，保持跟蹤其最后看到的偏移量。由于記錄被持久化在一個主題中，多個消費者可以相互獨立地處理記錄。

在實踐中，你可能會將你的處理分布在許多機器上。為了實現(xiàn)這一點，Kafka提供了一個 "消費者組 "的抽象，它是一組合作的進程，從一個主題消費數(shù)據(jù)。一個主題的分區(qū)被劃分給組內(nèi)的成員。然后，當成員加入或離開該組時，必須重新分配分區(qū)，以便每個成員都能獲得公平的分區(qū)份額。這就是所謂的再平衡算法。

請注意，一個分區(qū)只能由消費者組的一個成員來處理。(但一個成員可能負責多個分區(qū))這使得嚴格有序的處理得到保證。

這套工具是非常有用的。你可以通過添加更多的工作者來輕松地擴展你的處理，而Kafka則負責處理分布式協(xié)調(diào)問題。

Redis的流數(shù)據(jù)結構

Redis的 "流 "數(shù)據(jù)結構是如何比較的？Redis流在概念上等同于上面描述的Kafka主題的一個分區(qū)，但有一些小的區(qū)別。

它是一個持久的、有序的事件存儲（與Kafka中相同）

它有一個可配置的最大長度（與Kafka中的保留期相比）。

事件存儲鍵和值，就像Redis Hash（相對于Kafka中的單個鍵和值）。

最主要的區(qū)別是，Redis中的消費者組與Kafka中的消費者組完全不同。

在Redis中，一個消費者組是一組全部從同一流讀取的進程。Redis確保事件只會被傳遞給組內(nèi)的一個消費者。例如，在下圖中，消費者1不會處理'9'，它會跳過它，因為消費者2已經(jīng)看到它了。消費者1將得到下一個未被任何其他組成員看到的事件。

組的作用是將單個流的處理并行化。這看起來很像一個傳統(tǒng)的作業(yè)隊列結構。因此，它失去了作為流處理核心的排序保證，這是很不幸的。

流處理作為一個客戶端庫

那么，如果Redis只提供有效的具有作業(yè)隊列語義的主題的單一分區(qū)，我們怎么能在Redis之上建立一個流處理引擎？好吧，如果你想要Kafka的功能，你需要自己構建它們。這意味著要實現(xiàn)。

1. 事件分區(qū)。你需要創(chuàng)建N個流，并將每個流視為一個分區(qū)。然后，在發(fā)送時，你需要決定哪個分區(qū)應該接收它，大概是基于事件的哈希值或其中的一個字段。

2. 一個工人分區(qū)分配系統(tǒng)。為了擴展和支持多個工作者，你需要創(chuàng)建一個算法，在他們之間分配分區(qū)，確保每個工作者擁有一個相互排斥的子集，也就是相當于Kafka的 "再平衡 "系統(tǒng)。

3. 有確認的順序處理。每個工作者都需要迭代其每個分區(qū)，跟蹤其偏移量。盡管Redis消費者組有作業(yè)隊列語義，但它們在這里可以提供幫助。訣竅是每個組使用一個消費者，然后為每個分區(qū)創(chuàng)建一個組。然后每個分區(qū)將被按順序處理，你可以利用內(nèi)置的消費者組狀態(tài)跟蹤。Redis不僅可以跟蹤偏移量，還可以跟蹤每個事件的確認，這是很強大的。

這是絕對的最低要求。如果你希望你的解決方案是健壯的，你可能還想考慮錯誤處理：除了崩潰你的工作者，也許你會想要一個機制，將錯誤轉發(fā)到一個 "死信 "流并繼續(xù)處理。

好消息是--如果你喜歡Python的話--已經(jīng)解決了這些問題，并且在一個新發(fā)布的名為Runnel的庫中解決了更多問題。如果你想從Redis上類似Kafka的語義中獲益，歡迎你來看看。下面是它的外觀，基本上與上面的Kafka圖之一相同。

工作者通過Redis中實現(xiàn)的鎖來協(xié)調(diào)他們對分區(qū)的所有權。他們通過一個特殊的 "控制 "流相互溝通。更多信息，包括架構和再平衡算法的詳細分解，請參閱Runnel文檔。

權衡

Redis是大規(guī)模事件處理的好選擇嗎？有一個基本的權衡：因為一切都在內(nèi)存中，獲得了無與倫比的處理速度，但它不適合存儲無限制的數(shù)據(jù)量。使用Kafka，你可能愿意無限期地保存你的所有事件，但使用Redis，你肯定要存儲最近的事件的固定窗口--只夠你的處理器有一個舒適的緩沖區(qū)，以防止它們變慢或崩潰。這意味著你可能還想使用一個外部的長期事件存儲，例如S3，以便能夠重放它們，這增加了你的架構的復雜性，但降低了成本。

研究這個問題的主要動機是在部署和操作Redis時涉及的易用性和低成本。這就是為什么它對Kafka有吸引力。它也是一套神奇的工具，經(jīng)受住了時間的考驗，非常了不起。事實證明，經(jīng)過努力，它也可以支持分布式流處理范式.

審核編輯：黃飛