Kafka以解決大規模數據處理問題而聞名，並被廣泛部署在許多知名公司的基礎設施中。早在2015年，LinkedIn有60個集群，總共有1100個Broker，每秒處理1300萬條資訊。
但事實證明，規模並不是Kafka唯一擅長的事情。它所提倡的編程範式——分區、有序、事件處理——對於你可能面臨的許多問題都是一個很好的解決方案。例如，如果事件代表的是要被索引到搜尋資料庫的行，那麽最後的修改就是最後的索引，這一點很重要，否則搜尋將無限期地返回陳舊的數據。同樣，如果事件代表使用者行為，處理第二個事件（「使用者升級帳戶」）可能依賴於第一個（「使用者建立帳戶」）。這種範式與傳統的作業佇列系統不同，在傳統的作業佇列中，事件是由許多工作者同時從佇列中彈出的，這很簡單，可延伸，但它破壞了任何排序保證。假設你想要有序的處理，但也許你不想使用Kafka，因為它是一個難以操作或昂貴的重型系統的聲譽。
Redis現在有了5.0版本釋出的「流」數據結構，與之相比如何？它是否解決了同樣的問題？
Kafka的架構
我們先來看看Kafka的基本架構。基本的數據結構是主題。它是一個按時間排序的記錄序列，只需追加。使用這種數據結構的好處在Jay Kreps的經典博文The Log中得到了很好的描述。
主題Topic被分區，以使它們能夠擴充套件：每個主題可以被托管在單獨的Kafka例項上。每個分區中的記錄都被分配了連續的ID，稱為偏移量，它可以唯一地辨識分區中的每個記錄。消費者按順序處理記錄，保持跟蹤其最後看到的偏移量。由於記錄被持久化在一個主題中， 多個消費者可以相互獨立地處理記錄 。
在實踐中，你可能會將你的處理分布在許多機器上。為了實作這一點，Kafka提供了一個 「消費者組」的抽象，它是一組合作的行程，從一個主題消費數據。一個主題的分區被劃分給組內的成員。然後，當成員加入或離開該組時，必須重新分配分區，以便每個成員都能獲得公平的分區份額。這就是所謂的再平衡演算法。
請註意，一個分區只能由消費者組的一個成員來處理。(但一個成員可能負責多個分區)這使得嚴格有序的處理得到保證。
這套工具是非常有用的。你可以透過添加更多的工作者來輕松地擴充套件你的處理，而Kafka則負責處理分布式協調問題。
Redis的流數據結構
Redis的「流」數據結構是如何比較的？Redis流在概念上等同於上面描述的Kafka主題的一個分區，但有一些小的區別。
它是一個持久的、有序的事件儲存（與Kafka中相同）
它有一個可配置的最大長度（與Kafka中的保留期相比）。
事件儲存鍵和值，就像Redis Hash（相對於Kafka中的單個鍵和值）。
最主要的區別是，Redis中的消費者組與Kafka中的消費者組完全不同。
在Redis中，一個消費者組是一組全部從同一流讀取的行程。Redis確保事件只會被傳遞給組內的一個消費者。例如，在下圖中，消費者1不會處理'9'，它會跳過它，因為消費者2已經看到它了。消費者1將得到下一個未被任何其他組成員看到的事件。
組的作用是將單個流的處理並列化。這看起來很像一個傳統的作業佇列結構。因此，它失去了作為流處理核心的排序保證，這是很不幸的。
流處理作為一個客戶端庫
那麽，如果Redis只提供有效的具有作業佇列語意的主題的單一分區，我們怎麽能在Redis之上建立一個流處理引擎？好吧，如果你想要Kafka的功能，你需要自己構建它們。這意味著要實作：
1. 事件分區 。你需要建立N個流，並將每個流視為一個分區。然後，在發送時，你需要決定哪個分區應該接收它，大概是基於事件的哈希值或其中的一個欄位。
2. 一個工人分區分配系統 。為了擴充套件和支持多個工作者，你需要建立一個演算法，在他們之間分配分區，確保每個工作者擁有一個相互排斥的子集，也就是相當於Kafka的「再平衡」系統。
3. 有確認的順序處理 。每個工作者都需要叠代其每個分區，跟蹤其偏移量。盡管Redis消費者組有作業佇列語意，但它們在這裏可以提供幫助。訣竅是每個組使用一個消費者，然後為每個分區建立一個組。然後每個分區將被按順序處理，你可以利用內建的消費者組狀態跟蹤。Redis不僅可以跟蹤偏移量，還可以跟蹤每個事件的確認，這是很強大的。
這是絕對的最低要求。如果你希望你的解決方案是健壯的，你可能還想考慮錯誤處理：除了崩潰你的工作者，也許你會想要一個機制，將錯誤轉發到一個 "死信 "流並繼續處理。
好訊息是——如果你喜歡Python的話--已經解決了這些問題，並且在一個新釋出的名為Runnel的庫中解決了更多問題。如果你想從Redis上類似Kafka的語意中獲益，歡迎你來看看。下面是它的外觀，基本上與上面的Kafka圖之一相同。
作者透過Redis中實作的鎖來協調他們對分區的所有權。他們透過一個特殊的「控制」流相互溝通。更多資訊，包括架構和再平衡演算法的詳細分解，請參閱Runnel文件。
權衡
Redis是大規模事件處理的好選擇嗎？有一個基本的權衡：因為一切都在記憶體中，獲得了無與倫比的處理速度，但它 不適合儲存無限制的數據量 。使用Kafka，你可能願意無限期地保存你的所有事件，但使用Redis，你肯定要儲存最近的事件的固定視窗——只夠你的處理器有一個舒適的緩沖區，以防止它們變慢或崩潰。這意味著你可能還想使用一個外部的長期事件儲存，例如S3，以便能夠重放它們，這增加了你的架構的復雜性，但降低了成本。
研究這個問題的主要動機是在部署和操作Redis時涉及的易用性和低成本。這就是為什麽它對Kafka有吸重力。它也是一套神奇的工具，經受住了時間的考驗，非常了不起。事實證明，經過努力，它也可以支持分布式流處理範式。
作者丨PetterLiu
來源丨cnblogs.com/wintersun/p/16795783.html
dbaplus社群歡迎廣大技術人員投稿，投稿信箱： [email protected]
