Redis緩存相關問題總結

使用緩存是系統性能優化的第一黃金法則。

緩存的設計和使用對一個系統的性能相當重要，平時接觸到項目不管多少也都會在某些層面用到緩存，好比用HashMap實現，Ehcache，memcached、redis等。Redis算是目前最火的方案之一，今天看了它相關的一些問題，總結匯總一下。

1、Redis的優缺點及適用場景

Redis 是一個基於內存的高性能key-value數據庫。很像memcached，整個數據庫通通加載在內存當中進行操做，按期經過異步操做把數據庫數據flush到硬盤上進行保存。它的優勢以下：

(1) 速度快，由於數據存在內存中，相似於HashMap，HashMap的優點就是查找和操做的時間複雜度都是O(1)

(2) 支持豐富數據類型，支持string，list，set，sorted set，hash

(3) 支持事務，操做都是原子性，所謂的原子性就是對數據的更改要麼所有執行，要麼所有不執行

(4) 豐富的特性：可用於緩存，消息，按key設置過時時間，過時後將會自動刪除
Redis的主要缺點是數據庫容量受到物理內存的限制，不能用做海量數據的高性能讀寫，所以Redis適合的場景主要侷限在較小數據量的高性能操做和運算上。

Redis最適合全部數據in-momory的場景，如：

（1）、會話緩存（Session Cache）

最經常使用的一種使用Redis的情景是會話緩存（session cache）。用Redis緩存會話比其餘存儲（如Memcached）的優點在於：Redis提供持久化。

（2）、全頁緩存（FPC）

除基本的會話token以外，Redis還提供很簡便的FPC平臺。回到一致性問題，即便重啓了Redis實例，由於有磁盤的持久化，用戶也不會看到頁面加載速度的降低，這是一個極大改進，相似PHP本地FPC。

（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的發佈/訂閱功能。發佈/訂閱的使用場景確實很是多。

 

 

2、redis的緩存失效策略和主鍵失效機制

　　做爲緩存系統都要按期清理無效數據，就須要一個主鍵失效和淘汰策略.
　　在Redis當中，有生存期的key被稱爲volatile。在建立緩存時，要爲給定的key設置生存期，當key過時的時候（生存期爲0），它可能會被刪除。
　　一、影響生存時間的一些操做
　　生存時間能夠經過使用 DEL 命令來刪除整個 key 來移除，或者被 SET 和 GETSET 命令覆蓋原來的數據，也就是說，修改key對應的value和使用另外相同的key和value來覆蓋之後，當前數據的生存時間不一樣。
　　好比說，對一個 key 執行INCR命令，對一個列表進行LPUSH命令，或者對一個哈希表執行HSET命令，這類操做都不會修改 key 自己的生存時間。另外一方面，若是使用RENAME對一個 key 進行更名，那麼更名後的 key的生存時間和更名前同樣。
　　RENAME命令的另外一種多是，嘗試將一個帶生存時間的 key 更名成另外一個帶生存時間的 another_key ，這時舊的 another_key (以及它的生存時間)會被刪除，而後舊的 key 會更名爲 another_key ，所以，新的 another_key 的生存時間也和本來的 key 同樣。使用PERSIST命令能夠在不刪除 key 的狀況下，移除 key 的生存時間，讓 key 從新成爲一個persistent key 。
　　二、如何更新生存時間
　　能夠對一個已經帶有生存時間的 key 執行EXPIRE命令，新指定的生存時間會取代舊的生存時間。過時時間的精度已經被控制在1ms以內，主鍵失效的時間複雜度是O（1），
　　EXPIRE和TTL命令搭配使用，TTL能夠查看key的當前生存時間。設置成功返回 1；當 key 不存在或者不能爲 key 設置生存時間時，返回 0 。
　　最大緩存配置
　　在 redis 中，容許用戶設置最大使用內存大小
　　server.maxmemory
　　默認爲0，沒有指定最大緩存，若是有新的數據添加，超過最大內存，則會使redis崩潰，因此必定要設置。redis 內存數據集大小上升到必定大小的時候，就會實行數據淘汰策略。
　　redis 提供 6種數據淘汰策略：
　　． 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（驅逐）：禁止驅逐數據
　　注意這裏的6種機制，volatile和allkeys規定了是對已設置過時時間的數據集淘汰數據仍是從所有數據集淘汰數據，後面的lru、ttl以及random是三種不一樣的淘汰策略，再加上一種no-enviction永不回收的策略。
　　使用策略規則：
　　一、若是數據呈現冪律分佈，也就是一部分數據訪問頻率高，一部分數據訪問頻率低，則使用allkeys-lru
　　二、若是數據呈現平等分佈，也就是全部的數據訪問頻率都相同，則使用allkeys-random
　　三種數據淘汰策略：
　　ttl和random比較容易理解，實現也會比較簡單。主要是Lru最近最少使用淘汰策略，設計上會對key 按失效時間排序，而後取最早失效的key進行淘汰

 

3、Redis是單進程單線程的，併發問題如何解決

Redis爲單進程單線程模式，採用隊列模式將併發訪問變爲串行訪問。Redis自己沒有鎖的概念，Redis對於多個客戶端鏈接並不存在競爭，可是在Jedis客戶端對Redis進行併發訪問時會發生鏈接超時、數據轉換錯誤、阻塞、客戶端關閉鏈接等問題，這些問題均是因爲客戶端鏈接混亂形成。對此有2種解決方法：

　　　1.客戶端角度，爲保證每一個客戶端間正常有序與Redis進行通訊，對鏈接進行池化，同時對客戶端讀寫Redis操做採用內部鎖synchronized。

　　　2.服務器角度，利用setnx實現鎖。
　　　注：對於第一種，須要應用程序本身處理資源的同步，可使用的方法比較通俗，可使用synchronized也可使用lock；第二種須要用到Redis的setnx命令，可是須要注意一些問題。

 

4、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最好在同一個局域網內。

 

5、redis持久化的幾種方式

一、快照（snapshots）
　　缺省狀況狀況下，Redis把數據快照存放在磁盤上的二進制文件中，文件名爲dump.rdb。你能夠配置Redis的持久化策略，例如數據集中每N秒鐘有超過M次更新，就將數據寫入磁盤；或者你能夠手工調用命令SAVE或BGSAVE。
　　工做原理
　　． Redis forks.
　　． 子進程開始將數據寫到臨時RDB文件中。
　　． 當子進程完成寫RDB文件，用新文件替換老文件。
　　． 這種方式可使Redis使用copy-on-write技術。
二、AOF
　　快照模式並不十分健壯，當系統中止，或者無心中Redis被kill掉，最後寫入Redis的數據就會丟失。這對某些應用也許不是大問題，但對於要求高可靠性的應用來講，
　　Redis就不是一個合適的選擇。
　　Append-only文件模式是另外一種選擇。
　　你能夠在配置文件中打開AOF模式
三、虛擬內存方式
　　當你的key很小而value很大時,使用VM的效果會比較好.由於這樣節約的內存比較大.
　　當你的key不小時,能夠考慮使用一些很是方法將很大的key變成很大的value,好比你能夠考慮將key,value組合成一個新的value.
　　vm-max-threads這個參數,能夠設置訪問swap文件的線程數,設置最好不要超過機器的核數,若是設置爲0,那麼全部對swap文件的操做都是串行的.可能會形成比較長時間的延遲,可是對數據完整性有很好的保證.

　　本身測試的時候發現用虛擬內存性能也不錯。若是數據量很大，能夠考慮分佈式或者其餘數據庫。

 

六，其它

Redis和Memcached的區別

一、數據類型支持不一樣

與Memcached僅支持簡單的key-value結構的數據記錄不一樣，Redis支持的數據類型要豐富得多。最爲經常使用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject對象來表示全部的key和value。redisObject最主要的信息如圖所示：

type表明一個value對象具體是何種數據類型，encoding是不一樣數據類型在redis內部的存儲方式，好比：type=string表明value存儲的是一個普通字符串，那麼對應的encoding能夠是raw或者是int，若是是int則表明實際redis內部是按數值型類存儲和表示這個字符串的，固然前提是這個字符串自己能夠用數值表示，好比:」123″ 「456」這樣的字符串。只有打開了Redis的虛擬內存功能，vm字段字段纔會真正的分配內存，該功能默認是關閉狀態的。

1）String

• 經常使用命令：set/get/decr/incr/mget等；
• 應用場景：String是最經常使用的一種數據類型，普通的key/value存儲均可以歸爲此類；
• 實現方式：String在redis內部存儲默認就是一個字符串，被redisObject所引用，當遇到incr、decr等操做時會轉成數值型進行計算，此時redisObject的encoding字段爲int。

2）Hash

• 經常使用命令：hget/hset/hgetall等
• 應用場景：咱們要存儲一個用戶信息對象數據，其中包括用戶ID、用戶姓名、年齡和生日，經過用戶ID咱們但願獲取該用戶的姓名或者年齡或者生日；
• 實現方式：Redis的Hash實際是內部存儲的Value爲一個HashMap，並提供了直接存取這個Map成員的接口。如圖所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取均可以直接經過其內部Map的Key(Redis裏稱內部Map的key爲field), 也就是經過 key(用戶ID) + field(屬性標籤) 就能夠操做對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis爲了節省內存會採用相似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，這時對應的value的redisObject的encoding爲zipmap，當成員數量增大時會自動轉成真正的HashMap,此時encoding爲ht。

3）List

• 經常使用命令：lpush/rpush/lpop/rpop/lrange等；
• 應用場景：Redis list的應用場景很是多，也是Redis最重要的數據結構之一，好比twitter的關注列表，粉絲列表等均可以用Redis的list結構來實現；
• 實現方式：Redis list的實現爲一個雙向鏈表，便可以支持反向查找和遍歷，更方便操做，不過帶來了部分額外的內存開銷，Redis內部的不少實現，包括髮送緩衝隊列等也都是用的這個數據結構。

4）Set

• 經常使用命令：sadd/spop/smembers/sunion等；
• 應用場景：Redis set對外提供的功能與list相似是一個列表的功能，特殊之處在於set是能夠自動排重的，當你須要存儲一個列表數據，又不但願出現重複數據時，set是一個很好的選擇，而且set提供了判斷某個成員是否在一個set集合內的重要接口，這個也是list所不能提供的；
• 實現方式：set 的內部實現是一個 value永遠爲null的HashMap，實際就是經過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的緣由。

5）Sorted Set

• 經常使用命令：zadd/zrange/zrem/zcard等；
• 應用場景：Redis sorted set的使用場景與set相似，區別是set不是自動有序的，而sorted set能夠經過用戶額外提供一個優先級(score)的參數來爲成員排序，而且是插入有序的，即自動排序。當你須要一個有序的而且不重複的集合列表，那麼能夠選擇sorted set數據結構，好比twitter 的public timeline能夠以發表時間做爲score來存儲，這樣獲取時就是自動按時間排好序的。
• 實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap裏放的是成員到score的映射，而跳躍表裏存放的是全部的成員，排序依據是HashMap裏存的score,使用跳躍表的結構能夠得到比較高的查找效率，而且在實現上比較簡單。

二、內存管理機制不一樣

在Redis中，並非全部的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。當物理內存用完時，Redis能夠將一些好久沒用到的value交換到磁盤。Redis只會緩存全部的key的信息，若是Redis發現內存的使用量超過了某一個閥值，將觸發swap的操做，Redis根據「swappability = age*log(size_in_memory)」計算出哪些key對應的value須要swap到磁盤。而後再將這些key對應的value持久化到磁盤中，同時在內存中清除。這種特性使得Redis能夠保持超過其機器自己內存大小的數據。固然，機器自己的內存必需要可以保持全部的key，畢竟這些數據是不會進行swap操做的。同時因爲Redis將內存中的數據swap到磁盤中的時候，提供服務的主線程和進行swap操做的子線程會共享這部份內存，因此若是更新須要swap的數據，Redis將阻塞這個操做，直到子線程完成swap操做後才能夠進行修改。當從Redis中讀取數據的時候，若是讀取的key對應的value不在內存中，那麼Redis就須要從swap文件中加載相應數據，而後再返回給請求方。 這裏就存在一個I/O線程池的問題。在默認的狀況下，Redis會出現阻塞，即完成全部的swap文件加載後纔會相應。這種策略在客戶端的數量較小，進行批量操做的時候比較合適。可是若是將Redis應用在一個大型的網站應用程序中，這顯然是沒法知足大併發的狀況的。因此Redis運行咱們設置I/O線程池的大小，對須要從swap文件中加載相應數據的讀取請求進行併發操做，減小阻塞的時間。

三、持久化方案

四、集羣管理的不一樣

Couchbase vs Redis，究竟哪一個更勝一籌？

Redis有哪些數據結構？

字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。

若是你是Redis中高級用戶，還須要加上下面幾種數據結構HyperLogLog、Geo、Pub/Sub。

若是你說還玩過Redis Module，像BloomFilter，RedisSearch，Redis-ML，面試官得眼睛就開始發亮了。

使用過Redis分佈式鎖麼，它是什麼回事？

先拿setnx來爭搶鎖，搶到以後，再用expire給鎖加一個過時時間防止鎖忘記了釋放。

這時候對方會告訴你說你回答得不錯，而後接着問若是在setnx以後執行expire以前進程意外crash或者要重啓維護了，那會怎麼樣？

這時候你要給予驚訝的反饋：唉，是喔，這個鎖就永遠得不到釋放了。緊接着你須要抓一抓本身得腦殼，故做思考片刻，好像接下來的結果是你主動思考出來的，而後回答：我記得set指令有很是複雜的參數，這個應該是能夠同時把setnx和expire合成一條指令來用的！對方這時會顯露笑容，內心開始默唸：摁，這小子還不錯。

假如Redis裏面有1億個key，其中有10w個key是以某個固定的已知的前綴開頭的，若是將它們所有找出來？

使用keys指令能夠掃出指定模式的key列表。

對方接着追問：若是這個redis正在給線上的業務提供服務，那使用keys指令會有什麼問題？

這個時候你要回答redis關鍵的一個特性：redis的單線程的。keys指令會致使線程阻塞一段時間，線上服務會停頓，直到指令執行完畢，服務才能恢復。這個時候可使用scan指令，scan指令能夠無阻塞的提取出指定模式的key列表，可是會有必定的重複機率，在客戶端作一次去重就能夠了，可是總體所花費的時間會比直接用keys指令長。

使用過Redis作異步隊列麼，你是怎麼用的？

通常使用list結構做爲隊列，rpush生產消息，lpop消費消息。當lpop沒有消息的時候，要適當sleep一會再重試。

若是對方追問可不能夠不用sleep呢？list還有個指令叫blpop，在沒有消息的時候，它會阻塞住直到消息到來。

若是對方追問能不能生產一次消費屢次呢？使用pub/sub主題訂閱者模式，能夠實現1:N的消息隊列。

若是對方追問pub/sub有什麼缺點？在消費者下線的狀況下，生產的消息會丟失，得使用專業的消息隊列如rabbitmq等。

若是對方追問redis如何實現延時隊列？我估計如今你很想把面試官一棒打死若是你手上有一根棒球棍的話，怎麼問的這麼詳細。可是你很剋制，而後神態自若的回答道：使用sortedset，拿時間戳做爲score，消息內容做爲key調用zadd來生產消息，消費者用zrangebyscore指令獲取N秒以前的數據輪詢進行處理。

到這裏，面試官暗地裏已經對你豎起了大拇指。可是他不知道的是此刻你卻豎起了中指，在椅子背後。

若是有大量的key須要設置同一時間過時，通常須要注意什麼？

若是大量的key過時時間設置的過於集中，到過時的那個時間點，redis可能會出現短暫的卡頓現象。通常須要在時間上加一個隨機值，使得過時時間分散一些。

Redis如何作持久化的？

bgsave作鏡像全量持久化，aof作增量持久化。由於bgsave會耗費較長時間，不夠實時，在停機的時候會致使大量丟失數據，因此須要aof來配合使用。在redis實例重啓時，會使用bgsave持久化文件從新構建內存，再使用aof重放近期的操做指令來實現完整恢復重啓以前的狀態。

對方追問那若是忽然機器掉電會怎樣？取決於aof日誌sync屬性的配置，若是不要求性能，在每條寫指令時都sync一下磁盤，就不會丟失數據。可是在高性能的要求下每次都sync是不現實的，通常都使用定時sync，好比1s1次，這個時候最多就會丟失1s的數據。

對方追問bgsave的原理是什麼？你給出兩個詞彙就能夠了，fork和cow。fork是指redis經過建立子進程來進行bgsave操做，cow指的是copy on write，子進程建立後，父子進程共享數據段，父進程繼續提供讀寫服務，寫髒的頁面數據會逐漸和子進程分離開來。

Pipeline有什麼好處，爲何要用pipeline？

能夠將屢次IO往返的時間縮減爲一次，前提是pipeline執行的指令之間沒有因果相關性。使用redis-benchmark進行壓測的時候能夠發現影響redis的QPS峯值的一個重要因素是pipeline批次指令的數目。

Redis的同步機制瞭解麼？

Redis可使用主從同步，從從同步。第一次同步時，主節點作一次bgsave，並同時將後續修改操做記錄到內存buffer，待完成後將rdb文件全量同步到複製節點，複製節點接受完成後將rdb鏡像加載到內存。加載完成後，再通知主節點將期間修改的操做記錄同步到複製節點進行重放就完成了同步過程。

是否使用過Redis集羣，集羣的原理是什麼？

Redis Sentinal着眼於高可用，在master宕機時會自動將slave提高爲master，繼續提供服務。

 

Redis Cluster着眼於擴展性，在單個redis內存不足時，使用Cluster進行分片存儲。

https://mp.weixin.qq.com/s/507jyNbL4xCkxyW6Xk15Xg