課堂

1.1 簡介 現在樂趣開始了——交易如何運作的理論。當您在不同線程中更改相同數據時，如何保持系統正常工作？或者您想在另一筆交易中執行一筆交易？我們將開始通過研究事務的隔離性來尋找這些問題的答案…… 事務隔離級別是一個條件值，它決定了由於 DBMS 中邏輯並行事務的執行，允許不一致數據的程度。事務隔離級別的規模包含許多值，從低到高排列；更高的隔離級別對應於更好的數據一致性，但它的使用可能會減少物理上並行事務的數量。 相反，較低的隔離級別允許更多並行事務，但會降低數據準確性。因此

2.1 讀未提交 “事務隔離級別”是指DBMS內部機制（即不需要特殊編程）對事務並行執行時出現的上述所有或部分類型的數據不一致的保護程度。SQL-92 標准定義了四個隔離級別的範圍： 讀取未提交 讀提交 可重複讀 可序列化 第一個是最弱的，最後一個是最強的，後面的每一個都包含了前面的所有。 最低（第一）隔離級別。如果多個並行事務試圖修改同一個表行，那麼最後一行的值將由整個成功完成的事務集決定。在這種情況下，不僅可以讀取邏輯上不一致的數據，還可以讀取尚未記錄更改的數據。 實現此

3.1 酸的出現 縮寫詞 ACID於 1983 年首次出現在 Theo Haerder 和 Andreas Reuter 的一篇文章中。為了簡化文字並使其更具說服力，我將對本文的一個片段進行翻譯（略有刪減）。此代碼段使用銀行交易示例，其中資金從一個帳戶轉移到另一個帳戶。 事務的概念，在示例中包括$BEGIN_TRANSACTION和之間與數據庫的所有交互$COMMIT_TRANSACTION，要求所有操作不可分割地執行：要么所有操作都正確反映在數據庫狀態中，要么什麼都不發生。

4.1 關於 Brewera 的一致性 首先，Eric Brewer 不是，也從未聲稱自己是數據庫專家。他屬於分佈式系統社區，他在“分佈式計算原理”會議上發表了著名的演講，其中出現了 CAP“定理”。（順便說一下，十年後的 2010 年，他再次在同一個會議上作了受邀演講，在這次演講中，他特別給出了一些分佈式系統的例子，其發展考慮到了“定理”的 CAP。）在這方面對數據庫領域中使用的術語有自己的解釋。 特別地，術語“立即一致性”是指在用戶收到系統關於某個數據更新操作成功完成的通

5.1 同時性問題 讓我們從一個遙遠的理論開始。 程序員創建的任何信息系統（或簡單地說，一個應用程序）都由幾個典型的塊組成，每個塊都提供一部分必要的功能。例如，緩存用於記住資源密集型操作的結果以確保客戶端更快地讀取數據，流處理工具允許您將消息發送給其他組件進行異步處理，批處理工具用於“以一定的周期性“耙”累積的數據量。 . 在幾乎每個應用程序中，數據庫 (DB) 都以一種或另一種方式涉及，它們通常執行兩個功能：從您那裡收到數據時存儲數據，然後根據請求提供給您。很少有人會想到創

6.1 縮寫之戰：BASE vs. 酸 “在化學中，pH 測量水溶液的相對酸度。pH 範圍從 0（強酸性物質）到 14（強鹼性物質）；25°C 的純水的 pH 值為 7，呈中性。 數據工程師用這個比喻來比較數據庫的交易可靠性。” 可能的想法是：pH 值越高，即 數據庫越接近“鹼性”（“BASE”），交易越不可靠。 流行的關係型數據庫，如MySQL，就是在ACID的基礎上出現的。但是在過去的十年裡，所謂的 NoSQL 數據庫，在這個名稱下結合了幾種非常不同類型的數據庫，在沒有

7.1 為什麼需要 我們已經詳細討論了 ACID 的所有屬性、它們的用途和用例。如您所見，並非所有數據庫都提供 ACID 保證，為了更好的性能而犧牲它們。因此，很可能在您的項目中選擇了不提供 ACID 的數據庫，並且您可能需要在應用程序端實現一些必要的 ACID 功能。而且，如果您的系統被設計為微服務或某種其他類型的分佈式應用程序，那麼一個服務中的正常本地事務現在將變成分佈式事務——當然，將失去其 ACID 特性，即使數據庫每個單獨的微服務都是 ACID。 我不想為您提供關於

8.1 交易 ID 它被指定為 XID 或 TxID（如果有區別，請告訴我）。時間戳可以用作 TxID，如果我們想將所有操作恢復到某個時間點，它可以發揮作用。如果時間戳不夠精細，就會出現問題——然後事務可以獲得相同的 ID。 因此，最可靠的選擇是生成唯一的 UUID prod ID。在 Python 中這很容易： >>> import uuid