樂觀鎖
開啟事務前，設定對資料的監聽（watch），exec時，如果發生資料發生過修改，作用於改資料的事務會自動取消（discard）,事務exec後，無論成敗，監聽會被移除悲觀鎖
每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖。
場景：如果專案中使用了快取且對快取設定了超時時間。當併發量比較大的時候，如果沒有鎖機制，如果有大量請求訪問過期的資料，那麼大量併發請求會穿透快取直接查詢資料庫，造成雪崩效應。
用加鎖或者佇列的方式保證來保證不會有大量的執行緒對資料庫一次性進行讀寫，從而避免失效時大量的併發請求落到底層儲存系統上，加鎖排隊只是為了減輕資料庫的壓力，並沒有提高系統吞吐量。假設在高併發下，快取重建期間key是鎖著的，這是過來1000個請求999個都在阻塞的。同樣會導致使用者等待超時，這是個治標不治本的方法！
應用場景一：
多個客戶端可能同時操作同一組資料，並且該資料一旦被操作修改後，便不適合在原基礎上繼續操作，如四個業務員對乙個物品進行入庫操作，一名業務員操作完成之後，其他的業務員將不可以再原先基礎的數量上進行入庫操作解決方案：
加鎖(樂觀鎖)
# 對key新增監視鎖，在執行exec前如果key發生了變化，終止事務執行
watch key1 [key2...]
#取消對所有key的監視
unwatch
應用場景二
超賣：
如何避免最後一件商品不被多人同時購買？避免使用者在沒有庫存的時候不能下單業務分析： 解決方案：
分布式鎖（悲觀鎖）
#使用setnx設定乙個公共鎖，這個lock-key必須相同，如果都不規範，那就亂套了，vlue隨便設定
setnx lock-key valule
大量使用者要購買一件商品，首先要做的是看看有沒有人用（是否上鎖），如果沒有拿到執行權，進行購物（資料庫數量減1操作），如果有鎖，那就排隊等待
利用setnx命令的返回值特徵，有值則返回設定失敗，無值則返回設定成功操作完畢通過del操作釋放鎖
應用於基於分布式鎖對應的場景控制
問題描述：
符合上面以上兩種情形，使用者獲得鎖之後，宕機了，如何解決?
業務分析：
解決方案：
#使用expire為key新增事件限定，到時不釋放，放棄鎖
expire lock-key second
pexpire lock-key milliseconds
由於操作通常都是微妙或毫秒級，因此改鎖定事件不宜設定過大，具體事件需要業務測試後確認
鎖 悲觀鎖和樂觀鎖
1.頁鎖，頁的粒度上進行鎖定。2.表鎖，對資料表進行鎖定，鎖定粒度很大，同時發生鎖衝突的概率也會較高，資料訪問的併發度低。不過好處在於對鎖的使用開銷小，加鎖會很快。3.行鎖，按照行的粒度對資料進行鎖定。鎖定力度小，發生鎖衝突概率低，可以實現的併發度高，但是對於鎖的開銷較大，加鎖較慢，容易出現死鎖。讀...
悲觀鎖和樂觀鎖
1.悲觀鎖，正如其名，它指的是對資料被外界 包括本系統當前的其他事務，以及來自外部系統的事務處理 修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制 也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無...
悲觀鎖和樂觀鎖
前幾天有人問了我乙個問題，說如果資料庫某些操作不用事務，那麼又需要保持資料的一致性，那麼該用什麼方法替代事務。我就想到了悲觀鎖和樂觀鎖的思想，下面我解釋一下在資料庫中的悲觀鎖和樂觀鎖 1.悲觀鎖就是把資料庫的一些操作，放在事務當中，依賴資料庫的隔離級別，實現對資料修改的封鎖，這樣做資料一致性可以保持...