悲觀鎖和樂觀鎖

2021-08-03 11:26:23 字數 2334 閱讀 3052

1、悲觀鎖,正如其名,它指的是對資料被外界(包括本系統當前的其他事務,以及來自外部系統的事務處理)修改持保守態度,因此,在整個資料處理過程中,將資料處於鎖定狀態。悲觀鎖的實現,往往依靠資料庫提供的鎖機制(也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性,否則,即使在本系統中實現了加鎖機制,也無法保證外部系統不會修改資料)。

2、樂觀鎖( optimistic locking )

相對悲觀鎖而言,樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依靠資料庫的鎖機制實現,以保證操作最大程度的獨占性。但隨之而來的就是資料庫效能的大量開銷,特別是對長事務而言,這樣的開銷往往無法承受。而樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖,大多是基於資料版本( version )記錄機制實現。何謂資料版本?即為資料增加乙個版本標識,在基於資料庫表的版本解決方案中,一般是通過為資料庫表增加乙個 「version」 欄位來實現。讀取出資料時,將此版本號一同讀出,之後更新時,對此版本號加一。此時,將提交資料的版本資料與資料庫表對應記錄的當前版本資訊進行比對,如果提交的資料版本號大於資料庫表當前版本號,則予以更新,否則認為是過期資料。

但是有個缺點就是只能是應用中控制,如果有跨應用修改同一條資料樂觀鎖就沒辦法了,這個時候可以考慮悲觀鎖。
只在提交操作時檢查是否違反資料完整性。[1] 樂觀鎖不能解決髒讀的問題。    樂觀鎖則認為其他使用者企圖改變你正在更改的物件的概率是很小的,因此樂觀鎖直到你準備提交所作的更改時才將物件鎖住,當你讀取以及改變該物件時並不加鎖。可見樂觀鎖加鎖的時間要比悲觀鎖短,樂觀鎖可以用較大的鎖粒度獲得較好的併發訪問效能。但是如果第二個使用者恰好在第乙個使用者提交更改之前讀取了該物件,那麼當他完成了自己的更改進行提交時,資料庫就會發現該物件已經變化了,這樣,第二個使用者不得不重新讀取該物件並作出更改。這說明在樂觀鎖環境中,會增加併發使用者讀取物件的次數。

所以悲觀鎖和樂觀鎖最大的區別是是否一直鎖定資源,悲觀鎖在事物的全流程鎖定資料,樂觀鎖不鎖定資料(用讀寫鎖是阻塞事物,而用樂觀鎖則會導致回滾。這個是一種事物衝突後的不同鎖的表象)。樂觀鎖的最大特點是在最後檢查資料是否被修改,如果已被別人修改過,則回滾資料,避免髒資料。至於事物是否衝突和加鎖沒有直接聯絡,該衝突的還是會衝突,不管你加悲觀鎖和樂觀鎖都會衝突。

除了加鎖的方式也可以使用接收鎖定的方式,思路是在資料庫中設計乙個狀態標識位,使用者在對資料進行修改前,將狀態標識位標識為正在編輯的狀態,這樣其他使用者要編輯此條記錄時系統將發現有其他使用者正在編輯,則拒絕其編輯的請求,類似於你在

作業系統

中某檔案正在執行,然後你要修改該檔案時,系統會提醒你該檔案不可編輯或刪除

悲觀鎖和樂觀鎖都是為了解決丟失更新問題或者是髒讀。悲觀鎖和樂觀鎖的重點就是是否在讀取記錄的時候直接上鎖。悲觀鎖的缺點很明顯,需要乙個持續的資料庫連線,這在web應用中已經不適合了。

不建議在資料庫層面加鎖,建議通過服務端的記憶體鎖(鎖主鍵)。當某個使用者要修改某個id的資料時,把要修改的id存入memcache,若其他使用者觸發修改此id的資料時,讀到memcache有這個id的值時,就阻止那個使用者修改。

實際應用中,並不是讓mysql去直面大併發讀寫,會借助「外力」,比如快取、利用主從庫實現讀寫分離、分表、使用佇列寫入等方法來降低併發讀寫

從資料庫廠商的角度看,使用樂觀的頁鎖是比較好的,尤其在影響很多行的批量操作中可以放比較少的鎖,從而降低對資源的需求提高資料庫的效能。再考慮聚集索引。在資料庫中記錄是按照聚集索引的物理順序存放的。如果使用頁鎖,當兩個使用者同時訪問更改位於同一資料頁上的相鄰兩行時,其中乙個使用者必須等待另乙個使用者釋放鎖,這會明顯地降低系統的效能。interbase和大多數關聯式資料庫一樣,採用的是樂觀鎖,而且讀鎖是共享的,寫鎖是排他的。可以在乙個讀鎖上再放置讀鎖,但不能再放置寫鎖;你不能在寫鎖上再放置任何鎖。鎖是目前解決多使用者併發訪問的有效手段。
1.

使用自增長的整數表示資料版本號。更新時檢查版本號是否一致,比如資料庫中資料版本為6,更新提交時version=6+1,使用該version值(=7)與資料庫version+1(=7)作比較,如果相等,則可以更新,如果不等則有可能其他程式已更新該記錄,所以返回錯誤。

2.使用時間戳來實現.

注:對於以上兩種方式,hibernate自帶實現方式:在使用樂觀鎖的字段前加annotation: @version, hibernate在更新時自動校驗該欄位。

需要使用資料庫的鎖機制,比如sql server 的tablockx(排它表鎖) 此選項被選中時,sql  server  將在整個表上置排它鎖直至該命令或事務結束。這將防止其他程序讀取或修改表中的資料。

在實際生產環境裡邊,如果併發量不大且不允許髒讀,可以使用悲觀鎖解決併發問題;但如果系統的併發非常大的話,悲觀鎖定會帶來非常大的效能問題,所以我們就要選擇樂觀鎖定的方法.

悲觀鎖和樂觀鎖

1.悲觀鎖,正如其名,它指的是對資料被外界 包括本系統當前的其他事務,以及來自外部系統的事務處理 修改持保守態度,因此,在整個資料處理過程中,將資料處於鎖定狀態。悲觀鎖的實現,往往依靠資料庫提供的鎖機制 也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性,否則,即使在本系統中實現了加鎖機制,也無...

悲觀鎖和樂觀鎖

前幾天有人問了我乙個問題,說如果資料庫某些操作不用事務,那麼又需要保持資料的一致性,那麼該用什麼方法替代事務。我就想到了悲觀鎖和樂觀鎖的思想,下面我解釋一下在資料庫中的悲觀鎖和樂觀鎖 1.悲觀鎖就是把資料庫的一些操作,放在事務當中,依賴資料庫的隔離級別,實現對資料修改的封鎖,這樣做資料一致性可以保持...

悲觀鎖和樂觀鎖

悲觀鎖 pessimistic lock 顧名思義,就是很悲觀,每次去拿資料的時候都認為別人會修改,所以每次在拿資料的時候都會上鎖,這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖。樂觀鎖 optim...