Redis常見面試題

1. 什麼是redis?

Redis 是一個使用 C 語言寫成的，開源的基於內存的高性能key-value數據庫。 Redis的值能夠是由string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）、Bitmaps（位圖）等多種數據結構組成。

2. Redis的特性

1. 速度快

速度快的緣由：
- Redis全部數據都放在內存中
- Redis是C語言實現
- Redis使用了單線程的架構，預防了多線程可能產生的競爭問題

1. 基於鍵值對的數據結構服務器
   Redis中的值不只能夠是字符串，Redis的值能夠是由string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）、Bitmaps（位圖）等多種數據結構組成，便於許多應用場景的開發而且提升了開發效率。

2. 豐富的共鞥
   • 提供了鍵過時功能，能夠用來實現緩存
   • 提供了發佈/訂閱功能，能夠用來實現消息系統
   • 支持Lua腳本功能，能夠利用Lua創造出新的Redis命令
   • 提供了簡單的事務功能，能在必定程度上保證事務特性
   • 提供了流水線（Pipeline）功能，減小了網絡開銷

3. 簡單穩定

4. 客戶端語言多

5. 持久化
   • RDB（快照）
   • AOF（日誌的形式）
   • 4.0版本開始支持RDB和AOF混用的方式聊進行持久化

6. 主從複製

7. 高可用和分佈式
   • 高可用實現：Redis Sentinel
   • 分佈式實現：Redis cluster

3. Redis和Memcached的區別和優點？　

1. Redis不只僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。memcache支持簡單的數據類型，String。
2. Redis支持數據的備份，即master-slave模式的數據備份。
3. Redis支持數據的持久化，能夠將內存中的數據保持在磁盤中，重啓的時候能夠再次加載進行使用,而Memecache把數據所有存在內存之中
4. redis的速度比memcached快不少
5. Memcached是多線程，非阻塞IO複用的網絡模型；Redis使用單線程的IO複用模型。
   

Redis與Memcached的選擇
終極策略： 使用Redis的String類型作的事，均可以用Memcached替換，以此換取更好的性能提高； 除此之外，優先考慮Redis；

4. Redis常見數據結構使用場景

1. String

經常使用命令: set,get,decr,incr,mget 等。

String數據結構是簡單的key-value類型，value其實不只能夠是String，也能夠是數字。
常規key-value緩存應用；
常規計數：微博數，粉絲數等。

1. Hash

經常使用命令： hget,hset,hgetall 等。

Hash是一個string類型的field和value的映射表，hash特別適合用於存儲對象。 好比咱們能夠Hash數據結構來存儲用戶信息，商品信息等等。

1. List

經常使用命令: lpush,rpush,lpop,rpop,lrange等

list就是鏈表，Redis list的應用場景很是多，也是Redis最重要的數據結構之一，好比微博的關注列表，粉絲列表，最新消息排行等功能均可以用Redis的list結構來實現。
Redis list的實現爲一個雙向鏈表，便可以支持反向查找和遍歷，更方便操做，不過帶來了部分額外的內存開銷。

1. Set

經常使用命令：
sadd,spop,smembers,sunion 等

set對外提供的功能與list相似是一個列表的功能，特殊之處在於set是能夠自動排重的。
當你須要存儲一個列表數據，又不但願出現重複數據時，set是一個很好的選擇，而且set提供了判斷某個成員是否在一個set集合內的重要接口，這個也是list所不能提供的。
在微博應用中，能夠將一個用戶全部的關注人存在一個集合中，將其全部粉絲存在一個集合。Redis能夠很是方便的實現如共同關注、共同喜愛、二度好友等功能。

1. Sorted Set

經常使用命令： zadd,zrange,zrem,zcard等

和set相比，sorted set增長了一個權重參數score，使得集合中的元素可以按score進行有序排列。
舉例： 在直播系統中，實時排行信息包含直播間在線用戶列表，各類禮物排行榜，彈幕消息（能夠理解爲按消息維度的消息排行榜）等信息，適合使用Redis中的SortedSet結構進行存儲。

5. Redis常見性能問題和解決方案： 　　

- Master寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工做，當快照比較大時對性能影響是很是大的，會間斷性暫停服務，因此Master最好不要寫內存快照。

- Master AOF持久化，若是不重寫AOF文件，這個持久化方式對性能的影響是最小的，可是AOF文件會不斷增大，AOF文件過大會影響Master重啓的恢復速度。Master最好不要作任何持久化工做，包括內存快照和AOF日誌文件，特別是不要啓用內存快照作持久化,若是數據比較關鍵，某個Slave開啓AOF備份數據，策略爲每秒同步一次。

- Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會佔大量的CPU和內存資源，致使服務load太高，出現短暫服務暫停現象。

- Redis主從複製的性能問題，爲了主從複製的速度和鏈接的穩定性，Slave和Master最好在同一個局域網內

## 6. MySQL裏有2000w數據，redis中只存20w的數據，如何保證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（驅逐）：禁止驅逐數據

7. 請用Redis和任意語言實現一段惡意登陸保護的代碼，限制1小時內每用戶Id最多隻能登陸5次。具體登陸函數或功能用空函數便可，不用詳細寫出。

用列表實現：列表中每一個元素表明登錄時間,只要最後的第5次登錄時間和如今時間差不超過1小時就禁止登錄.
用Python寫的代碼以下：

#!/usr/bin/env python3
import redis  
import sys  
import time  
 
r = redis.StrictRedis(host=’127.0.0.1′, port=6379, db=0)  
try:       
    id = sys.argv[1]
except:      
    print(‘input argument error’)    
    sys.exit(0)  
if r.llen(id) >= 5 and time.time() – float(r.lindex(id, 4)) <= 3600:      
    print(「you are forbidden logining」)
else:       
    print(‘you are allowed to login’)    
    r.lpush(id, time.time())    
    # login_func()

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

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

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

　　10.Redis是單進程單線程的

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

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

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

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

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

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

　　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持久化的幾種方式

一、快照（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文件的操做都是串行的.可能會形成比較長時間的延遲,可是對數據完整性有很好的保證.

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

　　15.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進行淘汰

　　16.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的發佈/訂閱功能來創建聊天系統！（不，這是真的，你能夠去核

　　實）。
　　Redis提供的全部特性中，我感受這個是喜歡的人最少的一個，雖然它爲用戶提供若是此多功能。

參考資源：

（1） http://www.javashuo.com/article/p-aewzwjox-ca.html
（2）http://www.javashuo.com/article/p-fhlpnoey-cm.html