石頭自清潔掃拖機器人G10S評測：多年黑科技集大成之作 懶人終極福音
科技圈經常能看到一個詞叫“縫合怪”，用來形容那些把好多功能或者外觀結合在一起的產品，通常這樣的詞是貶義詞，但如果真的是產品縫合的好、縫合的實用的話，那它就成了中性詞，今
在MySQL中，悲觀鎖依賴數據庫提供的鎖機制來實現。在InnoDB引擎中，使用悲觀鎖需要先關閉MySQL數據庫的自動提交屬性，然后通過select ... for update來進行加鎖。
在數據庫中，悲觀鎖的流程如下：
? 在對記錄進行修改前，先嘗試為該記錄加上排他鎖（exclusive lock）。
? 如果加鎖失敗，說明該記錄正在被修改，此時當前查詢可能需要等待或拋出異常，具體響應方式由開發者根據實際需求決定。
? 如果成功加鎖，則可以對記錄進行修改，事務完成后鎖將被釋放。
? 其間若有其他操作試圖對該記錄進行修改或加排他鎖，則會等待當前鎖的釋放或直接拋出異常。
我們以電商平臺下單過程中扣減庫存的需求為例，說明如何使用悲觀鎖：
-- 0.開始事務begin; -- 1.查詢出商品信息SELECT stock FROM products WHERE product_id = 12345 FOR UPDATE;-- 2.修改商品stock為2update products set stock=2 where product_id = 12345;-- 3.提交事務commit;在對id=1的記錄進行修改前，先通過FOR UPDATE的方式加鎖，然后再進行修改。這就是典型的悲觀鎖策略。
如果上述修改庫存的代碼發生并發，同一時間只有一個線程可以開啟事務并獲得id=1的鎖，其他事務必須等本次事務提交之后才能執行。這樣，我們可以保證當前的數據不會被其他事務修改。
上面提到，使用SELECT ... FOR UPDATE會將數據鎖住，不過我們需要注意一些鎖的級別。MySQL InnoDB默認使用行級鎖。行級鎖都是基于索引的，如果一條SQL語句未使用索引，優化器在選擇時，若發現鎖表可能性能更好，有可能會直接鎖表。
上面這個點之前也有在文章提到過：
日活3kw的實際庫存業務場景中的超賣到底怎么解決的
感興趣的可以參考閱讀一下，希望對你有所幫助
MySQL中的樂觀鎖主要通過CAS（Compare and Swap）的機制來實現，通常使用版本號（version）來實現。
CAS是一種樂觀鎖技術，當多個線程嘗試使用CAS同時更新同一個變量時，只有其中一個線程能成功更新變量的值，而其他線程都失敗。失敗的線程并不會被掛起，而是被告知在此次競爭中失敗，并可以再次嘗試。
以扣減庫存為例，通過樂觀鎖可以實現如下：
-- 查詢出商品信息，stock = 3select stock from products product_id id= 1-- 根據商品信息生成訂單-- 修改商品stock為2update products set stock=2 where id=1 and stock = 3;以上，在更新之前，先查詢庫存表中當前的庫存數（stock），然后在執行更新時，將庫存數作為修改條件。提交更新時，對比數據庫表記錄的當前庫存數與第一次查詢得到的庫存數，若兩者相等，則執行更新；否則，視為數據已過期。
在對數據庫中的數據進行修改時，為了避免同時被其他人修改，最好的方法是直接對該數據進行加鎖以防止并發。這種在修改數據之前先鎖定再修改的方式被稱為悲觀并發控制（又稱“悲觀鎖”，Pessimistic Concurrency Control，縮寫為“PCC”）。
悲觀鎖之所以被稱為悲觀，是因為這是一種對數據的修改抱有悲觀態度的并發控制方式。一般來說，我們認為數據被并發修改的概率較大，因此在修改之前先加鎖。
悲觀并發控制實際上是一種保守的策略，即“先取鎖再訪問”，它為數據處理的安全性提供了保證。
圖片
在效率方面，處理加鎖機制會導致數據庫產生額外的開銷，增加了產生死鎖的風險。此外，悲觀鎖還可能降低并行性，因為如果一個事務鎖定了某行數據，其他事務就必須等待該事務完成才能處理該行數據。
樂觀鎖（Optimistic Locking）是相對悲觀鎖而言的。樂觀鎖假設數據在一般情況下不會發生沖突，因此在數據提交更新時才會實際檢查數據是否沖突。如果發現沖突，則會向用戶返回錯誤信息，讓用戶決定如何處理。
與悲觀鎖相比，樂觀鎖在處理數據庫時并不會使用數據庫提供的鎖機制。一般來說，樂觀鎖的實現方式是通過記錄數據的版本信息。
圖片
樂觀并發控制相信事務之間的數據競爭（data race）的概率較小，因此盡可能直接進行操作，直到提交時才對數據進行檢查和鎖定。這樣做不會產生任何鎖或死鎖。
在樂觀鎖與悲觀鎖的選擇上面，主要看下兩者的區別以及適用場景就可以了。
1. 樂觀鎖并未真正加鎖，效率高。適用于讀操作頻繁，寫操作相對較少的場景。一旦鎖的粒度掌握不好，更新失敗的概率就會比較高，容易發生業務失敗。
2. 悲觀鎖依賴數據庫鎖，效率低。更新失敗的概率比較低。適用于寫操作較為頻繁，且并發寫入的概率較高的場景。
根據以上區別和場景特點，可以針對具體業務需求選擇合適的并發控制策略。當然最多的場景其實當屬于高并發場景如何選擇。
本文鏈接：http://m.www897cc.com/showinfo-26-88933-0.html聊聊樂觀鎖與悲觀鎖
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Spring注入還可以這樣玩！漲知識了
下一篇： 誰說PHP不能異步和并行運行？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號