11/6筆記 補充（Redis持久化，RDB&&AOF）
11/6補充筆記
修改redis-6379.conf裡面的save10秒2個數據發生改變 (save 10 2)
修改一次數據不發生改變，修改2次數據才發生改變
繼續修改數據，發現還是一樣的規律
增刪該都發生變化，除了查以外。
save配置原理
返回結果，要對數據產生影響，數據發生了變化，或者變數達到設置要求，rdb才會發生變化。save配置要根據真實場景進行設置，否則性能可能出現問題，save配置後執行的是bgsave操作。
RDB2種啟動方式對比
save指令在讀寫的過程中是同步的，而不敢save是非同步的，save指令會阻塞客服端，bgsave讀寫的過程是非同步的，會創建子執行緒(相當於啟動了新進程)，不會造成客服端堵塞，但會造成額外消耗記憶體。
rdb特殊啟動指令
伺服器運行過程中重啟
debug reload
關閉伺服器是指定保存數據
shutdown save(不管是夠開啟，自動執行bgsave)
RDB優點與缺點
優點:
RDB是一個緊湊壓縮的二進位文件，代表Redis在某個時間點上的數據快照。非常適用於備份，全量複製等場景。比如每2小時執行bgsave備份， 並把RDB文件拷貝到遠程機器或者文件系統中（如hdfs），用於災難恢復。RDB恢複數據遠遠快於AOF的方式。
缺點:
RDB方式數據沒辦法做到實時持久化/秒級持久化,可能保存的數據不是很完整。因為bgsave每次運行都要執行fork操作創建子進程，會額外消耗性能，頻繁執行成本過高。RDB文件使用特定二進位格式保存，Redis版本更新過程中有多個格式的RDB版本，存在老版本Redis服務數據格式無法兼容新版RDB格式的問題。
AOF
使用AOF的原因:針對RDB不適合實時持久化的問題，Redis提供了AOF持久化方式來解決。
概念
AOF（append only file）持久化：以日誌的方式記錄數據產生的過程(每次寫入時命令)， 重啟時再重新執行AOF文件中的命令達到恢複數據的目的。AOF的主要作用是解決了數據持久化的實時性，目前已經是Redis持久化的主流方式
AOF寫數據三種策略(appendfsync)
always(每次),每次把寫入操作同步到AOF文件中,數據完整,性能較低.
everysec(每秒),每秒將緩衝區同步到AOF文件中,數據準確性和性能較高,一般都是使用這個指令,也是默認配置
no(系統控制),由作業系統控制每次同步到AOF中,整體不可控
實操:
配置:appendfilename配置為appendonly.aof,如果是多埠號的話,建議配置為appendonly-埠號.aof
1.進入conf目錄配置redis-6379的conf文件
2.添加以下命令,開啟持久化功能(appendonly yes|no),配置寫數據策略(appendfsync always |everysec|no)
3.先殺死原來的服務進程,再重新用配置文件啟動
4.進入data,查看文檔是否多了一個aof的文件
5.添加數據發現文件變大了
6.在使用everysec指令,重啟服務端,在修改數據之前查看文件大小
7.在寫入數據之後,查看文件大小,和cat 文件.aof日誌,發現修改數據日誌成功
AOF重寫
隨著AOF文件越來越大，需要定期對AOF文件進行重寫，達到壓縮的目的。
就是將對同一個數據的若干個條命令執行結果轉化成最終結果數據對應的指令進行記錄。
目的:AOF重寫節省了文件佔用空間，提高數據恢復效率,更小的AOF 文件可以更快地被Redis載入.
AOF重寫方式:手動和自動
手動:bgrewriteaof(後台重新寫入aof)
自動: auto-aof-rewrite-min-size size
`auto-aof-rewrite-percentage` *percentage*
修改配置文件
啟動客服端修改數據
查看文件和查看aof文檔數據
修改之後,啟動bgrewriteaof會出現以下提示
再次查看文件大小明顯變小了
當我查看aof數據過程的時候是亂碼,反正文件是被壓縮了.
AOF手動重寫 :bgrewriteaof指令工作原理
與bgsave指令相似,首先也是發送指令(控制台會回饋Background append only file rewriting started),調用fork函數生成子進程,重寫.aof文件,返回消息.
AOF自動重寫
自動重寫觸發條件設置 auto-aof-rewrite-min-size size自動重寫最小體積,默認為64MB。
auto-aof-rewrite-percentage percent代表當前AOF文件空間 和上一次重寫後AOF文件空間的比值。
aof_current_size AOF文件空間 aof_base_size上一次重寫後AOF文件空間
自動重寫觸發時機
aof_current_size>auto-aof-rewrite-min-size &&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite-percentage
在客服端輸入info,可以看到 Persistence(持久化),關於持久化的東西,
AOF重寫流程
RDB與AOF區別
RDB產生的文件緊湊壓縮比更高，佔用儲存空間小，因此讀取RDB恢復速度更快。由於每次生成RDB開銷較大，儲存速度很慢，可能會丟失數據，RDB在消耗資源是重量級的，相對於AOF啟動優先順序很低。
AOF通過追加寫命令到文件實現持久化，通過appendfsync參數可以控制實時/秒級持久化。因為需要不斷追加寫命令，所以AOF文件體積逐漸變大，需要定期執行重寫操作來降低文件體積。由於體積很大，所以佔用的儲存空間很大，與RDB相比，是相反的，佔用的儲存空間很大，存儲速度很快，恢復的速度比較慢，因為是記錄的數據的儲存過程，經過重寫之後會變小，AOF在消耗資源方面是輕量級的，在不同的場景更改策略可以提高數據的安全性。
RDB與AOF的選者
對數據的過程很敏感，而且不要求恢復速度的話，建議使用AOF，
對數據要求完整性，建議使用RDB持久化方案，切恢復速度很快。
如果能承受數分鐘以內的數據丟失，且追求恢復速度，選用RDB
如不能承受數分鐘以內的數據丟失，對業務數據非常敏感，選用AOF
或者兩者同時啟用，優先使用AOF恢複數據，降低數據丟失的量。
持久化應用場景
應用於搶購，限購類、限量發放優惠卷、激活碼等業務的數據存儲設計，應用於具有操作先後順序的數據控制，應用於最新消息展示，應用於控制黑名單設定的服務控制，應用於計數器組合排序功能對應的排名。
