Redis淘汰機制
Redis內存淘汰
指的是用戶存儲的一些鍵被可以被Redis主動地從實例中刪除，從而產生讀miss的情況
那麼Redis爲什麼要有這種功能？這就是我們需要探究的設計初衷。
Redis最常見的兩種應用場景爲緩存和持久存儲
首先要明確的一個問題是內存淘汰策略更適合於那種場景？是持久存儲還是緩存？
內存的淘汰機制的初衷是爲了更好地使用內存，
用一定的緩存miss來換取內存的使用效率。
作爲Redis用戶，我如何使用Redis提供的這個特性呢？看看下面配置
maxmemory
525行
我們可以通過配置redis.conf中的maxmemory這個值來開啓內存淘汰功能，
至於這個值有什麼意義，我們可以通過了解內存淘汰的過程來理解它的意義：
客戶端發起了需要申請更多內存的命令（如set）。
Redis檢查內存使用情況，如果已使用的內存大於maxmemory
則開始根據用戶配置的不同淘汰策略來淘汰內存（key），從而換取一定的內存。如果上面都沒問題，則這個命令執行成功。
maxmemory爲0的時候表示我們對Redis的內存使用沒有限制。
Redis提供了下面幾種淘汰策略供用戶選擇，其中默認的策略爲noeviction策略：
· noeviction：當內存使用達到閾值的時候，所有引起申請內存的命令會報錯。
· allkeys-lru：在主鍵空間中，優先移除最近未使用的key。
· volatile-lru：在設置了過期時間的鍵空間中，優先移除最近未使用的key。
· allkeys-random：在主鍵空間中，隨機移除某個key。
· volatile-random：在設置了過期時間的鍵空間中，隨機移除某個key。
· volatile-ttl：在設置了過期時間的鍵空間中，具有更早過期時間的key優先移除。
這裏補充一下主鍵空間和設置了過期時間的鍵空間，舉個例子，
假設我們有一批鍵存儲在Redis中，則有那麼一個哈希表用於存儲這批鍵及其值，
如果這批鍵中有一部分設置了過期時間，那麼這批鍵還會被存儲到另外一個哈希表中，
這個哈希表中的值對應的是鍵被設置的過期時間。
設置了過期時間的鍵空間爲主鍵空間的子集。
我們瞭解了Redis大概提供了這麼幾種淘汰策略，那麼如何選擇呢？淘汰策略的選擇可以通過下面的配置指定：
maxmemory-policy noeviction
但是這個值填什麼呢？爲解決這個問題，我們需要了解我們的應用請求對於Redis中存儲的數據集的訪問方式以及我們的訴求是什麼。
同時Redis也支持Runtime修改淘汰策略，這使得我們不需要重啓Redis實例而實時的調整內存淘汰策略。
下面看看幾種策略的適用場景：
· allkeys-lru：如果我們的應用對緩存的訪問符合冪律分佈（也就是存在相對熱點數據），或者我們不太清楚我們應用的緩存訪問分佈狀況，我們可以選擇allkeys-lru策略。
· allkeys-random：如果我們的應用對於緩存key的訪問概率相等，則可以使用這個策略。
· volatile-ttl：這種策略使得我們可以向Redis提示哪些key更適合被eviction。
另外，volatile-lru策略和volatile-random策略
適合我們將一個Redis實例既應用於緩存和又應用於持久化存儲的時候
然而我們也可以通過使用兩個Redis實例來達到相同的效果，值得一提的是將key設置過期時間實際上會消耗更多的內存，因此我們建議使用allkeys-lru策略從而更有效率的使用內存。
Redis的存儲機制有兩種AOF Snapshot
無論是那種機制,Redis都是將數據存儲在內存中。
Snapshot工作原理: 是將數據先存儲在內存，然後當數據累計達到某些設定的伐值的時候，就會觸發一次DUMP操作，將變化的數據一次性寫入數據文件（RDB文件）。
AOF 工作原理: 是將數據也是先存在內存，但是在存儲的時候會使用調用fsync來完成對本次寫操作的日誌記錄，這個日誌揭露文件其實是一個基於Redis網絡交互協議的文本文件。AOF調用fsync也不是說全部都是無阻塞的，在某些系統上可能出現fsync阻塞進程的情況，對於這種情況可以通過配置修改，但默認情況不要修改。AOF最關鍵的配置就是關於調用fsync追加日誌文件的平率，有兩種預設頻率，。兩個配置各有所長後面分析。由於是採用日誌追加的方式來持久話數據，所以引出了第二個日誌的概念：rewrite. 後面介紹它的由來。
存儲模式性能和安全比較：
1.性能：Snapshot方式的性能是要明顯高於AOF方式的，原因有兩點：
採用2進制方式存儲數據，數據文件比較小，加載快速.
存儲的時候是按照配置中的save策略來存儲，每次都是聚合很多數據批量存儲，寫入的效率很好，而AOF則一般都是工作在實時存儲或者準實時模式下。相對來說存儲的頻率高，效率卻偏低。
2.數據安全：AOF數據安全性高於Snapshot存儲，原因：
Snapshot存儲是基於累計批量的思想，
也就是說在允許的情況下，累計的數據越多那麼寫入效率也就越高，
但數據的累計是靠時間的積累完成的，
那麼如果在長時間數據不寫入RDB，但Redis又遇到了崩潰，那麼沒有寫入的數據就無法恢復了
但是AOF方式偏偏相反，根據AOF配置的存儲頻率的策略可以做到最少的數據丟失和較高的數據恢復能力。
說完了性能和安全，這裏不得不提的就是在Redis中的Rewrite的功能，
AOF的存儲是按照記錄日誌的方式去工作的，那麼成千上萬的數據插入必然導致日誌文件的擴大，
Redis這個時候會根據配置合理觸發Rewrite操作，
所謂Rewrite就是將日誌文件中的所有數據都重新寫到另外一個新的日誌文件中，
但是不同的是，對於老日誌文件中對於Key的多次操作，
只保留最終的值的那次操作記錄到日誌文件中，從而縮小日誌文件的大小。
這裏有兩個配置需要注意：
auto-aof-rewrite-percentage 100 （當前寫入日誌文件的大小佔到初始日誌文件大小的某個百分比時觸發Rewrite）
auto-aof-rewrite-min-size 64mb （本次Rewrite最小的寫入數據良）
兩個條件需要同時滿足。
2.Redis內存優化理解
Redis內部有很多的數據類型，這些在官方文檔上都可以看到，下面是其內部優化的一些細節點：
- String 和 數字，
在Redis中如果存儲的是「123」
Redis是能夠識別出來這是一個數字並且按照數字來存儲，節省存儲空間，當然除了這個優化之外
Redis內部會構建一個數字池，默認是10000
那麼如果是在這個池子的數字就只需要用一個簡單的索引來引用進來就可以，而不需要把重複的數字都分開存儲。
這個數值可以調整源代碼的宏：REDIS_SHARED_INTEGERS來擴大和縮小池子的大小。
2.複雜類型的存儲優化，比如Map，List，Set等，這些集合都有一個特點可大可小
，根據實際場景來定，一般情況下如果這些集合所包含的Entry不多，並且每個Entry所包含的Value不是很長的情況下，Redis內部使用緊湊格式來存儲數據，緊湊格式存儲數據在查詢場景的算法複雜度是O(N)，而類似Map或者Set他們的查詢算法複雜度都是O(1)那爲什麼要這麼做呢 ？爲了能夠節省內存空間，在N很小的時候其實和O(1)沒什麼區別。所以這裏不的不介紹緊湊格式的代表ZIPMap，他的數據結構是這樣：
可以看出，這個結構中初始情況只有2個字節，隨着操作的增加它會變長，其中最關鍵的是一個關於Free這個字段的理解，以Map爲例，如果新插入一個Key，那麼對應ZipMap就會多出來一長串數據:。從圖中可以看到插入key1的時候只有綠色的一串，當key2插入的時候就會又出來一個類似的黃色結構串。free的功能是在插入的時候用來冗餘空間的，當key所對應的數值發生變化的時候，如果數據變的比之前短了，那麼free的長度就變大，這個時候不需要做ZipMap的resize操作，如果數據長度變長了，並且在free能夠足以支持新數據的範圍之內，那麼free就被利用起來，並且也不需要做Resize。這個時候會有空間的浪費或者說碎片。空間換時間，沒什麼好說的。當然Redis的代碼中還有另外一個參數ZIPMAP_VALUE_MAX_FREE，這個參數可以用來設置如果Free的大小超過了這個值，那麼ZipMap會發生Resize（收縮），從而節約空間