# redis-持久化-事務-鎖 [TOC] ## 一、redis持久化 ### 1.概念 Redis提供了多種不同級別的持久化方式：RDB和AOF 1. RDB持久化： 指定的時間間隔內生成數據集的時間點快照（point-in-timesnapshot）。 2. AOF持久化： 記錄服務器執行的所有寫操作命令，并在服務器啟動時，通過重新執行這些命令來還原數據集。新命令會被追加到文件的末尾。Redis還會在AOF體積過大時在后臺對AOF文件進行重寫（rewrite），減小AOF文件的大小。 2. 同時持久化： Redis還可以同時使用AOF持久化和RDB持久化。在這種情況下，當Redis重啟時，它會優先使用AOF文件來還原數據集，因為AOF文件保存的數據集通常比RDB文件所保存的數據集更完整。 ### 2.RDB的優缺點 1. RDB的優點： 1）RDB是一個非常緊湊（compact）的文件，它保存了Redis在某個時間點上的數據集。這種文件非常適合用于進行備份。 2）RDB非常適用于災難恢復（disasterrecovery）：它只有一個文件，并且內容都非常緊湊，可以（在加密后）將它傳送到別的數據中。 3）RDB可以最大化Redis的性能：父進程在保存RDB文件時唯一要做的就是fork出一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無須執行任何磁盤I/O操作。 4）RDB在恢復大數據集時的速度比AOF的恢復速度要快。 2. DB的缺點 1）由于每次保存都會有時間間隔，所以如果恢復數據可能丟失最近未保存的數據 2）每次保存RDB的時候，Redis都要fork()出一個子進程，并由子進程來進行持久化工作。在數據集比較龐大時，fork()可能會非常耗時和消耗CPU資源。 ### 3.AOF的優缺點 1. AOF的優點 1）使用AOF持久化會讓Redis變得非常耐久：AOF的默認策略為每秒鐘fsync一次，在這種配置下，Redis仍然可以保持良好的性能，并且就算發生故障停機，也最多只會丟失一秒鐘的數據。 2）AOF文件是一個只進行追加操作的日志文件（appendonlylog），因此對AOF文件的寫入不需要進行seek，即使日志因為某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等），redis-check-aof工具也可以輕易地修復這種問題。 3）Redis可以在AOF文件體積變得過大時，自動地在后臺對AOF進行重寫：重寫后的新AOF文件包含了恢復當前數據集所需的最小命令集合。整個重寫操作是絕對安全的，用臨時文件的方式，成功后才覆蓋。 4）AOF文件有序地保存了對數據庫執行的所有寫入操作，這些寫入操作以Redis協議的格式保存，因此AOF文件的內容非常容易被人讀懂，對文件進行分析（parse）也很輕松。 5）導出（export）AOF文件也非常簡單：舉個例子，如果你不小心執行了FLUSHALL命令，但只要AOF文件未被重寫，那么只要停止服務器，移除AOF文件末尾的FLUSHALL命令，并重啟Redis，就可以將數據集恢復到FLUSHALL執行之前的狀態。 2. AOF的缺點 1）對于相同的數據集來說，AOF文件的體積通常要大于RDB文件的體積。 2）AOF文件恢復時間比RDB長 2）根據所使用的fsync策略，AOF的速度可能會慢于RDB。 ### 4.總結 1. redis 持久化方式有哪些？有什么區別？ rdb：基于快照的持久化，速度更快，一般用作備份，主從復制也是依賴于rdb持久化功能 aof：以追加的方式記錄redis操作日志的文件。可以最大程度的保證redis數據安全，類似于mysql的binlog 2. RDB和AOF怎么選 一般來說，如果想達到足以媲美關系型數據庫的數據安全性，應該同時使用兩種持久化功能。 如果你非常關心你的數據，但仍然可以承受數分鐘以內的數據丟失，那么你可以只使用RDB持久化。反之則使用AOF 可以采用mysql主從復制的思路，在主庫上關閉持久化，用從庫來進行持久化操作 ## 二、持久化配置 ### 1.RDB持久化 1) 基礎配置 ```sh save 900 1 save 300 10 save 60 10000 ``` 配置分別表示：當達到以下定義的配置時間時，就將內存數據持久化到磁盤 900秒（15分鐘）內有1個更改 300秒（5分鐘）內有10個更改 60秒內有10000個更改 2) 高級配置 ```sh stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir ./xxx ``` 配置分別表示: 后臺備份進程出錯時,主進程停不停止寫入? 主進程不停止容易造成數據不一致 導出的rdb文件是否壓縮 如果rdb的大小很大的話建議這么做 導入rbd恢復時數據時,要不要檢驗rdb的完整性 驗證版本是不是一致 導出來的rdb文件名 rdb的放置路徑 ### 2.AOF持久化 1) 基礎配置 ```sh appendonly yes/no appendfsync always| everysec| no ``` 配置分別表示： 是否打開aof日志功能 什么時候同步aof,[每1個命令|每秒|交給系統自動]寫入到aof 2) 高級配置 ```sh no-appendfsync-on-rewrite yes/no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb ``` 配置分別表示： 正在導出rdb快照的過程中,要不要停止同步aof aof文件大小比起上次重寫時的大小,增長率100%時重寫,缺點:業務開始的時候，會重復重寫多次。 aof文件,至少超過64M時,重寫 ## 三、RDB切換AOF \在 Redis 2.2 或以上版本，可以在不重啟的情況下，從 RDB 切換到 AOF,最好先手動備份dump.rdb文件,然后執行以下命令。 ```sh redis-cli> CONFIG SET appendonly yes redis-cli> CONFIG SET save "" ``` 修改后可以需要驗證數據庫的鍵的數量沒有改變,寫命令會被正確地追加到 AOF 文件的末尾 ## 四、事務和鎖 ### 1.redis事務 redis中的事務跟關系型數據庫中的事務是一個相似的概念，不同之處是關系型數據庫每條語句都執行了,只是執行結果再未落盤,而redis中的事務是將多個操作命令記錄下來,等提交時一起執行。 redis中開啟一個事務是使用multi，exec提交事務，discard取消隊列命令（非回滾操作）。 1) 事務命令 * DISCARD 取消事務，放棄執行事務塊內的所有命令。 * EXEC 執行所有事務塊內的命令。 * MULTI 標記一個事務塊的開始。 * UNWATCH 取消 WATCH 命令對所有 key 的監視。 * WATCH key [key ...] 監視一個(或多個) key ，如果在事務執行之前這個(或這些) key 被其他命令所改動，那么事務將被打斷。 2) 命令舉例 * 文字說明 ```sh multi command1 command2 command3 command4 ``` 4條語句作為一個組，并沒有真正執行，而是被放入同一隊列中。如果，這是執行discard，會直接丟棄隊列中所有的命令，而不是做回滾。 ```sh exec ``` 當執行exec時，對列中所有操作，要么全成功要么全失敗 * 實際操作 ```sh root@xxx ~]# 127.0.0.1:6379> set a b OK root@xxx ~]# 127.0.0.1:6379> MULTI OK root@xxx ~]# 127.0.0.1:6379> set a b QUEUED root@xxx ~]# 127.0.0.1:6379> set c d QUEUED root@xxx ~]# 127.0.0.1:6379> exec 1) OK 2) OK ``` 可以看到,執行了exec命令后,前兩條命令才一起執行 ### 2.redis鎖[樂觀鎖] redis支持樂觀鎖,也就是說,在最后提交時,才確定數據導致能不能執行 以買票來舉例如下: 我正在買票,在我下單時,發現還有一張票,我現在下單[開始事務],redis并不把這個票給我鎖起來,而是等我需要付款[提交事務],才去再次確定是否還有票,如果有我就可以用,如果沒有就提交失敗