樂觀鎖和悲觀鎖的一個例子

　　想象一下你立刻出發要去一家餐廳吃飯，可是你去以前不肯定會不會滿桌，你又不想排號。這時的你會有兩個選擇，若是你是個樂觀的人，心裏戲可能會是「管他的，去了再說，大不了沒座就回來」。反之，若是你是一個悲觀的人，可能會先打個電話預定一下，先確認下確定有座，同時交點定金讓餐廳預留好這個座位，這樣就能夠直接去了。
　　上面這個例子很直觀的對應了兩種事務模型的行爲，樂觀事務模型就是直接提交，遇到衝突就回滾，悲觀事務模型就是在真正提交事務前，先嚐試對須要修改的資源上鎖，只有在確保事務必定可以執行成功後，纔開始提交。
理解了上面的例子後，樂觀事務和悲觀事務的優劣就很好理解了。對於樂觀事務模型來講，比較適合衝突率不高的場景，由於直接提交（「直接去餐廳」）大機率會成功（「餐廳有座」），衝突（「餐廳無座」）的是小几率事件，可是一旦遇到事務衝突，回滾（回來）的代價會比較大。悲觀事務的好處是對於衝突率高的場景，提早上鎖（「打電話交定金預定」）的代價小於過後回滾的代價，並且還能以比較低的代價解決多個併發事務互相沖突、致使誰也成功不了的場景。

　　再次解釋背後思想：

　　常規的鎖是先互斥，再修改數據。無論是否是發生了衝突，咱們都會先作互斥。但樂觀鎖不一樣，它是先計算出全部修改的數據，而後最後一步統一提交修改。提交時會進行衝突檢查，若是沒有衝突，也就是說，在我以前沒有人提交過新版本，或者雖然有人提交過新版本，可是修改的數據和我所依賴的數據並不相關，那麼提交會成功。不然就是發生了衝突，會放棄本次修改。

爲何要用樂觀鎖?至少它讓鎖數據庫的粒度降到最低，判斷衝突的邏輯也都是可預期的行爲，這就避免了出現死鎖的可能。咱們很容易能夠推理得知，在全部並行執行的事務中，必然有一個事務的提交會成功。這樣就避免了飢餓（永遠都沒人能夠成功）。

 

reference:

1.  https://pingcap.com/blog-cn/pessimistic-transaction-the-new-features-of-tidb/

2. 許式偉架構課