樂觀鎖 Optimistic Locking
樂觀鎖的概念
樂觀鎖機制采取了更加寬松的加鎖機制。樂觀鎖是相對悲觀鎖而言，也是為了避免數據庫幻讀、業務處理時間過長等原因引起數據處理錯誤的一種機制，但樂觀鎖不會刻意使用數據庫本身的鎖機制，而是依據數據本身來保證數據的正確性
CAS 樂觀鎖技術，當多個線程嘗試使用CAS同時更新同一個變量時，只有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程並不會被掛起，而是被告知這次競爭中失敗，並可以再次嘗試。
為什么要用樂觀鎖 ?
例如銀行轉賬流程
- B 的賬戶余額為 ￥300
- A 向 B 轉賬 ￥700
- 在 A 向 B 轉賬的同時 C 要 取走 B 的 ￥200（此時 B 的余額還是 ￥300）
- 這樣的流程走下來后 B 的余額會覆蓋成 ￥100
設置樂觀鎖后
- C 的取款操作: 會判斷數據表當前的數據與操作時的數據是否相同(數據庫中B的余額 300 是否與操作時已經查出來 B 的余額是否一致)
- 如果數據相同則會更新數據，否則會認為 已經查出來 B 的數據為過期數據
使用樂觀鎖后卻產生了新的問題，就是ABA問題
- ABA問題: A 將 B 更新成 ￥1000 后 D 又將 B 更新為 ￥300，此時的 C 還認為 B 沒有被更新過，C 的操作還是會成功.但不代表這個過程就是沒有問題的
為了解決ABA問題,在數據庫表中增加version字段
- 其目的是達到順序遞增,也就是修改這條數據后version會產生變化,這樣其他正在操作這條數據的線程都會執行失敗,因為他們都變成了過期數據
- 例子:
update t_user set sex = 1,version = version + 1 where user_id = 1 and version = 0;
這句SQL語句執行第一次會執行成功,執行第二次就會失敗,因為version已經發生改變
發展趨勢
在當前高並發,高可用等並發量較大情況下使用樂觀鎖基本成為第一選擇
樂觀鎖並未真正的加鎖，效率高。一旦鎖的力度掌握不好，更新失敗的概率就會比較高，也很容易發生業務失敗
本文就先說到這里，有問題歡迎留言討論