“你們的系統能實現強一致性嗎？”作為過去幾年一直在開發流處理系統的從業者，我經常被問到這個問題。我時常想自信地推銷我們的產品，但現實情況是，回答這個問題并不簡單。其中的挑戰并不在于問題本身，而在于 “一致性”（Consistency） 對于不同技術背景的人來說有不同的含義。

實際上，來自以下不同背景的人：

• 數據庫
• 分布式系統
• 流處理系統

對“一致性”都有自己的理解。沒有了解清楚背景就回答可能會導致誤解。在本文中，我將澄清在這些不同的數據系統中“一致性”究竟意味著什么。

1. 數據庫中的“一致性”

在傳統數據庫中，“一致性”是 ACID 原則（Atomicity, Consistency, Isolation, Durability）中的一個基石，它保證了每個事務將數據庫從一個合法狀態轉換到另一個合法狀態。例如，在一個銀行交易中，一個賬戶被扣款，另一個賬戶被存款，“一致性”確保總余額保持不變。需要注意的是，這與“原子性”（Atomicity）不同，“原子性”指的是事務的要么成功要么失效特性。例如，“原子性”確保事務中的所有操作要么全部成功，要么全部失敗，確保數據庫中不會留下不完整的事務。

總而言之，數據庫的“一致性”指的是確保事務處理前后數據的正確性和有效性。

2. 分布式系統中的“一致性”

在討論分布式系統時，“一致性”常常指的是 CAP 定理中的一個基本概念，該定理最初由加州大學伯克利分校的研究人員提出，目前已成為分布式系統學術課程和專業討論中的基礎話題。

在 CAP 定理中，“一致性”具體指的是在不同節點分布的各種副本的數據一致性。在分布式系統中確保這種“一致性”尤其具有挑戰性。該定理強調了三個關鍵屬性之間的權衡：consistency, availability, 和 partition tolerance（一致性、可用性和分區容錯性）。根據 CAP 定理，分布式系統在同一時間只能實現這三個屬性中的兩個。

在這個背景下，“一致性”確保在任何給定時間，不同節點的所有數據副本都顯示相同的信息。這對于維護數據的完整性至關重要，特別是在涉及網絡故障或延遲的情況下。該定理揭示了在多個節點間保持數據同步的固有困難，突出了在設計和維護強大的分布式系統時，平衡這三個競爭需求的持續挑戰。

3. 流處理系統中的“一致性”

圍繞流處理系統中“一致性”的討論通常與涉及數據庫或分布式系統時不同，反映出其獨特的需求和挑戰。在文章《一致性與完整性：重新思考 Apache Kafka 中的分布式流處理》中，作者將“exactly-once” semantics（精確一次性）語義定義為流處理環境中“一致性”的一個關鍵特性。

在流處理系統中，維護“一致性”不是圍繞replicating data，而是確保每個數據事件只被處理一次，即使是在系統故障的情況下。以一個實時處理的金融交易為例，如果系統在處理過程中崩潰，系統恢復后我們必須確保交易不會被重復處理。保證“exactly-once”對于維護流數據的一致性和完整性至關重要，它確保了無論系統中斷與否，每個交易都被準確處理且僅處理一次。

4. 用戶真正需要什么？

為了突出不同數據系統中“一致性”需求的差異，請看下表：

系統類型	一致性需求	示例
數據庫	事務完整性	銀行交易應始終保持賬戶平衡
分布式系統	跨節點的數據一致性	社交媒體上的個人資料更新必須在各處一致
流處理系統	消息順序和消息處理語義保證	每筆金融交易實時處理且只處理一次

實際上，用戶和企業真正需要的是可靠性和數據完整性，這超出了標準教科書對“一致性”的定義。他們需要系統不僅強大可靠，還能有效處理現實世界的復雜性。對于用戶來說真正成功的系統是能夠始終如一地提供正確的結果，實現這種級別的“一致性”不僅僅需要系統“看起來”正確，而是理論上合理且功能上可靠。

5. 分布式流數據庫中的“一致性”

接下來讓我們深入探討更有趣的內容：分布式流數據庫中的“一致性”。如果你不熟悉流數據庫是什么，可以參考如 KsqlDB 和 PipelineDB 的傳統系統。本質上，流數據庫是專為流處理定制的數據庫，感興趣的讀者可以參考我之前的文章《什么是流式數據庫》。為了降低執行流處理的成本和復雜性，我們開發了一個名為 RisingWave 的分布式流數據庫。

分布式流數據庫是數據庫、分布式系統和流處理系統的結合體。那么，它的“一致性”是什么含義呢？理想情況下，分布式流數據庫的“一致性”應該同時滿足上述三種系統的需求，但當然這也取決于具體的系統實現。無法在此詳細介紹所有分布式流數據庫的一致性模型，讓我們重點關注 RisingWave：RisingWave 中的“一致性”是什么樣的？讓我們從三個維度來探討。

5.1 數據庫背景下的“一致性”

RisingWave 能夠實現。RisingWave 能有效地確保內部狀態無縫地從一個合法狀態轉變到另一個合法狀態。但需要注意的是，雖然 RisingWave 支持只讀事務，但它不支持跨不同表的讀寫事務。因此，如果有人需要一個 OLTP 數據庫來管理復雜的事務負載，他們可能會選擇 MySQL、Postgres、CockroachDB 或 TiDB 等解決方案。出現這個方案設計主要有以下兩個原因：

• 專注于流數據處理：RisingWave 專注于優化流數據處理。完整的事務處理能力可能會給系統帶來顯著的復雜性。
• 與傳統 OLTP 數據庫的集成：通常，傳統的 OLTP 數據庫在上游處理事務，序列化事務變更。RisingWave 作為下游系統，專注于實時分析。整合復雜的事務處理可能會導致顯著的性能下降，特別是在現實操作的苛刻條件下。

此外，RisingWave 能夠理解和處理來自上游 OLTP 數據庫的事務語義，這對于金融等領域的客戶來說是一個關鍵特性。

5.2 分布式系統背景下的“一致性”

RisingWave 能夠實現。RisingWave 可以在多個區域內實現高可用性。雖然 RisingWave 沒有實施如 Paxos 或 Raft 這樣的復雜一致性協議來確保跨副本的一致性，但它利用 S3 進行數據存儲。S3 不僅存儲數據庫表，還存儲流處理的內部狀態，有效地在多個副本間復制數據以保持一致性。

5.3 流處理系統背景下的“一致性”

RisingWave 能夠實現。RisingWave 通過確保exactly-once semantics 和 adeptly managing out-of-order data processing 而表現出色。這種能力確保無論數據流如何混亂，每個數據事件都能被準確地處理一次，從而保持流數據的一致性。

6. 總結

“一致性”的含義在數據庫、分布式系統和流處理系統中有顯著差異：

• 數據庫注重事務完整性。
• 分布式系統強調跨節點的數據一致性。
• 流處理系統優先考慮保證處理上的“exactly-once ”。

RisingWave 作為一個強大且適應性強的分布式流數據庫，有效地滿足了這些多樣化的“一致性”需求。不僅能在理論上達到這些“一致性”標準，還在實際應用中表現出色，使得 RisingWave 始終是實現數據“一致性”的可靠解決方案。

7. 關于 RisingWave

RisingWave 是一款開源的分布式流處理數據庫，旨在幫助用戶降低實時應用的開發成本。RisingWave 采用存算分離架構，提供 Postgres-style 使用體驗，具備比 Flink 高出 10 倍的性能以及更低的成本。

👨?🔬加入 RW 社區，歡迎關注公眾號：RisingWave 中文開源社區

🧑?💻快速上手 RisingWave，歡迎體驗入門教程：github.com/risingwave

💻深入使用 RisingWave，歡迎閱讀用戶文檔：zh-cn.risingwave.com/docs

🔍更多常見問題及答案，歡迎搜索留言: risingwavelabs/discussions