節點錯誤後資料不出現部分更新，這是哪個特性？
原題
某人工智慧團隊使用分散式資料庫（Distributed Database）儲存模型訓練資料，並在更新訓練樣本時啟用多節點交易。若其中一個節點在交易過程中發生錯誤，但系統仍確保整體資料不會出現部分更新、最終狀態維持一致，下列何者最能說明此現象？
白話
AI 團隊的資料庫分散在多個節點上。他們做了一次跨節點的資料更新（交易）。中途有一個節點出錯了，但系統確保最終結果不會是「部分節點更新了、部分節點沒有」的不一致狀態：要麼全部成功，要麼全部回復到原來的樣子。
問你：這種「要麼全部成功、要麼全部回復」的特性，是資料庫的哪一個 ACID 特性？
先自己選一個答案，再看完整解析。
一句話總結
「交易不能只做一半」：一個節點失敗就全部回復（Rollback），不會留下部分更新的「殘局」，這說的是 ACID 的原子性（Atomicity）：交易是不可分割的最小單位，只有「全部成功提交」和「全部回復」兩種結果。
情境
先感受問題：轉帳失敗到底是轉走了還是沒轉？
大家最熟悉的資料庫交易例子是銀行轉帳：
阿志要把 1,000 元從帳戶 A 轉到帳戶 B。這個操作分兩步：
Step 1：帳戶 A 扣 1,000 元
Step 2：帳戶 B 加 1,000 元
如果 Step 1 成功、Step 2 失敗（例如系統當機），就出現了「帳戶 A 少了 1,000 元，但帳戶 B 沒有多 1,000 元」的恐怖情況：錢憑空消失了。
原子性（Atomicity）就是防止這種情況的機制：要麼 Step 1 和 Step 2 都成功，要麼一個都不做（把 Step 1 的扣款回復）。不允許「做了一半」的中間狀態存在。
題目中的分散式資料庫多節點交易是相同道理：多個節點的更新要麼全部完成，要麼因為某個節點失敗而全部回復。
舊方法
不同 ACID 特性各自解決什麼問題
- 沒有原子性（Atomicity）的危害：交易做到一半系統當機，資料庫處於「部分更新」的不一致狀態。轉帳的錢消失、訂單扣了庫存但沒生成訂單記錄，各種業務邏輯錯誤全部出現。
- 沒有一致性（Consistency）的危害：交易完成後，資料違反了預設的業務規則（例如：帳戶餘額變成負數，超過了「不能為負」的完整性約束）。即使每筆交易本身是原子性的，結果也可能是錯的。
- 沒有隔離性（Isolation）的危害：兩個並行交易互相看到對方的「未提交」修改，導致「幻讀」「不可重複讀」「髒讀」等問題。例如：兩個人同時搶最後一個座位，各自的交易都以為搶到了。
- 沒有持久性（Durability）的危害：交易已成功提交，但資料沒有真正寫入永久儲存，系統重開後資料消失。就像收到轉帳確認簡訊，但對方說他的帳戶沒收到。
- ACID 在分散式環境的挑戰：分散式資料庫面對 CAP 定理（一致性、可用性、分區容錯性三選二），強 ACID 需要犧牲部分可用性，設計時需要在不同場景做取捨。
新方法
「不部分更新、失敗就全部回復」精確對應原子性
題目的關鍵描述是：「一個節點在交易過程中發生錯誤，但系統仍確保整體資料不會出現部分更新、最終狀態維持一致。」
逐字對照：
「不會出現部分更新」= 交易不能做到一半 = 原子性
「最終狀態維持一致」= 配合原子性的結果（要麼完整成功，要麼完整失敗）
「維持一致」這個說法容易讓人誤以為是「一致性（Consistency）」，但仔細看，題目說的是「因為做到一半失敗，系統把它回復，所以最終沒有部分更新」，這個機制是 Rollback（回復），是原子性的實現方式，不是一致性。
一致性是「資料符合業務完整性規則」，而不是「失敗時回復到原始狀態」。
這就是選項 A 講的：系統透過原子性（Atomicity）確保交易必須全部成功或全部回復（Rollback）。
ACID 四特性速記
| 特性 | 保護什麼 |
|---|---|
| Atomicity（原子性） | 交易全部成功或全部失敗，不存在中間狀態；失敗時 Rollback |
| Consistency（一致性） | 交易前後資料必須滿足所有業務完整性規則（如外鍵、唯一性、非負約束） |
| Isolation（隔離性） | 並行交易互不干擾，一個交易的中間狀態對其他交易不可見 |
| Durability（持久性） | 交易一旦 Commit，即使系統崩潰，資料也永久保留（通常透過 Write-Ahead Log 實現） |
分散式環境的挑戰：2PC（Two-Phase Commit）
單機資料庫的原子性相對容易實現（Undo Log 記錄撤銷操作）。分散式多節點環境下，原子性需要協調協議（Coordination Protocol）：
- 準備階段（Prepare Phase）：協調者詢問所有參與節點「你能提交嗎？」，各節點鎖定資源並回答 Ready 或 Abort。
- 提交階段（Commit Phase）：如果所有節點都說 Ready，協調者發 Commit 指令；只要有一個節點說 Abort，協調者發 Rollback 指令，所有節點撤銷已做的修改。
2PC 的問題：如果協調者在 Commit 指令發出後、部分節點執行前崩潰，會造成「部分提交」的不確定狀態（in-doubt transaction）。這是分散式系統中原子性實現的困難所在，衍生出 Saga 模式、TCC（Try-Confirm-Cancel）等更靈活的方案。
CAP 定理對 ACID 的影響：分散式系統在網路分區時，必須在一致性（C）和可用性（A）之間取捨。NoSQL 資料庫（如 Cassandra、MongoDB）通常選擇最終一致性（Eventual Consistency）和高可用性，犧牲強一致性；關聯式資料庫（MySQL、PostgreSQL）傾向犧牲部分可用性來保證強一致性。
錯選項
為什麼其他選項是錯的
B系統透過一致性（Consistency）確保交易完成後資料符合完整性規則
字面在說什麼
因為題目說「最終狀態維持一致」，所以是一致性（Consistency）。
為什麼不對
這是最常見的誤解陷阱。「一致性（Consistency）」在 ACID 中的含義是：交易完成後，資料必須滿足預先定義的業務完整性規則（例如：帳戶餘額不能為負、外鍵必須存在）。它關注的是「規則是否被滿足」，不是「失敗時是否回復」。題目說的「不出現部分更新」和「Rollback 回復」是原子性的機制，不是一致性。
誰會選錯
看到「維持一致」就聯想到「Consistency（一致性）」的人。這是出題者故意在題目措辭上設的陷阱，需要精確理解四個特性的定義才能辨別。
C系統透過隔離性（Isolation）避免多筆交易同時存取或修改相同資料
字面在說什麼
隔離性保護交易不受其他並行交易干擾。
為什麼不對
隔離性關注的是「並行多筆交易之間的互相影響」，例如「交易 A 未提交的修改，是否對交易 B 可見」。題目說的情境是「單一交易因為某節點錯誤而失敗」，是單一交易的完整性問題，不涉及多個並行交易的互相干擾，與隔離性無關。
誰會選錯
把「多節點」誤解為「多筆交易」的人。多節點是單一交易分散在多個節點上執行，不是多個並行交易。
D系統透過持久性（Durability）確保交易一旦提交，其結果將永久保留於資料庫中
字面在說什麼
交易成功提交後，資料不會因為系統崩潰而消失。
為什麼不對
持久性關注的是「已成功提交的交易，其結果是否永久寫入儲存」。但題目說的情境是「交易中途失敗」，重點是「失敗後的處理」，不是「成功提交後的保留」。持久性是在交易成功後才發揮作用，而題目的問題發生在交易還沒成功時。
誰會選錯
把持久性和原子性的觸發時機搞混的人。持久性關注「成功後不丟資料」，原子性關注「失敗時不留殘局」。兩者都很重要，但保護的是不同階段的問題。
變形題
同個考點下次怎麼變形
餘額不能為負是資料庫規則，和 ACID 有關係嗎？
答案
一致性（Consistency）。ACID 的一致性保證：交易完成後，資料必須符合所有預設的完整性約束（包括「餘額 ≥ 0」這個業務規則）。如果一筆轉帳交易會讓帳戶餘額變成負數，這個交易會被拒絕，維持資料庫的業務完整性。
兩個交易同時看到同一個狀態，然後都執行了。
答案
隔離性（Isolation）沒有被滿足。兩個並行交易都讀取了「還沒更新」的庫存值，這是「髒讀（Dirty Read）」或「不可重複讀（Non-repeatable Read）」的問題。隔離性要求交易的中間狀態對其他並行交易不可見，確保並發執行和序列執行的結果相同。解決方案是設定適當的事務隔離級別（例如：Serializable 或 Repeatable Read）。
交易明明成功了，重開後卻消失？
答案
持久性（Durability）沒有被滿足。持久性保證：一旦交易成功提交（Commit），即使系統隨後崩潰，資料也永久保留。通常透過 Write-Ahead Log（WAL）或 Redo Log 實現：每次修改都先寫日誌再寫磁碟，系統崩潰後可以從日誌重建已提交的修改。
沒有 ACID 不就很危險嗎？為什麼還有人用？
答案
NoSQL 資料庫犧牲強一致性（Strong Consistency），採用最終一致性（Eventual Consistency），換取的是更高的可用性（Availability）和水平擴展能力（Scalability）。對社群媒體貼文、IoT 感測器資料、推薦系統日誌這類場景，偶爾讀到稍微過時的資料是可以接受的，但系統必須 24/7 不停機且支撐超大規模寫入。這是 CAP 定理的取捨。
資料庫的 Atomicity 和化學的 atom（原子）名字來源一樣嗎？
答案
是的，靈感相同。化學的「原子」是不可分割的最小物質單位（雖然後來知道原子可以再分，但在化學反應層面原子是最小單位）。資料庫的「原子性」借用這個概念：交易是不可分割的最小操作單位，不能只執行一部分。「要麼整個交易都發生，要麼整個交易都不發生」，就像化學反應中原子作為整體參與，不能只送走一半的電子。
延伸
想再往下看，這 5 個
- ACID（ACID 特性）
資料庫交易的四大保證：原子性、一致性、隔離性、持久性，確保資料操作的可靠性。 - 資料管線（Data Pipeline）
AI 模型訓練資料的流動路徑，ACID 保證是資料更新管線可靠性的基礎。 - 資料品質監控（Data Quality Monitoring）
ACID 保證交易層面的完整性，資料品質監控則持續追蹤資料的準確性和一致性。 - 分散式訓練（Distributed Training）
AI 模型訓練常用分散式架構，底層資料庫的 ACID 特性確保訓練資料不出現不一致。 - 資料版本控制（Data Versioning）
與 ACID 的持久性相輔相成，確保每次訓練資料的更新都可追蹤和回溯。