redis事務就是乙個命令執行的佇列，將一系列預定義命令包裝成乙個整體（乙個佇列）。當執行時，一次性按照新增順序依次執行，中間不會被打斷或者干擾。
事務的基本操作：
開啟事務：multi 作用：設定事務的開啟位置，此指令執行後，後續的所有指令均加入到事務中
執行事務：exec 作用：設定事務的結束位置，同時執行事務。與multi成對出現，成對使用
注意：加入事務的命令暫時進入到任務佇列中，並沒有立即執行，只有執行exec命令才開始執行
事務定義過程中發現出了問題：
取消事務 discard 作用：終止當前事務的定義，發生在multi之後，exec之前
基於特定條件的事務執行——鎖：
業務場景：
天貓雙11熱賣過程中，對已經售罄的貨物追加**，4個業務員都有許可權進行**。**的操作可能是一系列的操作，牽扯到多個連續操作，如何保障不會重複操作？
業務分析：
多個客戶端有可能同時操作同一組資料，並且該資料一旦被操作修改後，其他客戶端將不適用於繼續操作
在操作之前鎖定要操作的資料，一旦發生變化，終止當前操作
解決方案：
對 key 新增監視鎖（必須在事務開啟之前新增監視鎖），在執行exec前如果key發生了變化，終止事務執行
watch key1 [key2……]
取消對所有 key 的監視
unwatch
基於特定條件的事務執行——分布式鎖：
業務場景：
天貓雙11熱賣過程中，對已經售罄的貨物追加**，且**完成。客戶購買熱情高漲，3秒內將所有商品購買完畢。本次**已經將庫存全部清空，如何避免最後一件商品不被多人同時購買？【超賣問題】
業務分析：
使用watch監控乙個key有沒有改變已經不能解決問題，此處要監控的是具體資料
雖然redis是單執行緒的，但是多個客戶端對同一資料同時進行操作時，如何避免不被同時修改？
解決方案：
使用 setnx 設定乙個公共鎖
setnx lock-key value
利用setnx命令的返回值特徵：執行上面的命令，如果有值（別人已經設定了）則返回設定失敗，無值則返回設定成功
對於返回設定成功的，擁有控制權，進行下一步的具體業務操作
對於返回設定失敗的，不具有控制權，排隊或等待
操作完畢通過del操作釋放鎖 del lock-key
注意：上述解決方案是一種設計概念，依賴規範保障(必須使用同一把鎖，也就是大家都使用同乙個lock-key)，具有風險性
基於特定條件的事務執行——分布式鎖改良
業務場景：
依賴分布式鎖的機制，某個使用者操作時對應客戶端宕機，且此時已經獲取到鎖。如何解決？
業務分析：
由於鎖操作由使用者控制加鎖解鎖，必定會存在加鎖後未解鎖的風險
需要解鎖操作不能僅依賴使用者控制，系統級別要給出對應的保底處理方案
解決方案：
使用 expire 為鎖key新增時間限定，到時不釋放，放棄鎖
expire lock-key second
pexpire lock-key milliseconds
由於操作通常都是微秒或毫秒級，因此該鎖定時間不宜設定過大。具體時間需要業務測試後確認。
例如：持有鎖的操作最長執行時間127ms，最短執行時間7ms。
測試百萬次最長執行時間對應命令的最大耗時，測試百萬次網路延遲平均耗時
鎖時間設定推薦：最大耗時*120%+平均網路延遲*110%
如果業務最大耗時《網路平均延遲，通常為2個數量級，取其中單個耗時較長即可
redis 事務和鎖
redis與 mysql事務的對比 在mutil後面的語句中,語句出錯可能有2種情況 redis 鎖 redis流水線 效能測試 set time limit 0 ini set memory limit 1024m redis new redis g 1 redis connect 127.0.0...
redis 事務和鎖
何為事務 redis事務就是乙個命令執行的佇列，將一些命令包裝為乙個整體，在執行時，一次性全部依次執行，中間不會被打斷。注意事項 若multi開啟事務後，後續指令存在語法錯誤，則指令佇列被銷毀。事務停止。事務的基本操作 1 multi 開啟事務 2 exec 執行事務 3 discard 取消事務，...
Redis事務 事務鎖
一旦成功所有的成功，乙個失敗，所有一些列連續動作都失敗 事務的基本操作 注意 加入事務的命令暫時到任務佇列中，並沒有立即執行，只有執行exec命令才開始執行事務定義過程中發現問題，怎麼辦？discard 事務的工作流程 事務的注意事項 手動進行事務回滾 業務場景1 業務分析 基於特定條件的事務執行 ...