第3章　事務處理

事務處理幾乎在每一個信息系統中都會涉及，它存在的意義是為了保證系統中所有的數據都是符合期望的，且相互關聯的數據之間不會產生矛盾，即數據狀態的一致性（Consistency）。按照數據庫的經典理論，要達成這個目標，需要三方面共同努力來保障。

·原子性（Atomic）：在同一項業務處理過程中，事務保證了對多個數據的修改，要么同時成功，要么同時被撤銷。

·隔離性（Isolation）：在不同的業務處理過程中，事務保證了各業務正在讀、寫的數據相互獨立，不會彼此影響。

·持久性（Durability）：事務應當保證所有成功被提交的數據修改都能夠正確地被持久化，不丟失數據。

以上四種屬性即事務的“ACID”特性，但筆者對這種說法其實不太認同，因為這四種特性并不正交，A、I、D是手段，C是目的，前者是因，后者是果，弄到一塊去完全是為了拼湊個單詞縮寫。

事務的概念雖然最初起源于數據庫系統，但今天已經有所延伸，不再局限于數據庫本身了。所有需要保證數據一致性的應用場景，包括但不限于數據庫、事務內存、緩存、消息隊列、分布式存儲，等等，都有可能用到事務，后文里筆者會使用“數據源”來泛指所有這些場景中提供與存儲數據的邏輯設備，但是上述場景所說的事務和一致性含義可能并不完全一致，說明如下。

·當一個服務只使用一個數據源時，通過A、I、D來獲得一致性是最經典的做法，也是相對容易的。此時，多個并發事務所讀寫的數據能夠被數據源感知是否存在沖突，并發事務的讀寫在時間線上的最終順序是由數據源來確定的，這種事務間一致性被稱為“內部一致性”。

·當一個服務使用到多個不同的數據源，甚至多個不同服務同時涉及多個不同的數據源時，問題就變得困難了許多。此時，并發執行甚至是先后執行的多個事務，在時間線上的順序并不由任何一個數據源來決定，這種涉及多個數據源的事務間一致性被稱為“外部一致性”[1]。

外部一致性問題通常很難使用A、I、D來解決，因為這樣需要付出很大甚至不切實際的代價；但是外部一致性又是分布式系統中必然會遇到且必須要解決的問題，為此我們要轉變觀念，將一致性從“是或否”的二元屬性轉變為可以按不同強度分開討論的多元屬性，在確保代價可承受的前提下獲得強度盡可能高的一致性保障，也正因如此，事務處理才從一個具體操作上的“編程問題”上升成一個需要全局權衡的“架構問題”。

人們在探索這些解決方案的過程中，產生了許多新的思路和概念，有一些概念看上去并不那么直觀，在本章，筆者會通過同一個場景事例講解如何在不同的事務方案中貫穿、理順這些概念。

額外知識

場景事例

Fenix’s Bookstore是一個在線書店。當一本書被成功售出時，需要確保以下三件事情被正確地處理：

·用戶的賬號扣減相應的商品款項；

·商品倉庫中扣減庫存，將商品標識為待配送狀態；

·商家的賬號增加相應的商品款項。

接下來，筆者將逐一介紹在“單個服務使用單個數據源”“單個服務使用多個數據源”“多個服務使用單個數據源”以及“多個服務使用多個數據源”下，可以采用哪些手段來保證數據在以上場景中被正確地讀寫。

[1] 外部一致性的定義起源于Google的Spanner的論文，地址為https://cloud.google.com/spanner/docs/true-time-external-consistency。