* 悲觀鎖(Pessimistic Lock) 悲觀鎖顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。 傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。 * 樂觀鎖(Optimistic Lock), 樂觀鎖顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。 樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量，像數據庫如果提供類似于`write_condition`機制的其實都是提供的樂觀鎖。 樂觀鎖的特點先進行業務操作，不到萬不得已不去拿鎖。即“樂觀”的認為拿鎖多半是會成功的，因此在進行完業務操作需要實際更新數據的最后一步再去拿一下鎖就好。 樂觀鎖在數據庫上的實現完全是邏輯的，不需要數據庫提供特殊的支持。一般的做法是在需要鎖的數據上增加一個版本號，或者時間戳，然后按照如下方式實現： ~~~go 1. SELECT data AS old_data, version AS old_version FROM …; 2. 根據獲取的數據進行業務操作，得到new_data和new_version 3. UPDATE SET data = new_data, version = new_version WHERE version = old_version if (updated row > 0) { // 樂觀鎖獲取成功，操作完成 } else { // 樂觀鎖獲取失敗，回滾并重試 } ~~~ 樂觀鎖是否在事務中其實都是無所謂的，其底層機制是這樣：在數據庫內部update同一行的時候是不允許并發的，即數據庫每次執行一條update語句時會獲取被update行的寫鎖，直到這一行被成功更新后才釋放。 因此在業務操作進行前獲取需要鎖的數據的當前版本號，然后實際更新數據時再次對比版本號確認與之前獲取的相同，并更新版本號，即可確認這之間沒有發生并發的修改。如果更新失敗即可認為老版本的數據已經被并發修改掉而不存在了，此時認為獲取鎖失敗，需要回滾整個業務操作并可根據需要重試整個過程。 兩種鎖各有優缺點，不可認為一種好于另一種，像樂觀鎖適用于寫比較少的情況下，即沖突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。 但如果經常產生沖突，上層應用會不斷的進行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。