127.0.0.1:6379> SAVE
OK
# 特色
1、執行SAVE命令過程當中，redis服務器將被阻塞，沒法處理客戶端發送的命令請求，在SAVE命令執行完畢後，服務器纔會從新開始處理客戶端發送的命令請求
2、若是RDB文件已經存在，那麼服務器將自動使用新的RDB文件代替舊的RDB文件
# 工做中定時持久化保存一個文件

127.0.0.1:6379> BGSAVE
Background saving started
# 執行過程以下
1、客戶端 發送 BGSAVE 給服務器
2、服務器立刻返回 Background saving started 給客戶端
3、服務器 fork() 子進程作這件事情
4、服務器繼續提供服務
5、子進程建立完RDB文件後再告知Redis服務器

# 配置文件相關操做
/etc/redis/redis.conf
263行: dir /var/lib/redis # 表示rdb文件存放路徑
253行: dbfilename dump.rdb  # 文件名

# 兩個命令比較
SAVE比BGSAVE快，由於須要建立子進程，消耗額外的內存

# 補充：能夠經過查看日誌文件來查看redis都作了哪些操做
# 日誌文件：配置文件中搜索 logfile
logfile /var/log/redis/redis-server.log

# 命令行示例
redis>save 300 10
  表示若是距離上一次建立RDB文件已通過去了300秒，而且服務器的全部數據庫總共已經發生了很多於10次修改，那麼自動執行BGSAVE命令
redis>save 60 10000
  表示若是距離上一次建立rdb文件已通過去60秒，而且服務器全部數據庫總共已經發生了很多於10000次修改，那麼執行bgsave命令

# redis配置文件默認
218行: save 900 1
219行: save 300 10
220行: save 60 10000
  1、只要三個條件中的任意一個被知足時，服務器就會自動執行BGSAVE
  二、每次建立RDB文件以後，服務器爲實現自動持久化而設置的時間計數器和次數計數器就會被清零，並從新開始計數，因此多個保存條件的效果不會疊加

1、存儲的是命令，而不是真實數據
2、默認不開啓
# 開啓方式（修改配置文件）
一、/etc/redis/redis.conf
  672行: appendonly yes # 把 no 改成 yes
  676行: appendfilename "appendonly.aof"
2、重啓服務
  sudo /etc/init.d/redis-server restart

# 原理
   1、每當有修改數據庫的命令被執行時，服務器就會將執行的命令寫入到AOF文件的末尾
   2、由於AOF文件裏面存儲了服務器執行過的全部數據庫修改的命令，因此給定一個AOF文件，服務器只要從新執行一遍AOF文件裏面包含的全部命令，就能夠達到還原數據庫的目的

# 優勢
  用戶能夠根據本身的須要對AOF持久化進行調整，讓Redis在遭遇意外停機時不丟失任何數據，或者只丟失一秒鐘的數據，這比RDB持久化丟失的數據要少的多

# 由於
  雖然服務器執行一個修改數據庫的命令，就會把執行的命令寫入到AOF文件，但這並不意味着AOF文件持久化不會丟失任何數據，在目前常見的操做系統中，執行系統調用write函數，將一些內容寫入到某個文件裏面時，爲了提升效率，系統一般不會直接將內容寫入硬盤裏面，而是將內容放入一個內存緩存區（buffer）裏面，等到緩衝區被填滿時纔將存儲在緩衝區裏面的內容真正寫入到硬盤裏

# 因此
  1、AOF持久化：當一條命令真正的被寫入到硬盤裏面時，這條命令纔不會由於停機而意外丟失
  2、AOF持久化在遭遇停機時丟失命令的數量，取決於命令被寫入到硬盤的時間
  三、越早將命令寫入到硬盤，發生意外停機時丟失的數據就越少，反之亦然

# 打開配置文件:/etc/redis/redis.conf，找到相關策略以下
1、701行: alwarys
   服務器每寫入一條命令，就將緩衝區裏面的命令寫入到硬盤裏面，服務器就算意外停機，也不會丟失任何已經成功執行的命令數據
二、702行: everysec（# 默認）
   服務器每一秒將緩衝區裏面的命令寫入到硬盤裏面，這種模式下，服務器即便遭遇意外停機，最多隻丟失1秒的數據
3、703行: no
   服務器不主動將命令寫入硬盤,由操做系統決定什麼時候將緩衝區裏面的命令寫入到硬盤裏面，丟失命令數量不肯定

# 運行速度比較
always：速度慢
everysec和no都很快，默認值爲everysec

爲了讓AOF文件的大小控制在合理範圍，避免胡亂增加，redis提供了AOF重寫功能，經過這個功能，服務器能夠產生一個新的AOF文件
  -- 新的AOF文件記錄的數據庫數據和起因的AOF文件記錄的數據庫數據徹底同樣
  -- 新的AOF文件會使用盡量少的命令來記錄數據庫數據，所以新的AOF文件的說起一般會小不少
  -- AOF重寫期間，服務器不會被阻塞，能夠正常處理客戶端發送的命令請求

1、客戶端向服務器發送BGREWRITEAOF命令
   127.0.0.1:6379> BGREWRITEAOF
   Background append only file rewriting started

2、修改配置文件讓服務器自動執行BGREWRITEAOF命令
  auto-aof-rewrite-percentage 100
  auto-aof-rewrite-min-size 64mb
  # 解釋
    一、只有當AOF文件的增量大於100%時才進行重寫，也就是大一倍的時候才觸發
        # 第一次重寫新增：64M
        # 第二次重寫新增：128M
        # 第三次重寫新增：256M（新增128M）

# 設置密碼
　　1、requirepass password
# 開啓遠程鏈接
　　二、bind 127.0.0.1 ::1　註釋掉
　　三、protected-mode no 　把默認的yes改成no# rdb持久化-默認配置
　　四、dir /var/lib/redis
　　5、dbfilename 'dump.rdb'
# rdb持久化-自動觸發
　　save 900 1
　　save 300 10
　　save 60 10000
# aof持久化開啓
　　appendonly yes
　　appendfilename "appendonly.aof"
# aof持久化策略
　　appendfsync alwarys　 
　　appendfsync everysec　  #默認
　　appendfsync no
# aof重寫觸發
　　auto-aof-rewrite-percentage 100　　#超過百分比觸發
　　auto-aof-rewrite-min-size 64mb　　 #超過大小