單領導者（事務）相對於多領導者複製的優勢
我正在閱讀我全心全意推薦的優秀書籍*“設計數據密集型應用程序”*，但我對比較多領導者（即多作者）複製與單領導者複製的部分感到困惑。我理解基本區別：在多領導者中，多個領導者節點可以接受寫入，每個領導者將其寫入發送給其他領導者，並且您有解決衝突的規則來決定如何合併它們。單一領導者使用事務解決並發問題。
以下兩段描述了多寫入器如何更具挑戰性，因為衝突不會立即解決。我的問題是之後。
$$ This paragraph and the diagram are describing multi-leader. $$例如，考慮一個 wiki 頁面同時被兩個使用者編輯，如圖 5-7 所示$$ copied below $$. 使用者 1 將頁面標題從 A 更改為 B，同時使用者 2 將頁面標題從 A 更改為 C。每個使用者的更改都會成功應用到他們的本地領導者。但是，當非同步複製更改時，會檢測到衝突。在單領導者數據庫中不會出現此問題。 在單主數據庫中，第二個寫入者要麼阻塞並等待第一個寫入完成，要麼中止第二個寫入事務，迫使使用者重試寫入。另一方面，在多領導設置中，兩次寫入都成功，並且僅在稍後的某個時間點非同步檢測到衝突。那時，要求使用者解決衝突可能為時已晚。
我在這裡看到了多作家的困難，但我懷疑單作家會更好。
考慮兩個人大致同時編輯維基百科頁面時最可能發生的一系列事件： 1) 人 1 載入編輯頁面，需要 3-5 秒來編輯標題並送出。2）人2載入編輯頁面，需要3-5秒編輯標題並送出。應用編輯的每個數據庫事務只有幾毫秒，因此更新一個接一個發生的可能性遠大於它們同時發生的可能性。因此，如果您擔心這兩個人的更新中的一個會失去，您需要以某種方式解決應用程序級別的潛在衝突；交易不會真正幫助你。
此外，在兩個事務確實重疊的情況下，簡單地延遲一個事務直到另一個事務完成並不能幫助使用者。一旦它恢復，它仍然會覆蓋第一個使用者的數據。
所以我的問題是，是否有一些我缺少的有用的交易技術在這裡實際上很有用？自從我嘗試使用事務以來已經有一段時間了，所以我的技術已經生疏了。
我能想到的最好的改進：添加
AND title='A'到兩個UPDATE語句的末尾，並在事務中添加第二條語句來檢查受影響的行數，如果等於 0 則回滾。回滾沒有效果，但它會向客戶端指示失敗。但這有點駭人聽聞。我認為以支票開始交易不會有幫助（即
SELECT * FROM pages WHERE title='A'並確保您能拿回一些東西）。即使只有一筆交易會勝出，兩筆交易都可能在開始時看到“A”。
我在閱讀同一本書時遇到了您的問題。
我認為要考慮的問題是，在單一領導者場景中，有一個自然的總排序，因為它可以為每個事務應用一個序列號。它總是知道“哪個先發生”。由於時鐘偏差等問題，很難或不可能在多領導者中正確執行此操作。
所以我認為歸結為，系統甚至知道哪個先發生。
您的“寫如果”建議被多次提及/使用，我認為與單/多領導者無關。寫 if 是應用程序級別（使用者可能必須輸入他們認為的舊值），而單/多領導者可能不會向使用者公開。在單個領導者中，寫 if 將明確避免衝突；總排序決定了哪個操作首先發生，而第二個到達那裡的操作將由於寫入 if 而安全失敗。
我認為 multi 的優勢是基於性能的；單一的優點是基於“正確性/複雜性”。
驗證數據未更改
無狀態應用程序也有類似的問題。（例如網路）
數據可以在“選擇要顯示的數據進行編輯”和“最終使用者點擊
UPDATE按鈕”之間切換。
SELECT為確保數據在和UPDATE請求之間沒有改變，該UPDATE過程應該：
- 使用某種鎖序列化對行的訪問。
- Oracle 開發人員更喜歡
SELECT ... FOR UPDATE
- 驗證數據沒有改變。
- 計算雜湊值並比較之前/之後的值。
- 或查看“最後更新時間戳”列並比較之前/之後的值。
- 相應地執行 DML。
COMMIT/ROLLBACK& 釋放鎖。
- Oracle 行鎖通過
COMMIT/釋放ROLLBACK
- 根據需要提出錯誤。
這個實現是非常公式化的。
該邏輯可以在用於創建應用程序的框架內實現（例如，
Oracle APEX“自動 DML”程序預設執行此操作）。基於模板的程式碼生成器可以生成過程/函式（表 API
$$ TAPI $$) 通過使用適當的模板來實現這個邏輯。