一、Redis事務介紹
Redis事務是一個單獨的隔離操作 ：事務中的所有命令都會序列化、按順序地執行，事務在執行的程序中,不會被其他客戶端發送來的命令請求所打斷，
Redis事務的主要作用就是串聯多個命令防止別的命令插隊，
二、Multi、Exec、discard命令
從輸入Multi 命令開始,輸入的命令都會依次進入命令佇列中,但不會執行,直到輸入Exec后, Redis會將之前的命令佇列中的命令依次執行，組隊的程序中可以通過discard來放棄組隊，
discard取消組隊如下圖：
如果在multi組隊程序中，發生提示錯誤，在執行exec提交時會發生錯如下圖：
如果在multi組隊程序中，發生了非提示錯誤，并不會立馬報錯，而是在exec提交時才會報錯，而且其他命令會正常執行，
三、事務沖突問題
當多個請求同時操作一個資料時會發生資料錯誤，為了防止這種錯誤，我們可以進行加鎖操作，
1. 樂觀鎖
悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖，傳統的關系型資料庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖，這樣的缺點是效率低
2. 悲觀鎖
樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，可以使用版本號等機制，樂觀鎖適用于多讀的應用型別，這樣可以提高吞吐量，Redis就是利用這種check-and-set機制實作事務的，
3. watch key [key]
在執行multi之前，先執行watch key1 [key2],可以監視一個(或多個) key ，如果在事務執行之前這個(或這些) key 被其他命令所改動，那么事務將被打斷，
4. unwatch
取消 WATCH 命令對所有 key 的監視，如果在執行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被執行了的話，那么就不需要再執行UNWATCH 了，
四、Redis事務三大特性
1. 單獨的隔離操作
事務中的所有命令都會序列化、按順序地執行，事務在執行的程序中，不會被其他客戶端發送來的命令請求所打斷，
2. 沒有隔離級別的概念
佇列中的命令沒有提交之前都不會實際被執行，因為事務提交前任何指令都不會被實際執行，
3. 不保證原子性
事務中如果有一條命令執行失敗，其后的命令仍然會被執行，沒有回滾，
五、持久化操作
Redis 提供了2個不同形式的持久化方式：RDB(Redis DataBase)、AOF(Append Of File)
1. RDB
（1）什么是RDB
在指定的時間間隔內將記憶體中的資料集快照寫入磁盤， 也就是行話講的Snapshot快照，它恢復時是將快照檔案直接讀到記憶體里，
（2）RDB如何進行備份
Redis會單獨創建（fork）一個子行程來進行持久化，會先將資料寫入到 一個臨時檔案中，待持久化程序都結束了，再用這個臨時檔案替換上次持久化好的檔案， 整個程序中，主行程是不進行任何IO操作的，這就確保了極高的性能 如果需要進行大規模資料的恢復，且對于資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺點是最后一次持久化后的資料可能丟失，
（3）RDB備份
先通過config get dir 查詢rdb檔案的目錄
將*.rdb的檔案拷貝到別的地方
rdb的恢復
關閉Redis
先把備份的檔案拷貝到作業目錄下 cp dump2.rdb dump.rdb
啟動Redis, 備份資料會直接加載
（4）RDB的優勢
適合大規模的資料恢復
對資料完整性和一致性要求不高更適合使用
節省磁盤空間
恢復速度快
（5）RDB的缺點
Fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮
雖然Redis在fork時使用了寫時拷貝技術,但是如果資料龐大時還是比較消耗性能，
在備份周期在一定間隔時間做一次備份，所以如果Redis意外down掉的話，就會丟失最后一次快照后的所有修改，
2. AOF
（1）什么是AOF
以日志的形式來記錄每個寫操作（增量保存），將Redis執行過的所有寫指令記錄下來(讀操作不記錄)， 只許追加檔案但不可以改寫檔案，redis啟動之扯訓讀取該檔案重新構建資料，換言之，redis 重啟的話就根據日志檔案的內容將寫指令從前到后執行一次以完成資料的恢復作業
（2）AOF的持久化程序
（1）客戶端的請求寫命令會被append追加到AOF緩沖區內；
（2）AOF緩沖區根據AOF持久化策略[always,everysec,no]將操作sync同步到磁盤的AOF檔案中；
（3）AOF檔案大小超過重寫策略或手動重寫時，會對AOF檔案rewrite重寫，壓縮AOF檔案容量；
（4）Redis服務重啟時，會重新load加載AOF檔案中的寫操作達到資料恢復的目的；
（3）AOF的優勢
備份機制更穩健，丟失資料概率更低，
可讀的日志文本，通過操作AOF穩健，可以處理誤操作，
（4）AOF的劣勢
比起RDB占用更多的磁盤空間，
恢復備份速度要慢，
每次讀寫都同步的話，有一定的性能壓力，
存在個別Bug，造成恢復不能，
3. AOF和RDB選擇
官方推薦兩個都啟用，
如果對資料不敏感，可以選單獨用RDB，
不建議單獨用 AOF，因為可能會出現Bug，
如果只是做純記憶體快取，可以都不用，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/445281.html
標籤：Java