一??redis事務
事務核心參考
①? ?基礎概念
1、場景'引入'核心：通過現象'思考原因'?
2、'事務'的概念
3、事務'四大'特性說明： redis只'具備部分'特性
重點1： '原子性'和'一致性'
重點2： '隔離性'和'持久性'
②? ?redis的事務
1、'基礎'鋪墊備注： redis提供了'簡單的事務',不支持'事務回滾'
2、redis的'事務'命令核心點：1、在一個'客戶端'操作的時候,把'所有的指令'一次性按照'順序'放在一個'隊列'中2、執行完了之后再讓'其他的客戶端'操作事務相關的命令
1、multi --> '開啟事務',標記一個'事務塊的開始'備注： 設定事務的'開啟 start'位置,此指令執行后,'后續的所有指令'均加入到'事務'中2、exec --> '執行事務'作用：設定事務的'結束 end'位置,同時執行事務,與multi '成對'出現,成對使用備注1：若在'事務隊列'中存在'命令性'錯誤,則'執行EXEC'命令時,所有命令'都不會'執行備注2：若在事務隊列中存在'語法性'錯誤,則執行EXEC命令時,其他正確命令會被執行,錯誤命令拋出異常也即：已經'執行完畢的命令'對應的數據'不會自動回滾',需要程序員'自己在代碼中'實現回滾3、discard作用： 終止'當前事務的定義',發生在'multi之后',exec之'前'場景： 你在命令入隊列的時候,發現你有些命令指令輸入錯誤,你不想執行了,這個時候,你不想提交事務了
備注：1、mysql的commit是'先執行'了,然后'又回滾'了2、而redis的'discard'是取消redis服務器'暫存隊列'的內容,'不執行'QUEUED : '隊列'
備注：1、雖然'將命令序列化后'發給redis服務器,但是redis'并沒有'執行2、而是放在一個'獨立的暫存區域[隊列中]'3、只有'客戶端'發送'EXEC'的命令,對于redis就是一個信號,redis服務器端'才會執行'.缺點：每次發送命令都會'進行一個I/O操作',在服務器進行'多個命令'打包③? ?事務特殊情況
1、'語法 synax'錯誤
說明： '報錯時',所有的命令'都不會'執行,'完全回滾'命令'語法'錯誤: 一個事務中的'多個命令'都'不會'執行備注： '語法'錯誤,redis-cli客戶端會'進行校驗'
2、'類型操作'錯誤備注： 在'類型'執行時'報錯',這時一個事務中的'多個命令','對的會執行','錯的不會'執行
說明： redis只有'在服務器端執行'才知道'是否錯誤'常見： 1、incr email 'email'不是'整數'類型2、number 不是 'list'列表類型
④? 事務小結
⑤? 事務的工作流程
一個事務'從開始到結束'通常會進過以下'三個'階段：（1）事務開始 （2）命令入隊 （3）事務執行
百度二面：談談你對Redis事務的理解
⑥? watch
說明： watch 監控key備注： redis使用watch來提供'樂觀鎖',類似 'cas（check and set）'
樂觀鎖
樂觀鎖version和時間戳外的實現方式
樂觀鎖的version和timestamp
分布式鎖和消息隊列
思考： 樂觀鎖'樂觀在哪'?
redis 鎖和分布式鎖?
1、'不開啟'watch監控時,事務中的key被修改'不影響事務'的執行2、'開啟'watch監控時,'事務中的key被修改'影響'事務的執行' --> '案例演示'
結果：1、由于在'redis-cli'中的 'key k1'被'watch'監控2、另一個redis客戶端'修改k1后',再'執行事務'修改k1,則整個事務中的所有命令'都不會'執行補充： unwatch '取消監控key'
⑦??并發競爭key
分布式鎖和消息隊列
核心點： 體會'設計'思路
