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的釋出/訂閱功能。釋出/訂閱的使用場景确實非常多。
7、redis的緩存失效政策和主鍵失效機制
作為緩存系統都要定期清理無效資料，就需要一個主鍵失效和淘汰政策.
在Redis當中，有生存期的key被稱為volatile。在建立緩存時，要為給定的key設定生存期，當key過期的時候（生存期為0），它可能會被删除。
1、影響生存時間的一些操作
生存時間可以通過使用 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 。
2、如何更新生存時間
可以對一個已經帶有生存時間的 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永不回收的政策。
使用政策規則：
1、如果資料呈現幂律分布，也就是一部分資料通路頻率高，一部分資料通路頻率低，則使用allkeys-lru
2、如果資料呈現平等分布，也就是所有的資料通路頻率都相同，則使用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指令，但是需要注意一些問題。
11、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
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進行分片存儲。
更多參閱
Redis資料庫幫助文檔![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)