redis特性
多資料:
預設是0號資料庫，最多到15

select 0 ，當然也可以移動資料庫 move myset 1 就是將0中的myset移動到myset

redis中的事務一旦執行，後面的命令都會被執行

multi 開啟事務

exec 提交事務（只有提交事務後，設定的變數等才能生效）

discard 回滾事務

redis的持久化
redis的高效能，是因為redis把資料都存放在記憶體當中，為了保證重啟後不丟失，需要把資料從記憶體同步到硬碟上——持久化。

持久化操作，兩種方式：rdb方式、aof方式，可以單獨使用或者結合使用。
使用方法：
rdb持久化方法：預設的方式，無需配置。在指定的時間間隔寫入硬碟，指定將記憶體中的資料寫入到磁碟中的頻率
aof方式：將以日誌，記錄每一個操作，伺服器啟動後根據日誌構建資料庫，保證資料完整性。

配置可以禁用 持久化功能。
也可以同時使用兩種方式。
無持久化。可以配置為不進行持久化，redis就當一個緩衝使用。可以同時使用RDB和AOF

RDB方式
RDB
優勢:
1、儲存只有一個檔案，方便壓縮、轉移和恢復；
2、設定不同的儲存點，適合備份
3、RDB 可以最大化 Redis 的效能：父程序在儲存 RDB 檔案時唯一要做的就是 fork 出一個子程序，然後這個子程序就會處理接下來的所有儲存工作，父程序無須執行任何磁碟 I/O 操作。
4、RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快

RDB 是一個非常緊湊（compact）的檔案，它儲存了 Redis 在某個時間點上的資料集。 這種檔案非常適合用於進行備份： 比如說，你可以在最近的 24 小時內，每小時備份一次 RDB 檔案，並且在每個月的每一天，也備份一個 RDB 檔案。 這樣的話，即使遇上問題，也可以隨時將資料集還原到不同的版本。RDB 非常適用於災難恢復（disaster recovery）：它只有一個檔案，並且內容都非常緊湊，可以（在加密後）將它傳送到別的資料中心，或者亞馬遜 S3 中。RDB 可以最大化 Redis 的效能：父程序在儲存 RDB 檔案時唯一要做的就是 fork 出一個子程序，然後這個子程序就會處理接下來的所有儲存工作，父程序無須執行任何磁碟 I/O 操作。RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快

劣勢:
1、可能在伺服器故障時丟失資料
2、資料量大時，fork的子程序可能造成伺服器停止處理客戶端長達XXms~1s

如果你需要儘量避免在伺服器故障時丟失資料，那麼 RDB 不適合你。 雖然 Redis 允許你設定不同的儲存點（save point）來控制儲存 RDB 檔案的頻率， 但是， 因為RDB 檔案需要儲存整個資料集的狀態， 所以它並不是一個輕鬆的操作。 因此你可能會至少 5 分鐘才儲存一次 RDB 檔案。 在這種情況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的資料。每次儲存 RDB 的時候，Redis 都要 fork() 出一個子程序，並由子程序來進行實際的持久化工作。 在資料集比較龐大時， fork() 可能會非常耗時，造成伺服器在某某毫秒內停止處理客戶端； 如果資料集非常巨大，並且 CPU 時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒。 雖然 AOF 重寫也需要進行 fork() ，但無論 AOF 重寫的執行間隔有多長，資料的耐久性都不會有任何損失

AOF方式
優勢：
AOF 持久化會讓 Redis 變得非常耐久（much more durable），資料可靠性強
AOF 檔案是一個只進行追加操作的日誌檔案（append only log）；
AOF 檔案有序地儲存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式儲存， 因此 AOF 檔案的內容非常容易被人讀懂， 對檔案進行分析（parse）也很輕鬆。
匯出（export） AOF 檔案也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 檔案未被重寫， 那麼只要停止伺服器， 移除 AOF 檔案末尾的 FLUSHALL 命令， 並重啟 Redis ， 就可以將資料集恢復到 FLUSHALL 執行之前的狀態。

劣勢：
對於相同的資料集來說，AOF 檔案的體積通常要大於 RDB 檔案的體積。
不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。
個別命令出現bug，無法將資料集恢復成儲存時的原樣。RDB 幾乎是不可能出現這種 bug 的。

參考：https://blog.csdn.net/sinat_27406925/article/details/73382169