今天，我們將探討一個截然不同的思路。如果我們的目標不是跨越洲際，而是要榨干單個數據中心內的每一分性能，那系統設計會變成什么樣？這就是本課的主角 FaRM ，它通過 樂觀并發控制 (Optimistic Concurrency Control) 和對尖端硬件的極致運用，給出了一個驚人的答案。

請注意，FaRM 是一個研究原型，目前還沒有已知的生產系統直接使用它。它的價值在于探索設計的可能性。像微軟、Google 這樣的公司之所以發表這類論文，一方面是為了吸引頂尖人才，展示公司前沿的智力挑戰；另一方面，許多研究人員本身就有推動技術進步的學術使命感。

換句話說， FaRM 有些前提或者假設比較理想，不適合現有生產環境。

FaRM 的性能秘訣（一）：榨干硬件潛力

FaRM 的高性能并非空穴來風，它建立在軟硬件協同設計的基礎上，首先是兩種顛覆傳統瓶頸的硬件技術。

非易失性內存 (NVRAM)

傳統數據庫最大的瓶頸之一是磁盤 I/O。一次寫入到磁盤需要耗費數毫秒，即使是高速的固態硬盤 (SSD) 也要上百微秒。相比之下，內存 (DRAM) 的寫入只需要幾百納秒，速度快了成千上萬倍。FaRM 的設計哲學就是：所有數據都必須放在內存里。

但這帶來了持久性的問題：內存是易失的，一旦斷電，數據就會丟失。FaRM 采用了一種巧妙且經濟的方式來打造 非易失性內存 (Non-Volatile RAM) 。它沒有使用昂貴的專用 NVDIMM 硬件，而是在每個機架上部署了帶鋰電池的 不間斷電源 (UPS) 。

工作流程如下：

1. 正常運行時，所有數據寫入都直接在內存中完成，速度極快。
2. 當外部電源中斷時，硬件會通知軟件，服務器立即切換到電池供電。
3. FaRM 軟件會暫停所有事務處理，利用電池提供的幾分鐘電量，將內存中的全部內容轉儲到 SSD 上進行持久化。
4. 當電力恢復后，系統會從 SSD 中將數據重新加載回內存，然后從斷點處繼續運行。

這個設計至關重要。如果沒有電池和 NVRAM，FaRM 就必須為每個事務同步地寫入 SSD，其性能將會一落千丈，因為一次 SSD 寫入比 FaRM 的目標延遲高出太多。那能否用更便宜的機械硬盤 (HDD) 來代替 SSD 呢？理論上可以，但 HDD 的寫入速度要慢得多，這意味著需要容量更大、成本也更高的電池來支撐更長的轉儲時間，經濟上可能得不償失。

使用電池來保證斷電時的數據持久性這個想法并不新鮮，早在 90 年代初的 Harp 文件系統就用過類似的技術。不過，FaRM 這種機架級別的分布式 UPS 方案在通用系統中并不常見。

遠程直接內存訪問 (RDMA)

第二個傳統瓶頸在于網絡，尤其是處理網絡消息所帶來的 CPU 開銷。一次傳統的 遠程過程調用 (Remote Procedure Call, RPC) 流程相當繁瑣：

應用層 (App)                                   應用層 (App)
      |                                              ^
      v                                              |
  系統調用 (System Call)                       中斷 (Interrupt)
  ------------- 內核空間 (Kernel Space) ------------------
      |                                              ^
      v                                              |
  Socket 緩沖區 -> TCP協議棧                      TCP協議棧 <- NIC 驅動
      |                                              ^
      v                                              |
  NIC 驅動  --------------------------------------->  NIC

這個過程涉及到昂貴的系統調用、內核與用戶空間之間的數據拷貝以及中斷處理，極大地消耗了 CPU 資源，使得服務器處理小消息的速率受到限制。

FaRM 則使用了支持 遠程直接內存訪問 (Remote Direct Memory Access, RDMA) 的特殊 網卡 (Network Interface Card, NIC) 。RDMA 允許一臺機器上的應用程序直接讀寫另一臺遠程機器的內存，而完全不需要遠程機器 CPU 的參與，這個過程被稱為 單邊 RDMA (one-sided RDMA) 。請求由 NIC 直接處理，這繞過了遠程服務器的整個操作系統內核，幾乎消除了所有傳統 RPC 的 CPU 開銷，讓網絡通信的速度真正接近硬件的極限。

FaRM 的性能秘訣（二）：專為 RDMA 設計的軟件

有了強大的硬件，還需要同樣出色的軟件來發揮其潛力。FaRM 的軟件設計完全圍繞著如何最高效地利用 RDMA 和 NVRAM 。

系統架構與角色

FaRM 是一個分片、多副本的系統。數據被切分成多個 region，每個 region 都有一個主副本和多個備份副本，以實現容錯。系統中有三種核心角色：

• Primary (主副本) ：每個數據分片有且僅有一個主副本，負責處理該分片所有的讀寫請求。
• Backup (備份副本) ：被動地接收來自協調者的更新日志，保持與主副本數據一致，用于故障恢復。
• Configuration Manager (CM, 配置管理器) ：一個借助 ZooKeeper 實現的高可用服務，負責維護集群的元數據，例如哪些機器存活、數據分片的副本分布在哪些機器上等。

樂觀并發控制 (OCC) 的核心思想

這是本節課的重中之重。FaRM 采用 樂觀并發控制 (Optimistic Concurrency Control, OCC) 的核心原因，是為了最大化地利用單邊 RDMA 讀取的性能優勢。

• 悲觀鎖 (如 Spanner 的 2PL)：在訪問數據時首先加鎖，確保獨占。這種方式安全直接，但每次讀取都需要服務器 CPU 的介入來檢查和獲取鎖，無法利用單邊 RDMA。
• 樂觀鎖 ：假定事務之間的沖突很少發生。事務執行時，自由地讀取數據，并將所有寫操作緩存在本地。直到最后提交時，才進入一個“驗證”階段，檢查在此期間是否有其他事務修改了它讀取過的數據。如果驗證通過，則提交成功；如果檢測到沖突，則事務中止并回滾。

FaRM 的四階段提交協議正是為 RDMA 量身定制的 OCC 實現。

剖析 FaRM 的提交協議

讓我們一步步解析這個協議（對應論文中的 Figure 4）：

1. 執行 (Execute) ：作為事務協調者 (TC) 的客戶端，使用快速的單邊 RDMA 從主副本上讀取所需的對象，無需加鎖。它會記下所有讀取對象的版本號，并將寫操作緩存在本地。
2. 鎖定 (LOCK) ：當事務準備提交時，TC 會向所有被它 寫入 的對象所在的主副本發送 LOCK 記錄。這條記錄通過 RDMA 直接寫入主副本的日志中，包含了新值和原始版本號。主副本的 CPU 在輪詢日志時發現這條記錄，會使用一個原子操作（compare-and-swap）來檢查對象的版本號是否匹配并且未被鎖定。如果匹配，就設置鎖定標記；否則，鎖定失敗，整個事務將中止。
3. 驗證 (VALIDATE) ：對于那些只被 讀取 而未被寫入的對象，TC 無需執行完整的加鎖操作。它會進行一次更輕量的驗證：通過單邊 RDMA 再次讀取這些對象的版本號。如果版本號發生了變化，或對象已被其他事務鎖定，說明發生了沖突，事務同樣會中止。這個優化大大減少了只讀事務的開銷。
4. 提交備份 (COMMIT-BACKUP) ：當鎖定和驗證都成功后，TC 確信事務是有效的。為了保證容錯，它會將包含所有新數據的 COMMIT-BACKUP 記錄寫入所有相關備份副本的日志中。TC 只需等待 NIC 返回的硬件 ACK，確認數據已安全存入備份副本的 NVRAM 即可，無需等待備份副本的 CPU 進行任何處理。
5. 提交主庫 (COMMIT-PRIMARY) ：一旦所有備份副本都確認收到日志，TC 會向主副本發送最終的 COMMIT-PRIMARY 記錄。至此，事務被正式視為已提交。主副本在處理這條日志時，會應用寫入、更新版本號并釋放鎖，使更改對其他事務可見。

最后，當事務在所有副本上都完成后，協調者會發起一個 截斷 (Truncate) 操作，通知各副本可以安全地刪除這條事務對應的日志條目了。截斷會刪除某個點之前的所有日志，以回收空間。

解答一致性與并發的疑慮

• 執行期間讀到不一致數據怎么辦？ FaRM 確實允許在事務執行中看到可能不一致的狀態（例如，另一個最終會中止的事務留下的中間結果）。但 FaRM 保證，任何看到這種不一致性的事務，在提交時都會因驗證失敗而被中止。因此，應用程序需要有足夠的防御性，不能因為暫時的不一致而崩潰，要能堅持到最后的提交階段，由 FaRM 來決定成敗。
• 高并發修改同一對象會怎樣？ OCC 在高沖突場景下表現不佳。如果大量事務同時修改同一個對象，大部分事務會在 LOCK 或 VALIDATE 階段失敗，然后不斷中止和重試，導致系統吞吐量急劇下降。FaRM 的出色性能數據，很大程度上是因為其測試負載的沖突率較低。
• COMMIT-BACKUP 期間會失敗嗎？ 會。如果某個備份副本因為硬件故障而沒有響應，并且此時 TC 也崩潰了，那么在后續的恢復流程中，這個事務可能會被中止。
• 為什么論文圖 7 中延遲會飆升？ 這標志著系統已達到其處理能力的飽和點。當客戶端發送請求的速率超過了服務器的處理極限時，請求就會開始排隊等待，這種等待時間反映為延遲的急劇增加。

局限性與總結

FaRM 雖然強大，但它并非終結所有妥協的“銀彈”。它是在特定約束下取得極致性能的典范，其局限性也十分明顯：

• 高沖突敏感 ：如前所述，不適用于寫沖突頻繁的應用場景。
• 內存限制 ：整個數據集必須能完全載入集群所有機器的內存中。
• 單數據中心 ：其設計嚴重依賴數據中心內部的低延遲網絡，不適用于地理上分散的廣域網場景。
• 開發復雜性 ：它的 API 是回調式的，使用起來比較笨拙。應用代碼需要自行處理輪詢和臨時不一致等問題，對開發者要求較高。

它適合小規模使用嗎？ 完全不適合。如果你的需求只是每秒幾千次事務，那么像 MySQL 這樣成熟穩定的傳統數據庫是更簡單、更明智的選擇。只有當你需要支撐每秒數百萬甚至上千萬次事務的巨大負載時，FaRM 的設計和復雜性才顯示出其價值。

總結

FaRM 是一篇里程碑式的論文。它向我們證明了，通過顛覆性的軟硬件協同設計，我們可以在數據中心這個特定場景內，同時擁有 嚴格可串行化 的強一致性、基于多副本的 高可用性 以及無與倫比的 高性能 。它雖然是一個研究原型，但它所揭示的關于樂觀并發控制、RDMA 和 NVRAM 的潛力，為未來高性能分布式系統的設計開辟了全新的視野。