Redis淘汰機制
Redis內存淘汰web
指的是用戶存儲的一些鍵被能夠被Redis主動地從實例中刪除，從而產生讀miss的狀況redis
那麼Redis爲何要有這種功能？這就是咱們須要探究的設計初衷。算法
Redis最多見的兩種應用場景爲緩存和持久存儲緩存
首先要明確的一個問題是內存淘汰策略更適合於那種場景？是持久存儲仍是緩存？安全
內存的淘汰機制的初衷是爲了更好地使用內存，網絡
用必定的緩存miss來換取內存的使用效率。數據結構
做爲Redis用戶，我如何使用Redis提供的這個特性呢？看看下面配置dom
maxmemory
525行svg
咱們能夠經過配置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（收縮），從而節約空間