背景

這篇討論源於資料庫領域大師 Michael Stonebraker 在 2010 年針對 CAP 定理發表的觀點。他當時主張在企業級應用中，網路分區（Partition）發生的機率極低，因此開發者不應為了追求可用性（Availability）而輕易犧牲一致性（Consistency），並對當時興起的 NoSQL 運動與最終一致性（Eventual Consistency）趨勢提出質疑。

社群觀點

即便這篇文章已過時十五年，HN 社群仍認為其核心爭議在今日的雲端架構下依然鮮活。許多討論者指出，Stonebraker 當年的預言在某種程度上得到了驗證：隨著分散式系統技術的成熟，業界重新認識到強一致性的價值，並發現其擴展性遠超早期的想像。支持 CP（一致性與分區容忍）系統的觀點認為，在現代雲端基礎設施中，與其忍受複雜且難以除錯的最終一致性，不如在極少數的分區發生時選擇暫時犧牲可用性，因為讓客戶端知道請求被拒絕並稍後重試，通常比數據出錯更容易處理。

然而，社群中對於「最終一致性」的必要性存在激烈辯論。部分留言者認為 Stonebraker 低估了全球化雲端環境中網路分區的常態性，並以銀行轉帳、航空公司超訂、甚至超市標價與結帳的時差為例，強調現實世界本質上就是由無數個最終一致性的流程所構成。他們主張，強一致性往往只是教科書上的理想模型，在跨國或跨系統的複雜交易中，最終仍須依賴補償機制與對帳來達成邏輯上的正確。

對此，反對者則精確地指出，不應將「業務流程的延遲」與「底層數據庫的一致性」混為一談。銀行雖然在跨行轉帳上看似是最終一致，但其內部的帳本資料庫絕對要求強一致性，否則對帳將失去基準。此外，開發者若在應用層試圖模擬 ACID 特性，往往會因為忽略隔離層級（Isolation Levels）或錯誤使用 ORM 工具而導致數據破壞。討論中也提到，許多宣稱具備 ACID 的資料庫在預設配置下（如 Read Committed）其實並未提供完全的隔離，這使得追求「絕對一致性」在實務上比想像中更具挑戰。

最後，社群達成了一種務實的共識：對於 90% 的中小型企業而言，強一致性的傳統資料庫已綽綽有餘，過度追求 Web Scale 或 AP 系統往往是解決了並不存在的問題。但在處理如 DNS 或全球規模的快取系統時，最終一致性則是不可避的設計選擇。正如留言所言，CAP 定理並非非黑即白的選擇，而是關於延遲閾值與錯誤處理的權衡。

延伸閱讀

留言中推薦了多篇 Stonebraker 的經典論文，包括 2005 年的《What Goes Around Comes Around》以及 2024 年與 Andy Pavlo 合著的續篇，後者回顧了過去二十年資料庫技術的演進。此外，Peter Bailis 的部落格文章《When is ACID ACID?》也被提及，用於深入探討分散式系統中一致性的真實定義。針對高性能交易系統的設計，討論者也推薦參考 Martin Thompson 關於 LMAX 與 Aeron 的相關研究。