一 什麼是redis事務？
一組命令的執行看作乙個集體，在這執行中間，這一組命令按順序依次執行，中間不被打斷或干擾。
乙個佇列中一次性，順序性，排他性的執行一系列命令。
二 事務的基本操作
開啟事務：multi
作用：開啟事務，此條命令執行，後續命令均加入事務中。
執行事務：exec
事務結束位置，即執行事務，與multi成對使用。
三 事務定義過程**現問題咋辦
命令：discard
終止當前事務。在multi後，exec前
四 鎖
業務場景1
天貓雙11熱賣過程中，對已經售罄的貨物追加**，4個業務員都有許可權進行**。**的操作可能是一系列的操作，牽扯到多個連續操作，如何保障不會重複操作？
業務分析
多個客戶端有可能同時操作同一組資料，並且該資料一旦被操作修改後，將不適用於繼續操作，在操作之前鎖定要操作的資料，一旦發生變化，終止當前操作
解決方案
對key加監視鎖，在exec之前，key發生變化，終止事務。
watch key1unwatch天貓雙11熱賣過程中，對已經售罄的貨物追加**，且**完成。客戶購買熱情高漲，3秒內將所有商品購買完畢。本次**已經將庫存全部清空，如何避免最後一件商品不被多人同時購買？【超賣問題】
使用watch監控乙個key有沒有改變已經不能解決問題，此處要監控的是具體資料
雖然redis是單執行緒的，但是多個客戶端對同一資料同時進行操作時，如何避免不被同時修改？
基於特定條件的事務執行——分布式鎖
解決方案
setnx設定乙個公共鎖
setnx lock_key value對於返回設定成功的，擁有控制權，進行下一步的具體業務操作
對於返回設定失敗的，不具有控制權，排隊或等待
操作完畢通過del操作釋放鎖
注意：上述解決方案是一種設計概念，依賴規範保障，具有風險性
業務場景3
依賴分布式鎖的機制，某個使用者操作時對應客戶端宕機，且此時已經獲取到鎖。如何解決？
業務分析
由於鎖操作由使用者控制加鎖解鎖，必定會存在加鎖後未解鎖的風險
需要解鎖操作不能僅依賴使用者控制，系統級別要給出對應的保底處理方案
解決方案
1 使用 expire 為鎖key新增時間限定，到時不釋放，放棄鎖
expire lock
-key
second
pexpire lock
-key milliseconds
鎖時間設定推薦：最大耗時120%+平均網路延遲110%
如果業務最大耗時《網路平均延遲，通常為2個數量級，取其中單個耗時較長即可
簡述Redis的事務
簡單理解，可以認為 redis 事務是一些列 redis 命令的集合，並且有如下兩個特點 1.事務是乙個單獨的隔離操作 事務中的所有命令都會序列化 按順序地執行。事務在執行的過程中，不會被其他客戶端傳送來的命令請求所打斷。2.事務是乙個原子操作 事務中的命令要麼全部被執行，要麼全部都不執行。一般來說...
事務 Transaction 簡述
一 定義 二 應用場景 設想網上購物的一次交易，其付款過程至少包括以下幾步資料庫操作 正常的情況下，這些操作將順利進行，最終交易成功，與交易相關的所有資料庫資訊也成功地更新。但是，如果在這一系列過程中任何乙個環節出了差錯，例如在更新商品庫存資訊時發生異常 該顧客銀行帳戶存款不足等，都將導致交易失敗。...
簡述Flink事務過程
flink kafka sink執行兩階段提交的流程圖大致如下 假設一種場景，從kafka source拉取資料，經過一次視窗聚合，最後將資料傳送到kafka sink，如下圖 jobmanager向source傳送barrier，開始進入pre commit階段，當只有內部狀態時，pre comm...