1. Redis數據過期淘汰策略
Redis 中數據過期策略採用定期刪除+惰性刪除策略。
定期刪除策略：Redis 啟用一個定時器定時監視所有的 key，判斷key是否過期，過期的話就刪除。這種策略可以保證過期的 key 最終都會被刪除，但是也存在嚴重的缺點：每次都遍歷內存中所有的數據，非常消耗 CPU 資源，並且當 key 已過期，但是定時器還處於未喚起狀態，這段時間內 key 仍然可以用。
惰性刪除策略：在獲取 key 時，先判斷 key 是否過期，如果過期則刪除。這種方式存在一個缺點：如果這個 key 一直未被使用，那麼它一直在內存中，其實它已經過期了，會浪費大量的空間。
2、定期刪除+惰性刪除策略是如何工作的？
這兩種策略天然的互補，結合起來之後，定時刪除策略就發生了一些改變，不在是每次掃描全部的 key 了，而是隨機抽取一部分 key 進行檢查，這樣就降低了對 CPU 資源的損耗，惰性刪除策略互補了為檢查到的key，基本上滿足了所有要求。但是有時候就是那麼的巧，既沒有被定時器抽取到，又沒有被使用，這些數據又如何從內存中消失？沒關系，還有內存淘汰機制，當內存不夠用時，內存淘汰機制就會上場。Redis 內存淘汰機制有以下幾種策略：
noeviction：當內存不足以容納新寫入數據時，新寫入操作會報錯。（Redis 默認策略）
allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的 Key。（推薦使用）
allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個 Key。
volatile-lru：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，移除最近最少使用的 Key。這種情況一般是把 Redis 既當緩存，又做持久化存儲的時候才用。
volatile-random：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，隨機移除某個 Key。
volatile-ttl：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，有更早過期時間的 Key 優先移除。
修改內存淘汰機制只需要在 redis.conf 配置文件中配置 maxmemory-policy 參數即可。
2. redis ttl與生存時間有什麼關系
Redis對鍵提供生存時間，在不指定生存時間時，生存時間是永久。時間到期後Redis會自動刪除這個鍵。可以用EXPIRE命令，時間單位時秒，如果一個鍵是被設為有限的生存時間，那麼在SET key進行重新賦值的時候會被再次設為永久：
SET session:captcha sd2a
EXPIRE session:captcha 600！
3. redis有效期設置方式有幾種
Redis是一種高級key-value資料庫。它跟memcached類似，不過數據可以持久化，而且支持的數據類型很豐富。有字元串，鏈表，集 合和有序集合。
支持在伺服器端計算集合的並，交和補集(difference)等，還支持多種排序功能。
所以Redis也可以被看成是一個數據結構伺服器。
4. 怎麼查看redis數據的過期時間
通過EXPIRE 命令或者PEXPIRE 命令，客戶端可以以秒或者毫秒精度為資料庫中的某個鍵設置生存時間( Time To Live , TTL) ，在經過指定的秒數或者毫秒數之後，伺服器就會自動刪除生存時間為0的鍵:
redis> SET key value
OK
redis> EXP 工RE key 5
(integer) 1
redis> GET key // 5 秒之內
"value"
redis> GET key // 5 秒之後
(nil)
5. Redis過期時間
1.0.0版本後可用
時間復雜度： O(1)
給一個 key 設置超時時間。在一個超時時間結束後，這個鍵將會被自動刪除。一個擁有關聯過期時間的鍵在Redis術語里通常被認為 不穩定的 。
只有刪除或者覆蓋鍵的內容的命令，包括 DEL , SET , GETSET 和所有的 *STORE 命令，才會把過期時間清除。這意味著從理論上講，所有改變鍵上存儲的值而不是使用新的值來替換的操作，都將會保持過期時間不變。例如，使用 INCR 增加一個鍵的值，使用 LPUSH 講一個新的值放到列表中，或者使用 HSET 改變一個哈希的欄位的值都將會使過期時間保持不變。
使用 PERSIST 命令將一個鍵變成持久化的鍵，過期時間也會被清除。
如果一個鍵被 RENAME 重命名，關聯的生存時間將會被轉移到新的鍵名上。
如果一個鍵被 RENAME 重命名，就像在一個已經存在的鍵 Key_A ，它被一個調用 RENAME Key_B Key_A 所覆蓋，原始的 Key_A 是否關聯過期時間是沒關系的，新的鍵 Key_A 將會繼承 Key_B 的所有特徵。
注意，使用負數調用 EXPIRE / PEXPIRE ，或者使用過去的時間調用 EXPIREAT / PEXPIREAT 將會使鍵被刪除，而不是過期(相應的，彈出的 key event 將會是 del ，而不是 expired )。
可以使用一個已經有過期時間集的鍵作為參數來調用 EXPIRE 。在這種情況下，一個鍵的生存時間已經 更新 為一個新值。對此很多應用，下面的 Navigation session 模式一節記錄了一個例子。
在Redis 2.1.3之前的版本中，使用一個命令改變一個擁有過期時間的鍵的值，效果跟徹底移除這個鍵一樣。這種語義是必須的，因為復制層的限制現在已經確定了。
EXPIRE 將會返回0，並且不會使用一個過期時間集合來改變一個鍵的過期時間。
特別的 返回數字 ：
redis> SET mykey "Hello"
redis> EXPIRE mykey 10
redis> TTL mykey
redis> SET mykey "Hello World"
redis> TTL mykey
redis>
想像你有一個網頁服務，並且你對用戶最近訪問的N個頁面有興趣，這樣每個臨近的頁面視圖的執行時間不會超過前一個頁面視圖執行的60秒。理論上來講，你可以認為用戶訪問的頁面集合為 Navigation session ，其中就可以包含用戶在尋找哪些他或她感興趣的產品信息，因此你可以推薦關聯的產品。
你可以非常容易的使用下面的策略在Redis中建模這種類型：每次用戶訪問一個頁面你就調用下面的命令：
如果用戶閑置超過60秒，這個鍵將會被刪除，只有訪問時間差值小於60秒的頁面才會被記錄。
這個模式可以很容易的修改為使用 INCR 做計數器來替代使用 RPUSH 的列表。
通常情況下創建Redis的鍵時不關聯生存時間。這個鍵將會簡單的一直生存，除非用戶顯示的刪除它，例如使用 DEL 命令。
EXPIRE 家族命令能夠把一個過期時間關聯到一個給定的鍵，代價是這個鍵會使用額外的內存。當一個鍵設置了過期時間，Redis將會確保當指定的時間過去之後移除這個鍵。
一個鍵的生存時間可以被 EXPIRE 命令更新，或者被 PERSIST 命令完全移除(或其他嚴格相關的命令)。
在Redis2.4版本中，過期時間可能不是非常精確的，並且它可能是在0到1秒之間的出入。從Redis2.6版本開始，過期時間誤差是從0到1毫秒。
鍵的過期信息以絕對的Unix時間戳形式保存(Redis2.6以及更新的版本毫秒內)。這意味著甚至當Redis實例未啟動時時間就流走了。
為了過期時間能工作的很好，計算機時間必須保持穩定。如果你從兩個時鍾巨大不同步的計算機上移動一個RDB文件，有趣的事情將會發生(像所有的鍵在載入時變成過期)。
實際上運行中的實例將一直會檢查計算機的時鍾，舉例來說，如果你給一個鍵設置1000秒的生存時間，然後在未來將你的計算機設置在2000秒以後，這個鍵將會立即失效，而不是持續1000秒。
Redis鍵將會通過兩種方式過期：一個被動的方式，和一個主動的方式。
一個鍵的被動過期是很簡單的，當一些客戶端嘗試訪問它，然後這個鍵被發現超時了。
當然，這是不夠的，因為有一些鍵將永遠不會被再次訪問。這些鍵無論如何都應該被過期。所以，Redis會定期的在過期的集合中隨機范圍內測試少量的鍵。所有的已過期的鍵將會被從鍵空間被刪除。
這就是Redis會在每秒做10次的事情：
這是一個小概率的演算法，基本的設想是我們的樣本代表整個鍵空間，然後我們繼續失效直到將要失效的鍵百分比小於25%。
這意味著在任何一個時刻，正在使用內存的已經過期的最大數量的鍵等於每秒最大寫操作數量除以4.
為了獲得正確的行為而不犧牲一致性，當一個鍵失效， DEL 操作會同時在AOF文件和附屬的副節點執行。這種方式失效進程是在主實例集中的，也不會出現一致性錯誤。
然而，當副本已經連接到主節點後將不會獨立的失效鍵(但將會等待來自主節點的 DEL )，他們仍將會獲取數據集中的全部過期狀態，所以當一個副本被選舉為主節點後，它將能夠獨立的失效這些鍵，完全像一個主節點。
6. 三分鍾讀懂redis資料庫
redis是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步。
1. 使用Redis有哪些好處？
(1) 速度快，因為數據存在內存中，類似於HashMap，HashMap的優勢就是查找和操作的時間復雜度都是O(1)
(2) 支持豐富數據類型，支持string，list，set，sorted set，hash
(3) 支持事務，操作都是原子性，所謂的原子性就是對數據的更改要麼全部執行，要麼全部不執行
(4) 豐富的特性：可用於緩存，消息，按key設置過期時間，過期後將會自動刪除
2. redis相比memcached有哪些優勢？
(1) memcached所有的值均是簡單的字元串，redis作為其替代者，支持更為豐富的數據類型
(2) redis的速度比memcached快很多
(3) redis可以持久化其數據
3. redis常見性能問題和解決方案：
(1) Master最好不要做任何持久化工作，如RDB內存快照和AOF日誌文件
(2) 如果數據比較重要，某個Slave開啟AOF備份數據，策略設置為每秒同步一次
(3) 為了主從復制的速度和連接的穩定性，Master和Slave最好在同一個區域網內
(4) 盡量避免在壓力很大的主庫上增加從庫
(5) 主從復制不要用圖狀結構，用單向鏈表結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3...
這樣的結構方便解決單點故障問題，實現Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。
4. MySQL里有2000w數據，redis中只存20w的數據，如何保證redis中的數據都是熱點數據
相關知識：redis 內存數據集大小上升到一定大小的時候，就會施行數據淘汰策略。redis 提供 6種數據淘汰策略：
voltile-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（驅逐）：禁止驅逐數據
相關推薦：《Python視頻教程》
5. Memcache與Redis的區別都有哪些？
1)、存儲方式
Memecache把數據全部存在內存之中，斷電後會掛掉，數據不能超過內存大小。
Redis有部份存在硬碟上，這樣能保證數據的持久性。
2)、數據支持類型
Memcache對數據類型支持相對簡單。
Redis有復雜的數據類型。
3），value大小
redis最大可以達到1GB，而memcache只有1MB
6. Redis 常見的性能問題都有哪些？如何解決？
1).Master寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫內存快照。
2).Master AOF持久化，如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復速度。Master最好不要做任何持久化工作，包括內存快照和AOF日誌文件，特別是不要啟用內存快照做持久化,如果數據比較關鍵，某個Slave開啟AOF備份數據，策略為每秒同步一次。
3).Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會佔大量的CPU和內存資源，導致服務load過高，出現短暫服務暫停現象。
4). Redis主從復制的性能問題，為了主從復制的速度和連接的穩定性，Slave和Master最好在同一個區域網內
7. redis 最適合的場景
Redis最適合所有數據in-momory的場景，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed的功能，跟傳統意義上的持久化有比較大的差別，那麼可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那麼何時使用Memcached,何時使用Redis呢?
如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：
1.Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
2.Redis支持數據的備份，即master-slave模式的數據備份。
3.Redis支持數據的持久化，可以將內存中的數據保持在磁碟中，重啟的時候可以再次載入進行使用。
（1）會話緩存（Session Cache）
最常用的一種使用Redis的情景是會話緩存（session cache）。用Redis緩存會話比其他存儲（如Memcached）的優勢在於：Redis提供持久化。當維護一個不是嚴格要求一致性的緩存時，如果用戶的購物車信息全部丟失，大部分人都會不高興的，現在，他們還會這樣嗎？
幸運的是，隨著 Redis 這些年的改進，很容易找到怎麼恰當的使用Redis來緩存會話的文檔。甚至廣為人知的商業平台Magento也提供Redis的插件。
（2）全頁緩存（FPC）
除基本的會話token之外，Redis還提供很簡便的FPC平台。回到一致性問題，即使重啟了Redis實例，因為有磁碟的持久化，用戶也不會看到頁面載入速度的下降，這是一個極大改進，類似PHP本地FPC。
再次以Magento為例，Magento提供一個插件來使用Redis作為全頁緩存後端。
此外，對WordPress的用戶來說，Pantheon有一個非常好的插件 wp-redis，這個插件能幫助你以最快速度載入你曾瀏覽過的頁面。
（3）隊列
Reids在內存存儲引擎領域的一大優點是提供 list 和 set 操作，這使得Redis能作為一個很好的消息隊列平台來使用。Redis作為隊列使用的操作，就類似於本地程序語言（如Python）對 list 的 push/pop 操作。
如果你快速的在Google中搜索「Redis queues」，你馬上就能找到大量的開源項目，這些項目的目的就是利用Redis創建非常好的後端工具，以滿足各種隊列需求。例如，Celery有一個後台就是使用Redis作為broker，你可以從這里去查看。
（4）排行榜/計數器
Redis在內存中對數字進行遞增或遞減的操作實現的非常好。集合（Set）和有序集合（Sorted Set）也使得我們在執行這些操作的時候變的非常簡單，Redis只是正好提供了這兩種數據結構。所以，我們要從排序集合中獲取到排名最靠前的10個用戶–我們稱之為「user_scores」，我們只需要像下面一樣執行即可：
當然，這是假定你是根據你用戶的分數做遞增的排序。如果你想返回用戶及用戶的分數，你需要這樣執行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一個很好的例子，用Ruby實現的，它的排行榜就是使用Redis來存儲數據的，你可以在這里看到。
（5）發布/訂閱
最後（但肯定不是最不重要的）是Redis的發布/訂閱功能。發布/訂閱的使用場景確實非常多。我已看見人們在社交網路連接中使用，還可作為基於發布/訂閱的腳本觸發器，甚至用Redis的發布/訂閱功能來建立聊天系統！（不，這是真的，你可以去核實）。
7. java設置 redis 失效時間多久
EXPIRE命令返回1表示成功，返回0表示鍵值不存在或設置失敗。
同時這里還有一個比較常用的命令是ttl，用於查看一個鍵還有多久時間會被刪除。返回的是剩餘時間（秒數）。
這里就不貼代碼了，有一點需要說明的是，ttl命令在鍵不存在或被刪除之後，會返回-2，在沒有為鍵設置生存時間（即永久存在，建一個鍵之後的默認情況）時返回的是-1。大家可以親自操作一把。
如果想要把一個設置過過期時間的鍵取消過期時間設置，則需要使用persist命令。
redis > SET session:27e7a id1234
OK
redis > EXPIRE session:27e7a 1200
(integer) 1
redis > TTL session:27e7a
(integer) 1092
redis > PERSIST session:27e7a
(integer) 1
redis > TTL session:27e7a
(integer) -1
這里需要說明一點的是，除了使用persist命令外，使用set、getset命令為鍵賦值，也會同時消除鍵的生存時間，如果需要可以重新使用expire命令為鍵設置生存時間。而其他對鍵的操作命令（如incr、lpush、hset、zrem）都不會影響鍵的生存時間。
expire命令的單位是秒，而且這個參數必須為整數，如果需要更精準的時間的話，需要使用pexpire命令設置，其單位為毫秒，同理也需要用pttl命令來看鍵的剩餘毫秒數。當然使用expire命令設置的過期時間也是可以用pttl看鍵的剩餘毫秒數的。
訪問限制
有時候我們會有一個需求是需要限制一個用戶對一個資源的訪問頻率，我們假定一個用戶（用IP作為判斷）每分鍾對一個資源訪問次數不能超過10次。
我們可以使用一個鍵，每次用戶訪問則把值加1，當值加到10的時候，我們設定鍵的過期時間為60秒，並且禁止訪問。這時候下次訪問發現值為10，則不讓訪問了，然後60秒後鍵被刪除，這時候再次創建鍵。這樣就可以解決，但是其實這樣時間並不精準，問題還是挺大的。
我們還有一個方案：使用隊列。前面的章節也說到了，使用列表類型可以用作隊列。
我們設定一個隊列rate.limiting.192.168.1.1（假定是這個IP），我們把每次的訪問時間都添加到隊列中，當隊列長度達到10以後，判斷當前時間與隊列第一個值的時間差是否小於60，如果小於60則說明60秒內訪問次數超過10次，不允許訪問；否則說明可以訪問，則把隊列頭的值刪除，隊列尾增加當前訪問時間。
這種方法可以比較精準的實現訪問限制，但是當限制的次數比較大時，這種方法佔用的存儲空間也會比較大。
緩存
有時候會把一些對CPU或IO資源消耗比較大的操作結果緩存起來，並設置一定時間的自動過期。比如我們設定一個微博外鏈的最熱站點緩存放於新浪微博的首頁，這樣我們不可能每次訪問都重新計算最熱的外鏈站點，所以我們可以設定兩小時更新一次。每次訪問是判斷這個鍵有沒有，如果存在則直接返回，如果沒有則通過計算把內容存入鍵中，並設定兩小時的過期時間。
然而在很多場合這種方法會很恐怖，當伺服器內存有限的時候，大量使用緩存切設置生存時間過長就會導致redis佔用太多內存，而redis有時候會把系統內存都吃掉，導致系統崩潰。但是設置時間過短又會導致緩存的命中太低。
所以我們最好的辦法是設定緩存的淘汰規則。這種方式比較適用於將redis用作緩存系統的時候比較好。
具體就是：修改配置文件中的maxmemory參數，限制redis的最大內存，當超出後會按照maxmemory-policy參數指定的策略刪除不需要的鍵，直到redis佔用的內存小於設定值。
8. 如何查詢redis的緩存文件路徑
1、首先找到redis的安裝目錄，如下圖測試環境目錄，進入到/opt/install/redis-2.8.19/src，如下圖所示。
9. redis ttl過期會 自動刪除嗎
在Redis中，內存的大小是有限的，所以為了防止內存飽和，需要實現某種鍵淘汰策略。主要有兩種方法，一種是當Redis內存不足時所採用的內存釋放策略。
另一種是對過期鍵進行刪除的策略，也可以在某種程度上釋放內存。