redis事務是乙個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端傳送來的命令請求所打斷,redis事務的主要作用就是串聯多個命令防止別的命令插隊
multi
用於標記事務塊的開始。redis會將後續的命令逐個放入佇列中，然後才能使用exec命令原子化地執行這個命令序列。
這個命令的執行格式如下所示：
multi
這個命令的返回值是乙個簡單的字串，總是ok。
exec
在乙個事務中執行所有先前放入佇列的命令，然後恢復正常的連線狀態。
當使用watch命令時，只有當受監控的鍵沒有被修改時，exec命令才會執行事務中的命令，這種方式利用了檢查再設定（cas）的機制。
這個命令的執行格式如下所示：
exec
這個命令的返回值是乙個陣列，其中的每個元素分別是原子化事務中的每個命令的返回值。 當使用watch命令時，如果事務執行中止，那麼exec命令就會返回乙個null值。
discard
清除所有先前在乙個事務中放入佇列的命令，然後恢復正常的連線狀態。
如果使用了watch命令，那麼discard命令就會將當前連線監控的所有鍵取消監控。
這個命令的執行格式如下所示：
discardwatch
當某個事務需要按條件執行時，就要使用這個命令將給定的鍵設定為受監控的。
這個命令的執行格式如下所示：
watch key [key ...]對於每個鍵來說，時間複雜度總是o(1)。
unwatch
清除所有先前為乙個事務監控的鍵。
如果你呼叫了exec或discard命令，那麼就不需要手動呼叫unwatch命令。
這個命令的執行格式如下所示：
unwatch時間複雜度總是o(1)。總結
從輸入multi命令開始，輸入的命令都會依次進入命令佇列中，但不會執行，至到輸入exec後，redis會將之前的命令佇列中的命令依次執行。
組隊的過程中可以通過discard來放棄組隊。
如果執行階段某個命令報出了錯誤，則只有報錯的命令不會被執行，而其他的命令都會執行，不會回滾。
單獨的隔離操作
事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端傳送來的命令請求所打斷
沒有隔離級別的概念
佇列中的命令沒有提交之前都不會實際的被執行，因為事務提交前任何指令都不會被實際執行，也就不存在「事務內的查詢要看到事務裡的更新，在事務外查詢不能看到」這個讓人萬分頭痛的問題
不保證原子性
redis同乙個事務中如果有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾
應用場景:搶購
兩個請求
乙個請求想給金額減8000
乙個請求想給金額減5000
乙個請求想給金額減1000
這樣的話即使在使用者卡里沒有金額的情況下仍舊可以進行支付。為了解決這個問題我們在redis中使用到了鎖的機制
悲觀鎖悲觀鎖(pessimistic lock), 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
樂觀鎖樂觀鎖(optimistic lock), 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，可以使用版本號等機制。樂觀鎖適用於多讀的應用型別，這樣可以提高吞吐量。redis就是利用這種check-and-set機制實現事務的。
rediss事務 -------秒殺
解決計數器和人員記錄的事務操作
超賣問題
樂觀鎖
lua指令碼
Redis事務和實現秒殺功能的實現
今天帶著學生學習了redis的事務功能，redis的事務與傳統的關係型資料庫 如mysql 有所不同，redis的事務不能回滾。redis中使用multi exec discard watch unwatch等命令來操作事務。例如 multi ok incr aaa queued incr bbb ...
Redis事務和實現秒殺功能的實現
今天帶著學生學習了redis的事務功能，redis的事務與傳統的關係型資料庫 如mysql 有所不同，redis的事務不能回滾。redis中使用multi exec discard watch unwatch等命令來操作事務。例如 multi ok incr aaa queued incr bbb ...
秒殺和限流 redis
redis是單執行緒的，所以在redis中所有命令都是原子操作。而當要多條redis命令同時執行而不被打斷時，則需要使用redis的事務了。商品放到redis上面,每一次都在redis裡面執行操作,操作之前先watch key watch的作用就是檢測這個key,如果這key的事務被修改則不會執行,...