redis內存回收機制及rdb和aof存儲機制aof重寫原理

redis內存回收機制：
當在redis交互式十刪除了二十G的數據，使用free -m，發現操做系統內存並無釋放，消耗掉的內存仍是從前。由於redis會經過操做系統的com機制將數據段分爲多個數據頁面，因此各個頁面也許都會你有的key存在，此時你須要使用flushdb刷新一下內存，清空各頁面存在的key，此時再使用fee -m會發現內存已釋放

rdb存儲機制
redis在持久化時會fork一個子進程出來對快照進行持久化進行處理，交進程負責處理客戶端的請求，子和父進程 共享內存裏面的代碼段和數據，子進程作數據持久化，不會修改如今的內存數據結構，它只是對數據結構遍歷讀取，而後序列化寫到磁盤中。父進程不斷持續服務客戶端請求，而後對內存數據結構進行不間斷的修改，這個時候會使用com機制來進行數據段頁面的分離，數據段是由不少操做系統的頁面組成，當父進程 對其中一個頁面的數據進行修改時，會將被共享的頁複製一份分離出來，而後對這個複製的頁面進行修入，這時子進程相應的頁面是沒有變化的，仍是進程產生那一瞬間的數據，隨着父進程修改操做的持續進行，愈來愈多的共享頁面被分離出來，內存就會持續增加，可是也不會超過原有數據內存的兩倍大小。另外。另redis實例裏冷數據佔的比例每每是比較高的，因此不多會出現全部的頁面被分離的狀況，被分離的每每只有其中一部分頁面。每一個頁面的大小隻有四KB，一個redis實例裏面通常都會有成千上萬個頁面。

aof原理
aof日誌存儲的是redis服務器的順序指令序列，aof日誌只記錄對內存進行的修改的指令記錄，redis會在收到客戶端修改指令後，進行參數校驗交，邏輯處理，若是沒問題，就當即將指令文本存儲到AOF日誌中，也就是說，先執行指令纔將日誌存盤。

aof重寫
隨着時間的推移，aof的日誌會愈來愈長，日誌會愈來愈大，須要對aof進行瘦身
redis提供了bgrewriteaof指令用於對aof日誌進行瘦身，原理就是開闢一個子進程對內存進行遍歷，轉換成一系列的redis的操做指令，序列化到一個新的aof日誌文件中，序列化完畢後再將操做期間發生的增量aof日誌追加到這個新的aof日誌文件中，追加完畢後就當即替換舊的aof，因爲新的aof文件去除了許多沒有用佔用空間的多餘東西，因此新aof文件會比舊的aof佔用空間容量要小不少