3.1 酸的出現
縮寫詞 ACID於 1983 年首次出現在 Theo Haerder 和 Andreas Reuter 的一篇文章中。為了簡化文字並使其更具說服力，我將對本文的一個片段進行翻譯（略有刪減）。此代碼段使用銀行交易示例，其中資金從一個帳戶轉移到另一個帳戶。
事務的概念，在示例中包括$BEGIN_TRANSACTION和之間與數據庫的所有交互$COMMIT_TRANSACTION，要求所有操作不可分割地執行：要么所有操作都正確反映在數據庫狀態中，要么什麼都不發生。$COMMIT_TRANSACTION如果在到達用戶之前的任何時間點輸入ERROR包含 的語句$RESTORE_TRANSACTION，則數據庫中不會反映任何更改。
為了實現這種不可分割性，交易必須具有以下四個屬性：
原子性（Atomicity）。交易必須是上述的all-or-nothing類型，無論發生什麼，用戶都必須知道交易處於什麼狀態。
一致性（Consistency）。達到其正常事務結束 (EOT) 並因此提交其結果的事務可維護數據庫一致性。換句話說，每個成功的交易，根據定義，只提交有效的結果。這個條件是支持第四個屬性——耐久性的必要條件。
隔離（隔離）。事務中發生的事件必須對其他並發執行的事務隱藏。如果不滿足此條件，則由於上述原因，交易將無法返回到開始的位置。為了實現隔離，使用稱為同步的方法......
耐久性（Durability）。事務完成並將其結果提交到數據庫後，系統必須確保這些結果在任何後續故障中仍然存在。由於不存在跨越事務集的控制範圍，因此數據庫管理系統 (DBMS) 無法控制超出事務邊界的範圍。
因此，必須保證用戶，如果系統通知他發生了什麼事，那麼這個“事情”就真的發生了。由於，根據定義，任何（成功完成——S.K.）交易都是正確的，因此不可避免地出現錯誤交易（即包含錯誤數據的交易）的結果只能通過相應的“反”交易（countertransaction）來消除。
3.2 交易的出現
這四個屬性——原子性、一致性、隔離性和持久性 (ACID)——描述了影響數據庫系統設計許多方面的事務範式的核心特徵。因此，我們認為，任何一個系統對交易的支持能力，都是這個系統好壞的試金石（ACID測試）。
將資金從一個帳戶轉移到另一個帳戶的簡單 PL/1-SQL 程序。
FUNDS_TRANSFER. PROCEDURE,
$BEGIN_TRANSACTION;
ON ERROR DO; /* in case of error */
$RESTORE_TRANSACTION, /* undo all work */
GET INPUT MESSAGE; /* reacquire input */
PUT MESSAGE ('TRANSFER FAILED'); /* report failure */
GO TO COMMIT;
END;
GET INPUT MESSAGE; /* get and parse input */
EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
AMOUNT FROM MESSAGE,
$UPDATE ACCOUNTS /* do debit */
SET BALANCE ffi BALANCE - AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
$UPDATE ACCOUNTS /* do credit */
SET BALANCE = BALANCE + AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
$INSERT INTO HISTORY /* keep audit trail */
<DATE, MESSAGE>;
PUT MESSAGE ('TRANSFER DONE'); /* report success */
COMMIT: /* commit updates */
$COMMIT_TRANSACTION;
END; /* end of program */我提供了這段代碼的示例來提醒您，實際上，ACID 屬性一方面可以被視為任何聲稱支持事務的 DBMS 的要求，另一方面，作為事務的定義一個數據庫系統。這個定義完全符合世俗慣例。例如，很難想像執行銀行交易的客戶（無論是在現場人工出納員的幫助下還是使用網上銀行）不期望銀行滿足 ACID 的所有屬性。不支持其交易的 ACID 屬性的銀行充其量會失去客戶，最壞的情況是破產。
3.3 酸連接
ACID 屬性不可分割是非常重要的，丟棄其中任何一個都會使剩餘的組合變得毫無意義。特別是，如果我們丟棄一致性屬性（在上面引用中使用的意義上），那麼我們將失去交易正確性的標準。數據庫系統將無法以任何有意義的方式決定是否允許提交事務，並且必須在應用程序代碼中執行對在數據庫當前狀態下執行的操作正確性的所有檢查。
您需要了解，在這種情況下，我們談論的是邏輯一致性。銀行的客戶需要銀行按照他制定的並為客戶所知的規則進行工作，這樣就不可能執行任何違反這些規則的交易，從而使同一客戶的下一次交易在一個環境同意按照這些規則。
在線商店的客戶需要他訂購併支付的商品及時交付給他（根據客戶已知的既定規則）。否則，他不會信任這家店。同時，無論是銀行的客戶端還是網店的客戶端，都不關心企業內部的廚房，內部採取什麼動作來完成自己的交易。客戶端不關心這個企業的物理一致性是如何維護的，物理層是如何操作的。
如果 DBMS 負責維護事務（和數據庫）的邏輯一致性，那麼應用程序將變得更簡單、更易理解且更可靠。應用領域（銀行、商店、倉庫等）關於交易和數據有效狀態的所有邏輯都進入數據庫系統。而且這個系統的需求很簡單：支持ACID事務，同時考慮到應用在數據庫中提供的一致性規則。在我看來，拒絕 ACID 事務給應用程序開發人員帶來了極大的困難，無論你喜歡與否，他們都必須自己實現類似的東西以滿足客戶的自然需求。
我再次注意到 ACID 屬性實際上定義了事務的概念。在我看來，為了至少有可能討論不支持事務一致性屬性的事務數據管理系統，絕對有必要定義術語事務在這種情況下的含義。
不幸的是，今天在許多情況下（特別是，這是 NoSQL 方向的特徵），人們在談論支持 OLTP 應用程序時根本沒有具體說明它們意味著什麼類型的事務。因此，在本文中，我將使用組合 ACID 事務來指代真實的事務，而不限定術語事務將在非正式意義上使用，在不同的上下文中有所不同。
現在讓我們處理 CAP 的“定理”，並嘗試弄清楚 Brewer 意義上的一致性意味著什麼。