Redis的數據回寫機制
Redis的數據回寫機制分同步和異步兩種，
- 同步回寫即SAVE命令，主進程直接向磁盤回寫數據。在數據大的情況下會導致系統假死很長時間，所以一般不是推薦的。
- 異步回寫即BGSAVE命令，主進程fork后，復制自身並通過這個新的進程回寫磁盤，回寫結束后新進程自行關閉。由於這樣做不需要主進程阻塞，系統不會假死，一般默認會采用這個方法。方法２采用fork主進程的方式很拙劣，但似乎是唯一的方法。內存中的熱數據隨時可能修改，要在磁盤上保存某個時間的內存鏡像必須要凍結。凍結就會 導致假死。 fork一個新的進程之后等於復制了當時的一個內存鏡像，這樣主進程上就不需要凍結，只要子進程上操作就可以了。在小內存的 進程上做一個fork,不需要太多資源，但當這個進程的內存空間以Ｇ為單位時，fork就成為一件很恐怖的操作。何況在16G內存的主機上fork 14G內存的進程呢？肯定會報內存無法分配的。更可氣的是，越是改動頻繁的主機上fork也越頻繁，fork操作本身的代價恐怕也不會比假死好多少。找到原因之后，直接修改/etc/sysctl.conf內核參數vm.overcommit_memory= 1 ，sysctl -p ，Linux內核會根據參數vm.overcommit_memory參數的設置決定是否放行。
- 如果 vm.overcommit_memory = 1，直接放行
- vm.overcommit_memory = 0：則比較 此次請求分配的虛擬內存大小和系統當前空閑的物理內存加上swap，決定是否放行。
- vm.overcommit_memory= 2：則會比較進程所有已分配的虛擬內存加上此次請求分配的虛擬內存和系統當前的空閑物理內存加上swap，決定是否放行。
- AOF的完全持久化方式帶來的問題：
比如我們調用INCR test命令100次，文件中就必須保存全部的100條命令，但其實99條都是多余的。
因為要恢復數據庫的狀態其實文件中保存一條SET test 100就夠了。
為了壓縮AOF的持久化文件，Redis提供了bgrewriteaof命令。
收到此命令后Redis將使用與快照類似的方式將內存中的數據以命令的方式保存到臨時文件中，最后替換原來的文件，以此來實現控制AOF文件的增長。
由於是模擬快照的過程，因此在重寫AOF文件時並沒有讀取舊的AOF文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的AOF文件。
對應的設置參數為:
$ vim /opt/redis/etc/redis_6379.confno-appendfsync-on-rewrite yes #在日志重寫時，不進行命令追加操作，而只是將其放在緩沖區里，避免與命令的追加造成DISK IO上的沖突。 auto-aof-rewrite-percentage 100 #當前AOF文件大小是上次日志重寫得到AOF文件大小的二倍時，自動啟動新的日志重寫過程。 auto-aof-rewrite-min-size 64mb #當前AOF文件啟動新的日志重寫過程的最小值，避免剛剛啟動Reids時由於文件尺寸較小導致頻繁的重寫。
-
二、災難恢復模擬:目前，通常的設計思路是利用Replication機制來彌補aof、snapshot性能上的不足，達到了數據可持久化。
-
即Master上Snapshot和AOF都不做，來保證Master的讀寫性能，而Slave上則同時開啟Snapshot和AOF來進行持久化，保證數據的安全性
- 數據持久化的優化：
使用Replication機制，結合使用rdb和aof方式，Master主節點負責讀操作，Slave從節點負責寫數據，選擇
Replication機制的其中一種方式，將數據保存在Slava節點，然后利用Slave從節點的rdb文件和aof文件去恢復被
kill掉的Master節點。
這種集群Master節點的配置文件的主要部分：
|----------------------------------------------------------------------------------------------------------------------------------------
|#save 900 1 #禁用Snapshot
|#save 300 10
|#save 60 10000
|#appendonly no #禁用AOF
|----------------------------------------------------------------------------------------------------------------------------------------
Slave節點的配置文件的主要部分：
|----------------------------------------------------------------------------------------------------------------------------------------
|save 900 1 #啟用Snapshot
|save 300 10
|save 60 10000
|appendonly yes #啟用AOF
|appendfilename appendonly.aof #AOF文件的名稱
|# appendfsync always
|appendfsync everysec #每秒鍾強制寫入磁盤一次
|# appendfsync no
|no-appendfsync-on-rewrite yes #在日志重寫時，不進行命令追加操作
|auto-aof-rewrite-percentage 100 #自動啟動新的日志重寫過程
|auto-aof-rewrite-min-size 64mb #啟動新的日志重寫過程的最小值
|----------------------------------------------------------------------------------------------------------------------------------------
3、持久化過程：
在確認主節點Master已經失效的前提下，打包（tar）Slaver結點的rdb和aof文件；將其上傳到Master節點下的文
件夾，同時刪除Master目錄下初始化Slave的數據文件；然后解壓剛才上傳的tar包；最后再次啟動被kill的Master
節點，至此，Maste節點的數據白恢復。
4、主從配置：
集群怎樣把從節點變成主節點，當Master節點失效的時候。
5、集群的可用性
Redis集群通過分區來提供一定程度的可用性：即使集群中有一部分節點失效或者無法進行通訊， 集群也可以繼續處理
命令請求