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恢複資料，降低資料丢失的量。
持久化應用場景
應用于搶購，限購類、限量發放優惠卷、激活碼等業務的資料存儲設計，應用于具有操作先後順序的資料控制，應用于最新消息展示，應用于控制黑名單設定的服務控制，應用于計數器組合排序功能對應的排名。