持久化和叢集
redis持久化機制
提供兩種持久化策略
RDB
RDB的持久化策略：按照規則將記憶體的資料同步到磁碟
snapshot：快照
reids在指定的情況下會觸發快照
1.自己配置的快照規則
save
只要滿足下面任意一個條件，都會執行快照
save 900 1 當在900秒內被更改的key的數量大於1的時候，就執行快照
save 300 10
save 60 10000
2.save或者bgsave
save：執行記憶體的資料同步到磁碟的操作，這個操作會阻塞客戶端的請求
bgsave：在後臺非同步執行快照操作，這個操作不會阻塞客戶端的請求
3.執行flushall的時候
清除記憶體的所有資料，只要快照的規則不為空，也就是第一個規則存在，那麼redis
4.執行復制的時候
快照的實現原理
redis會使用fork函式複製一份當前程序的副本（子程序），fork程序負責把記憶體的資料同步到磁碟的臨時檔案，父程序繼續處理客戶端請求
redis的優缺點
1.可能會存在資料丟失的請求
2.可以最大化redis的效能（優點）
實踐
修改redis.conf中的appendonly yes ;重啟後執行對資料的變更命令，會在bin目錄下生成對應的aof檔案。
auto-aof-rewrite-percentage 100 表示當前aof 檔案大小超過上一次aof檔案大小的百分之多少的時候會進行重寫。如果執行沒有重寫過，以啟動時aof檔案大小為準。
auto-aof-rewrite-min-size 64mb 限制允許重寫最小aof檔案大小，也就是檔案大小小於64mb的時候，不需要進行優化
同步磁碟資料
redi每次更改資料的時候，aof機制都會將命令記錄到aof檔案，但是實際上由於作業系統的快取機制，資料並沒有實時寫入到硬碟，而是進入硬碟快取，再通過硬碟快取區重新整理儲存到檔案。
#appendfsync always 每次執行寫入都會進行同步，這個是最安全但是效率比較低的方式
appendfsync everysec 每一秒執行
#appendfsync no 不主動進行同步操作，由作業系統去執行，這個是最快但不安全的方式
aof檔案損壞以後如何修復
通過 redis-check-aof --fix
AOF
AOF的持久化策略：每次執行命令後，把命令本身記錄下來
AOF會把redis執行的每一條命令追加到磁碟檔案中
需要注意的是：即使已經在redis.conf檔案中把appendonly 從no改為了yes,把伺服器重啟了的情況也沒有appendonly.aof檔案時，必須要執行
redis-cli config set appendonly yes
redis-cli config set save “”
這兩個命令後才會在安裝目錄下出現appendonly.aof檔案
兩種持久化策略可以同時使用，也可以使用其中一種。如果同時使用的話，那麼redis重啟時，會優先使用AOF檔案來還原資料
對資料安全性要求較高用AOF，執行丟失用rdb。
叢集
複製（master、slave）
配置過程
修改slave的redis.conf檔案，增加 slaveof masterip masterport
slaveof 192.168.253.101 6379
實現原理
- slave連線到master上以後，會向master傳送一個SYNC的命令
- master收到SYNC的時候，會在兩件事
a)執行bgsave（rdb的快照檔案）
b)master會把新收到的修改命令存入到緩衝區
哨兵機制
叢集（redis3.0以後）
第三方提供的叢集解決方案
快取的擊穿