redis 事務的本質: 一組命令的集合 乙個事務中的所有命令都會被序列化, 在事務執行過程中, 會按照順序執行
一次性 順序性 排他性 執行一系列的命令
----- 佇列set set
set 執行-----
redis的事務:
127.0.0.1:6379> multi # 開啟事務
ok# 命令入隊
127.0.0.1:6379>
set k1 v1
queued
127.0.0.1:6379>
set k2 v2
queued
127.0.0.1:6379> get k2
queued
127.0.0.1:6379>
set k3 v3
queued
# 執行事務
127.0.0.1:6379>
exec
1) ok
2) ok
3)"v2"
4) ok
127.0.0.1:6379>
127.0.0.1:6379> multi # 開啟事務
ok127.0.0.1:6379>
set k4 v4
queued
127.0.0.1:6379> discard # 取消事務
ok127.0.0.1:6379> get k4 # 事務佇列中的命令都不會執行
(nil)
(**有錯誤 命令有錯誤)
事務中的所有命令都不會被執行
127.0.0.1:6379> multi
ok127.0.0.1:6379>
set k1 v1
queued
127.0.0.1:6379>
set k2 v2
queued
127.0.0.1:6379>
set k3 v3
queued
127.0.0.1:6379> getset k3 # 錯誤的命令
(error) err wrong number of arguments for
'getset'
command
127.0.0.1:6379>
set k4 v4
queued
127.0.0.1:6379>
set k5 v5
queued
127.0.0.1:6379>
exec
# 執行的時候報錯
(error) execabort transaction discarded because of previous errors.
127.0.0.1:6379> get k5 # 所有的命令都不會被執行
(nil)
127.0.0.1:6379>
如果事務佇列中存在語法性錯誤, 那麼執行命令的時候, 其他命令是可以正常執行的, 錯誤命令丟擲異常
127.0.0.1:6379>
set k1 "v1"
ok127.0.0.1:6379> multi
ok127.0.0.1:6379> incr k1 # 會在執行的時候失敗
queued
127.0.0.1:6379>
set k2 v2
queued
127.0.0.1:6379>
set k3 v3
queued
127.0.0.1:6379> get k3
queued
127.0.0.1:6379>
exec
# 雖然第一條命令報錯了, 但是依舊正常執行成功了
1)(error) err value is not an integer or out of range
2) ok
3) ok
4)"v3"
127.0.0.1:6379>
悲觀鎖
樂觀鎖
正常執行成功
127.0.0.1:6379>
set money 100
ok127.0.0.1:6379>
set out 0
ok127.0.0.1:6379>
watch money # 監視money物件
ok127.0.0.1:6379> multi # 事務正常結束, 資料期間沒有發生變動, 這個時候就正常執行成功
ok127.0.0.1:6379> decrby money 20
queued
127.0.0.1:6379> incrby out 20
queued
127.0.0.1:6379>
exec
1)(integer) 80
2)(integer) 20
127.0.0.1:6379>
測試多執行緒修改值, 監視失敗, 使用watch可以當作redis樂觀鎖操作
執行緒一
127.0.0.1:6379>
watch money # 監視money
ok127.0.0.1:6379> multi
ok127.0.0.1:6379> decrby money 10
queued
127.0.0.1:6379> incrby out 10
queued
127.0.0.1:6379>
exec
# 執行事務之前在, 另外乙個執行緒, 修改了我們的值, 就會導致事務執行失敗.
(nil)
127.0.0.1:6379>
執行緒二
127.0.0.1:6379> get money
"80"
127.0.0.1:6379>
set money 1000
ok127.0.0.1:6379>
解決方案
127.0.0.1:6379> unwatch # 如果發現事務執行失敗, 就先解鎖
ok127.0.0.1:6379>
watch money # 獲取新的值, 再次監視, select version
ok127.0.0.1:6379> multi
ok127.0.0.1:6379> decrby money 1
queued
127.0.0.1:6379> incrby money 1
queued
127.0.0.1:6379>
exec
# 比對監視的值是否發生變化, 如果沒有變化, 執行成功, 如果執行失敗, 那麼就繼續 先解鎖 -》 獲取新值再次監視......
1)(integer) 999
2)(integer) 1000
127.0.0.1:6379>
redis狀態與效能監控
1 redis benchmark redis基準資訊,redis伺服器效能檢測 redis benchmark h localhost p 6379 c 100 n 100000 100個併發連線,100000個請求,檢測host為localhost 埠為6379的redis伺服器效能 2 red...
Redis 鎖機制與監控
redis沒有原子性,所以當前事務在操作時,其他事務可以修改,造成錯誤 redis還沒有隔離性 悲觀鎖 樂觀鎖 模擬轉賬業務 set money 100 set out 0 watch money 監控 money muti decrby money 20 incrby out 20 如果在事務提交...
Redis事務與MySQL事務的區別
1.想著 在springboot事務中,第一步insert mysql 第二步 更新到redis中 transactional rollbackfor public void addchannel meschannelvo meschannelvo 3.測試事務回滾 int i null int i...