Redpanda：用C++重寫的Kafka

您可以在此處找到有關其他安裝選項的更多資訊。

Redpanda是一個基於附加日誌的相容Kafka的分散式流系統。與 Kafka 相比，Redpanda 旨在為使用者提供更低的延遲和更低的操作複雜性。它在內部使用Raft 共識演算法，而不是依賴於Zookeeper的單獨安裝。Redpanda 使用 Kafka 的有線協議：Redpanda 使用常規的 Kafka 客戶端，而不是釋出自己的客戶端庫。

像 Kafka 一樣，Redpanda 提供了一組命名的、部分有序的日誌，稱為主題。每個主題被分片成一個或多個分割槽，每個分割槽是一個完全有序的訊息日誌。訊息在分割槽中的位置由唯一的單調遞增整數offset標識，它提供了總順序。偏移量可能是稀疏的：日誌中的一些偏移量用於內部訊息，例如事務後設資料，這些對客戶端是不可見的。

Kafka 客戶端分為幾個部分。使用者使用生產者客戶端向分割槽寫入（產生）訊息，並使用消費者客戶端從分割槽中讀取（輪詢）訊息。使用者可以在手動指定的分割槽中產生和消費，或者允許系統自動選擇訊息寫入哪個分割槽，以及消費者從哪個分割槽讀取。

輪詢訊息不會刪除它們。相反，消費者透過從給定分割槽讀取連續偏移量來模擬“從佇列中消費”。消費者既可以為自己分配特定的分割槽並自己管理偏移量，也可以訂閱一個主題並允許 Redpanda 自動管理分割槽和偏移量。可以將偏移量提交給 Redpanda，它會持久地儲存它們，以便崩潰的消費者可以從他們（或他們的前輩）停止的地方繼續。

Redpanda 實現了 Kafka 的事務協議，但是這種支援在 22.1.1 版本中仍然存在一個功能標誌。Redpanda 沒有為使用者提供有關如何使用事務的具體文件，而是依賴 Kafka 的文件。Kafka 的官方文件規定消費者可以在兩個隔離級別之間進行選擇：read_uncomitted和read_committed. read_uncommitted允許消費者檢視“所有訊息，甚至是已中止的事務訊息”。該read_committed設定“將僅返回已提交的事務性訊息”。

Confluence 的Transactional Messaging wiki 頁面提供了 Kafka 中的事務應用程式所期望的五個簡單要求。起初，對於試圖理解事務語義的使用者來說，這看起來像是一個很有希望的總結：

1. 原子性：消費者的應用程式不應暴露於來自未提交事務的訊息。
2. 永續性：經紀人不能丟失任何已提交的交易。
3. 排序：事務感知消費者應該在每個分割槽內看到原始事務順序中的事務。
4. 交錯：每個分割槽都應該能夠接受來自事務和非事務生產者的訊息
5. 事務中不應有重複的訊息。

1. 對於壓縮主題，事務的某些訊息可能會被較新版本覆蓋。
2. 事務可能跨越日誌段。因此，當舊段被刪除時，我們可能會在事務的第一部分丟失一些訊息。
3. 消費者可能會在交易中尋找任意點，因此會丟失一些初始訊息。
4. 消費者可能不會從參與事務的所有分割槽中消費。因此，他們將永遠無法讀取構成交易的所有訊息。

事務 ID
在 Kafka/Redpanda 中執行事務的每個生產者都必須選擇一個事務 ID：一個含義不明確的字串，但如果選擇不正確，可能會導致事務系統表現出未定義的行為。

Kafka 事務設計文件有一個標題為“事務保證”的部分，詳細說明了事務 ID 如何確保跨會話的冪等性和事務恢復：
當提供這樣的 TransactionalId 時，Kafka 將保證：

1. 跨應用程式會話的冪等生產。這是透過在具有相同 TransactionalId 的新例項上線時遮蔽舊代來實現的。
2. 跨應用程式會話的事務恢復。如果應用程式例項死亡，則可以保證下一個例項已完成任何未完成的事務（無論是中止還是提交），從而在恢復工作之前使新例項處於乾淨狀態。