Redis的最常被問到知識點總結

1.什麼是redis?

　　　Redis 是一個基於內存的高性能key-value數據庫。 

2.Reids的特色　　

　　　Redis本質上是一個Key-Value類型的內存數據庫，很像memcached，整個數據庫通通加載在內存當中進行操做，按期經過異步操做把數據庫數據flush到硬盤上進行保存。由於是純內存操做，Redis的性能很是出色，每秒能夠處理超過 10萬次讀寫操做，是已知性能最快的Key-Value DB。

　　　Redis的出色之處不只僅是性能，Redis最大的魅力是支持保存多種數據結構，此外單個value的最大限制是1GB，不像 memcached只能保存1MB的數據，所以Redis能夠用來實現不少有用的功能，比方說用他的List來作FIFO雙向鏈表，實現一個輕量級的高性 能消息隊列服務，用他的Set能夠作高性能的tag系統等等。另外Redis也能夠對存入的Key-Value設置expire時間，所以也能夠被看成一 個功能增強版的memcached來用。

　　　Redis的主要缺點是數據庫容量受到物理內存的限制，不能用做海量數據的高性能讀寫，所以Redis適合的場景主要侷限在較小數據量的高性能操做和運算上。

3.使用redis有哪些好處？ 　　

   (1) 速度快，由於數據存在內存中，相似於HashMap，HashMap的優點就是查找和操做的時間複雜度都是O(1) 
   (2) 支持豐富數據類型，支持string，list，set，sorted set，hash 

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。
hash
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,使用跳躍表的結構能夠得到比較高的查找效率，而且在實現上比較簡單。

   (3) 支持事務，操做都是原子性，所謂的原子性就是對數據的更改要麼所有執行，要麼所有不執行 
   (4) 豐富的特性：可用於緩存，消息，按key設置過時時間，過時後將會自動刪除

4.redis相比memcached有哪些優點？ 　　

　(1) memcached全部的值均是簡單的字符串，redis做爲其替代者，支持更爲豐富的數據類型 
　(2) redis的速度比memcached快不少 (3) redis能夠持久化其數據

5.Memcache與Redis的區別都有哪些？    

　(1)、存儲方式 Memecache把數據所有存在內存之中，斷電後會掛掉，數據不能超過內存大小。 Redis有部份存在硬盤上，這樣能保證數據的持久性。 
　(2)、數據支持類型 Memcache對數據類型支持相對簡單。 Redis有複雜的數據類型。 
　(3)、使用底層模型不一樣 它們之間底層實現方式 以及與客戶端之間通訊的應用協議不同。 Redis直接本身構建了VM 機制 ，由於通常的系統調用系統函數的話，會浪費必定的時間去移動和請求。 

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

七、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進行淘汰

8.爲何redis須要把全部數據放到內存中?　

　　　Redis爲了達到最快的讀寫速度將數據都讀到內存中，並經過異步的方式將數據寫入磁盤。因此redis具備快速和數據持久化的特徵。若是不將數據放在內存中，磁盤I/O速度爲嚴重影響redis的性能。在內存愈來愈便宜的今天，redis將會愈來愈受歡迎。

　　　若是設置了最大使用的內存，則數據已有記錄數達到內存限值後不能繼續插入新值。

9.Redis是單進程單線程的

　　　redis利用隊列技術將併發訪問變爲串行訪問，消除了傳統數據庫串行控制的開銷

10.redis的併發競爭問題如何解決?

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

　　　　　因爲客戶端鏈接混亂形成。對此有2種解決方法：

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

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

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

12.redis事物的瞭解CAS(check-and-set 操做實現樂觀鎖 )?

　　　　和衆多其它數據庫同樣，Redis做爲NoSQL數據庫也一樣提供了事務機制。在Redis中，MULTI/EXEC/DISCARD/WATCH這四個命令是咱們實現事務的基石。相信對有關係型數據庫開發經驗的開發者而言這一律念並不陌生，即使如此，咱們仍是會簡要的列出

　　　　Redis中

　　事務的實現特徵：
　　　　1). 在事務中的全部命令都將會被串行化的順序執行，事務執行期間，Redis不會再爲其它客戶端的請求提供任何服務，從而保證了事物中的全部命令被原子的執行。
　　　　2). 和關係型數據庫中的事務相比，在Redis事務中若是有某一條命令執行失敗，其後的命令仍然會被繼續執行。
　　　　3). 咱們能夠經過MULTI命令開啓一個事務，有關係型數據庫開發經驗的人能夠將其理解爲"BEGIN TRANSACTION"語句。在該語句以後執行的命令都將被視爲事務以內的操做，最後咱們能夠經過執行EXEC/DISCARD命令來提交/回滾該事務內的全部操做。這兩個Redis命令可被視爲等同於關係型數據庫中的COMMIT/ROLLBACK語句。

　　　　4). 在事務開啓以前，若是客戶端與服務器之間出現通信故障並致使網絡斷開，其後全部待執行的語句都將不會被服務器執行。然而若是網絡中斷事件是發生在客戶端執行EXEC命令以後，那麼該事務中的全部命令都會被服務器執行。

　　　　5). 當使用Append-Only模式時，Redis會經過調用系統函數write將該事務內的全部寫操做在本次調用中所有寫入磁盤。然而若是在寫入的過程當中出現系統崩潰，如電源故障致使的宕機，那麼此時也許只有部分數據被寫入到磁盤，而另一部分數據卻已經丟失。Redis服務器會在從新啓動時執行一系列必要的一致性檢測，一旦發現相似問題，就會當即退出並給出相應的錯誤提示。此時，咱們就要充分利用Redis工具包中提供的redis-check-aof工具，該工具能夠幫助咱們定位到數據不一致的錯誤，並將已經寫入的部分數據進行回滾。修復以後咱們就能夠再次從新啓動Redis服務器了。

13.WATCH命令和基於CAS的樂觀鎖?

　　　在Redis的事務中，WATCH命令可用於提供CAS(check-and-set)功能。假設咱們經過WATCH命令在事務執行以前監控了多個Keys，假若在WATCH以後有任何Key的值發生了變化，EXEC命令執行的事務都將被放棄，同時返回Null multi-bulk應答以通知調用者事務

　執行失敗。例如，咱們再次假設Redis中並未提供incr命令來完成鍵值的原子性遞增，若是要實現該功能，咱們只能自行編寫相應的代碼。其僞碼以下：
　　val = GET mykey
　　val = val + 1
　　SET mykey $val
　　以上代碼只有在單鏈接的狀況下才能夠保證執行結果是正確的，由於若是在同一時刻有多個客戶端在同時執行該段代碼，那麼就會出現多線程程序中常常出現的一種錯誤場景--競態爭用(race condition)。好比，客戶端A和B都在同一時刻讀取了mykey的原有值，假設該值爲10，此後兩個客戶端又均將該值加一後set回Redis服務器，這樣就會致使mykey的結果爲11，而不是咱們認爲的12。爲了解決相似的問題，咱們須要藉助WATCH命令的幫助，見以下代碼：
　　WATCH mykey
　　val = GET mykey
　　val = val + 1
　　MULTI
　　SET mykey $val
　　EXEC
　　和此前代碼不一樣的是，新代碼在獲取mykey的值以前先經過WATCH命令監控了該鍵，此後又將set命令包圍在事務中，這樣就能夠有效的保證每一個鏈接在執行EXEC以前，若是當前鏈接獲取的mykey的值被其它鏈接的客戶端修改，那麼當前鏈接的EXEC命令將執行失敗。這樣調用者在判斷返回值後就能夠獲悉val是否被從新設置成功。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18.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，子進程建立後，父子進程共享數據段，父進程繼續提供讀寫服務，寫髒的頁面數據會逐漸和子進程分離開來。

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

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

20.Redis的同步機制瞭解麼？

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

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

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

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

參考博客:http://www.javashuo.com/article/p-fdjcekgu-dk.html

　　　　http://www.javashuo.com/article/p-delepozx-du.html