Redis數據結構以及RDB、AOF原理介紹

1. redis (核心數據結構和應用場景,AOF)

在我們安裝了redis之後，所有的配置都是在redis.conf文件中，裏面保存了RDB和AOF兩種持久化機制的各種配置

數據結構

字符串(string)： 二進制安全的，最大存儲512M數據

redis 127.0.0.1:6379> SET runoob "菜鳥教程"
OK
redis 127.0.0.1:6379> GET runoob
"菜鳥教程"

列表(list)： 列表是簡單的字符串列表，按照插入順序排序

redis 127.0.0.1:6379> lpush runoob redis
(integer) 1
redis 127.0.0.1:6379> lpush runoob mongodb
(integer) 2
redis 127.0.0.1:6379> lpush runoob rabitmq
(integer) 3
redis 127.0.0.1:6379> lrange runoob 0 10
1) "rabitmq"
2) "mongodb"
3) "redis"
redis 127.0.0.1:6379>

哈希(hash)： hash 是一個 string 類型的 field 和 value 的映射表，hash 特別適合用於存儲對象

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> HMSET runoob field1 "Hello" field2 "World"
"OK"
redis 127.0.0.1:6379> HGET runoob field1
"Hello"
redis 127.0.0.1:6379> HGET runoob field2
"World"

集合(set)： Redis 的 Set 是 string 類型的無序集合，數據具有唯一性，忽略第二次sadd

redis 127.0.0.1:6379> sadd runoob redis
(integer) 1
redis 127.0.0.1:6379> sadd runoob mongodb
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 0
redis 127.0.0.1:6379> smembers runoob
1) "redis"
2) "rabitmq"
3) "mongodb"

有序集合(zset)： zset 和 set 一樣也是string類型元素的集合,且不允許重複的成員，不同的是每個元素都會關聯一個double類型的分數。redis正是通過分數來爲集合中的成員進行從小到大的排序，zset的成員是唯一的,但分數(score)卻可以重複。

redis 127.0.0.1:6379> zadd runoob 0 redis
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 mongodb
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 0
redis 127.0.0.1:6379> > ZRANGEBYSCORE runoob 0 1000
1) "mongodb"
2) "rabitmq"
3) "redis"

2. Redis中的兩種持久化機制：RDB(Redis DataBase)和AOF(Append Only File)

數據保存的五個過程：
（1）客戶端向服務端發送寫操作(數據在客戶端的內存中)。
（2）數據庫服務端接收到寫請求的數據(數據在服務端的內存中)。
（3）服務端調用write這個系統調用，將數據往磁盤上寫(數據在系統內存的緩衝區中)。
（4）操作系統將緩衝區中的數據轉移到磁盤控制器上(數據在磁盤緩存中)。
（5）磁盤控制器將數據寫到磁盤的物理介質中(數據真正落到磁盤上)。
 
可能產生的問題：
（1）Redis數據庫發生故障，只要在上面的第三步執行完畢，那麼就可以持久化保存，剩下的兩步由操作系統替我們完成。
（2）操作系統發生故障，必須上面5步都完成纔可以。
此處只考慮第一種，因爲第二種需要一定的操作系統層面的恢復機制

RDB(Redis DataBase)機制

概念： 將Redis數據在指定的時間間隔內，以快照的形式保存到磁盤上，生成dump.rdb。
觸發機制：
（1）save觸發方式
  手動執行save命令觸發。此命令會阻塞Redis服務器，直到命令執行結束

 
（2）bgsave觸發
  手動執行bgsave命令觸發，Redis會在後臺異步進行快照操作，快照同時還可以響應客戶端請求。具體操作是Redis進程執行fork操作創建子進程，RDB持久化過程由子進程負責，完成後自動結束。阻塞只發生在fork階段，一般時間很短。

（3）自動化觸發
  redis.conf文件中配置保存機制，

eg：
save 900 1：表示900 秒內如果至少有 1 個 key 的值變化，則保存
save 300 10：表示300 秒內如果至少有 10 個 key 的值變化，則保存
save 60 10000：表示60 秒內如果至少有 10000 個 key 的值變化，則保存

save和bgsave的區別

 
RDB的優勢和劣勢
優勢
（1）RDB文件緊湊，全量備份，非常適合用於進行備份和災難恢復。
（2）生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作。
（3）RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。

劣勢
RDB快照是一次全量備份，存儲的是內存數據的二進制序列化形式，存儲上非常緊湊。當進行快照持久化時，會開啓一個子進程專門負責快照持久化，子進程會擁有父進程的內存數據，父進程修改內存子進程不會反應出來，所以在快照持久化期間修改的數據不會被保存，可能丟失數據。

AOF(Append Only File)機制

概念： Redis會將所有的寫操作通過write函數追加到aof文件中，類似於日誌記錄。

AOF產生的問題 ：持久化生成的文件會隨着時間的推移越來越大。
解決方式
  Redis提供了一個 bgrewriteaof 命
   命令作用：將Redis數據保存到臨時文件，並fork除一個子進程，將aof文件重寫，重寫的數據來源：內存中的數據庫內容
 
AOF的三種觸發機制
（1）每修改同步always：同步持久化 每次發生數據變更會被立即記錄到磁盤 性能較差但數據完整性比較好
（2）每秒同步everysec：異步操作，每秒記錄 如果一秒內宕機，有數據丟失
（3）不同no：從不同步

三者的比較

AOF的優勢和劣勢
優勢
  （1）AOF可以更好的保護數據不丟失，一般AOF會每隔1秒，通過一個後臺線程執行一次fsync操作，最多丟失1秒鐘的數據。
  （2）AOF日誌文件沒有任何磁盤尋址的開銷，寫入性能非常高，文件不容易破損。
  （3）AOF日誌文件即使過大的時候，出現後臺重寫操作，也不會影響客戶端的讀寫。
  （4）AOF日誌文件的命令通過非常可讀的方式進行記錄，這個特性非常適合做災難性的誤刪除的緊急恢復。比如某人不小心用flushall命令清空了所有數據，只要這個時候後臺rewrite還沒有發生，那麼就可以立即拷貝AOF文件，將最後一條flushall命令給刪了，然後再將該AOF文件放回去，就可以通過恢復機制，自動恢復所有數據。

劣勢
  （1）對於同一份數據來說，AOF日誌文件通常比RDB數據快照文件更大
  （2）AOF開啓後，支持的寫QPS會比RDB支持的寫QPS低，因爲AOF一般會配置成每秒fsync一次日誌文件，當然，每秒一次fsync，性能也還是很高的。
  （3）以前AOF發生過bug，就是通過AOF記錄的日誌，進行數據恢復的時候，沒有恢復一模一樣的數據出來。

RDB和AOF到底該如何選擇

一般結合使用

內容參考：
https://baijiahao.baidu.com/s?id=1654694618189745916&wfr=spider&for=pc
https://www.runoob.com/redis/redis-tutorial.html
https://www.cnblogs.com/ysocean/p/9114268.html