想象一下你馬上出發要去一家餐廳吃飯，但是你去之前不確定會不會滿桌，你又不想排號，這時的你會有兩個選擇，如果你是個樂觀的人，內心戲可能會是「管他的，去了再說，大不了沒座就回來」，反之，如果你是一個悲觀的人，可能會先打個電話預約一下，先確認下肯定有座，同時交點定金讓餐廳預留好這個座位，這樣就可以直接去了，
上面這個例子很直觀的對應了兩種事務模型的行為，樂觀事務模型就是直接提交，遇到沖突就回滾，悲觀事務模型就是在真正提交事務前，先嘗試對需要修改的資源上鎖，只有在確保事務一定能夠執行成功后，才開始提交，
理解了上面的例子后，樂觀事務和悲觀事務的優劣就很好理解了，對于樂觀事務模型來說，比較適合沖突率不高的場景，因為直接提交（“直接去餐廳”）大概率會成功（“餐廳有座”），沖突（“餐廳無座”）的是小概率事件，但是一旦遇到事務沖突，回滾（回來）的代價會比較大，悲觀事務的好處是對于沖突率高的場景，提前上鎖（“打電話交定金預約”）的代價小于事后回滾的代價，而且還能以比較低的代價解決多個并發事務互相沖突、導致誰也成功不了的場景，
再次解釋背后思想：
常規的鎖是先互斥，再修改資料，不管是不是發生了沖突，我們都會先做互斥，但樂觀鎖不同，它是先計算出所有修改的資料，然后最后一步統一提交修改，提交時會進行沖突檢查，如果沒有沖突，也就是說，在我之前沒有人提交過新版本，或者雖然有人提交過新版本，但是修改的資料和我所依賴的資料并不相關，那么提交會成功，否則就是發生了沖突，會放棄本次修改，
為什么要用樂觀鎖?至少它讓鎖資料庫的粒度降到最低，判斷沖突的邏輯也都是可預期的行為，這就避免了出現死鎖的可能，我們很容易可以推理得知，在所有并行執行的事務中，必然有一個事務的提交會成功，這樣就避免了饑餓（永遠都沒人可以成功），
reference:
1. https://pingcap.com/blog-cn/pessimistic-transaction-the-new-features-of-tidb/
2. 許式偉架構課
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/32425.html
標籤：架構設計
上一篇：DjangoRestFramework，restful規范、APIview、決議器組件、Postman等
下一篇：分布式事務，解決方案