redis採用的是定期刪除+惰性刪除策略。
為什麼不用定時刪除策略?
定期刪除，redis預設每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。因此，如果只採用定期刪除策略，會導致很多key到時間沒有刪除。
於是，惰性刪除派上用場。也就是說在你獲取某個key的時候，redis會檢查一下，這個key如果設定了過期時間那麼是否過期了？如果過期了此時就會刪除。
採用定期刪除+惰性刪除就沒其他問題了麼?
不是的，如果定期刪除沒刪除key。然後你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的記憶體會越來越高。那麼就應該採用記憶體淘汰機制。
在redis.conf中有一行配置
maxmemory-policy volatile-lru
該配置就是配記憶體淘汰策略的
volatile-lru：從已設定過期時間的資料集（server.db[i].expires）中挑選最近最少使用的資料淘汰
volatile-ttl：從已設定過期時間的資料集（server.db[i].expires）中挑選將要過期的資料淘汰
volatile-random：從已設定過期時間的資料集（server.db[i].expires）中任意選擇資料淘汰
allkeys-lru：從資料集（server.db[i].dict）中挑選最近最少使用的資料淘汰
allkeys-random：從資料集（server.db[i].dict）中任意選擇資料淘汰
no-enviction（驅逐）：禁止驅逐資料，新寫入操作會報錯
ps：如果沒有設定 expire 的key, 不滿足先決條件(prerequisites); 那麼 volatile-lru, volatile-random 和 volatile-ttl 策略的行為, 和 noeviction(不刪除) 基本上一致。
官方faq表示，因為redis是基於記憶體的操作，cpu不是redis的瓶頸，redis的瓶頸最有可能是機器記憶體的大小或者網路頻寬。既然單執行緒容易實現，而且cpu不會成為瓶頸，那就順理成章地採用單執行緒的方案了（畢竟採用多執行緒會有很多麻煩！）redis利用佇列技術將併發訪問變為序列訪問
完全基於記憶體，絕大部分請求是純粹的記憶體操作，非常快速。資料存在記憶體中，類似於hashmap，hashmap的優勢就是查詢和操作的時間複雜度都是o(1)；正因為 redis 是單執行緒，所以要小心使用 redis 指令，對於那些時間複雜度為 o(n) 級別的指令，一定要謹慎使用，一不小心就可能會導致 redis 卡頓。
資料結構簡單，對資料操作也簡單，redis中的資料結構是專門進行設計的；
採用單執行緒，避免了不必要的上下文切換和競爭條件，也不存在多程序或者多執行緒導致的切換而消耗 cpu，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的效能消耗；
3.使用多路i/o復用模型，非阻塞io，redis 單執行緒處理大量的併發客戶端連線的模型。
使用底層模型不同，它們之間底層實現方式以及與客戶端之間通訊的應用協議不一樣，redis直接自己構建了vm 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求；
效能好，每秒可以處理超過 10 萬次讀寫操作
多種資料結構，string、list、hash、set、zset
512m
機率大的redis面試題
近期面試題彙總 Vue系列
1.vue 的雙向繫結原理 2.v model 是怎麼實現的 3.nexttick 的實現原理 4.vue 表單驗證 5.slot 的實現原理 6.vue 常用的指令 7.key的作用是什麼 8.動態元件和非同步元件 9.元件間通訊的方式 10.更新資料元件不更新的情況 11.觸發路由的幾種方式 r...
面試題彙總
1.佇列先進先出，棧先進後出。2.對插入和刪除操作的 限定 棧是限定只能在表的一端進行插入和刪除操作的線性表。佇列是限定只能在表的一端進行插入和在另一端進行刪除操作的線性表。從 資料結構 的角度看，它們都是線性結構，即資料元素之間的關係相同。3.遍歷資料速度不同。順序表是在記憶體中開闢一段連續的空間...
面試題彙總
1 integer和int的區別？2 和equals的區別？int a 50,integer b 50 a b?integer c 50,b c?3 get和post的區別？4 用執行緒池建立執行緒和自己建立執行緒的區別，好處是什麼？5 利用int型陣列實現乙個棧，並實現出棧和入棧操作？要求時間複雜...