# 使用場景 ### 1、數據緩存（最常用） string，hash類型 比如session共享，頁面數據緩存 ### 2、消息隊列 list 類型。 隊列：排序、秒殺、搶購，叫號等。 ### 3、集合 set：求交集等運算。比如共同好友。 ### 4、有序集合 zset：排行榜，帶權重的消息隊列。 # 常見問題 ## 1、緩存雪崩、穿透、擊穿問題及解決方案 緩存雪崩（大面積過期） 描述：大面積的key過期。造成服務器崩潰。 解決方案： 1、設置常用key永不過期， 2.過期時間錯開，過期時間使用隨機生成，并且熱點數據的過期時間設置的長一點，非熱點數據可以設置短一點 3.多緩存結合，例如：請求進入，可以現請求redis，當redis中不存在的時候再去請求memcache，如果都沒有再去請求db 緩存穿透（找不到key攻擊） 描述： 當用戶查詢的key在redis中不存在，對應的數據在數據庫也不存在，此時被非法用戶進行攻擊，大量的請求會直接打在db上，造成宕機，從而影響整個系統，這種現象稱之為緩存穿透 解決方案： 1、緩存空值、 2、布隆過濾器 緩存擊穿 描述：緩存過期了，大量請求并發，同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大，造成過大壓力 解決方案 1、設置熱點數據永遠不過期。 2、加互斥鎖 ## 2、如何避免多個相同key，系統：key,模塊：key。 ~~~ 1、不同系統可以用sys_name:key_name 如 douyon_sys:douyin_key 2、同系統key:id 如shop:1 3、redis鎖，產生uuid,或者key，單線程 ~~~ ## 3、redis如何做內存優化 存儲盡量使用hash存儲占用內存少。 ## 4、如何實現消息隊列list push,pop,沒有消息時休眠，blpop可以不休眠，阻塞，直到消息到來，1-1消費，1：n sub/pub 發布訂閱，消息丟失，高版本確認機制，rabbitmq等 延時隊列，zset,zadd 時間戳做score,內容做key,zrangebyscore獲取n秒前的數據輪詢處理。zrem剔除過期的數據 ## 5、為什么使用redis （一）性能 我們在碰到需要執行耗時特別久，且結果不頻繁變動的SQL，就特別適合將運行結果放入緩存。這樣，后面的請求就去緩存中讀取，使得請求能夠迅速響應。 （二）并發 在大并發的情況下，所有的請求直接訪問數據庫，數據庫會出現連接異常。這個時候，就需要使用redis做一個緩沖操作，讓請求先訪問到redis，而不是直接訪問數據庫。 ## 6、使用redis有什么缺點 (一)緩存和數據庫雙寫一致性問題 (二)緩存雪崩問題 (三)緩存擊穿問題 (四)緩存穿透問題 (五)緩存的并發競爭問題 ## 7、單線程的redis為什么這么快 (一)純內存操作 (二)單線程操作，避免了頻繁的上下文切換 (三)采用了非阻塞I/O多路復用機制 簡單來說，就是。我們的redis-client在操作的時候，會產生具有不同事件類型的socket。在服務端，有一段I/0多路復用程序，將其置入隊列之中。然后，文件事件分派器，依次去隊列中取，轉發到不同的事件處理器中。 ## 8、redis的數據類型，以及每種數據類型的使用場景 回答：一共五種 (一)String 最常規的set/get操作，value可以是String也可以是數字。一般做一些復雜的計數功能的緩存。 (二)hash 這里value存放的是結構化的對象，比較方便的就是操作其中的某個字段。博主在做單點登錄的時候，就是用這種數據結構存儲用戶信息，以cookieId作為key，設置30分鐘為緩存過期時間，能很好的模擬出類似session的效果。 (三)list 使用List的數據結構，可以做簡單的消息隊列的功能。另外還有一個就是，可以利用lrange命令，做基于redis的分頁功能，性能極佳，用戶體驗好。還用一個場景，就也是個生產者和消費者的場景。LIST可以很好的完成排隊，先進先出的原則。 (四)set 因為set堆放的是一堆不重復值的集合。所以可以做全局去重的功能。另外，就是利用交集、并集、差集等操作，可以計算共同喜好，全部的喜好，自己獨有的喜好等功能，共同好友 (五)sorted set sortedset多了一個權重參數score,集合中的元素能夠按score進行排列。可以做排行榜應用。 ## 9、redis的過期策略以及內存淘汰機制 redis采用的是定期刪除+惰性刪除策略。 為什么不用定時刪除策略? ????定時刪除,用一個定時器來負責監視key,過期則自動刪除。雖然內存及時釋放，但是十分消耗CPU資源。在大并發請求下，CPU要將時間應用在處理請求，而不是刪除key,因此沒有采用這一策略. 定期刪除+惰性刪除是如何工作的呢? ????定期刪除，redis默認每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。因此，如果只采用定期刪除策略，會導致很多key到時間沒有刪除。 ????于是，惰性刪除派上用場。也就是說在你獲取某個key的時候，redis會檢查一下，這個key如果設置了過期時間那么是否過期了？如果過期了此時就會刪除。 采用定期刪除+惰性刪除就沒其他問題了么? ????不是的，如果定期刪除沒刪除key。然后你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的內存會越來越高。那么就應該采用內存淘汰機制。在redis.conf中有一行配置# maxmemory-policy volatile-lru該配置就是配內存淘汰策略的 1）noeviction：當內存不足以容納新寫入數據時，新寫入操作會報錯。應該沒人用吧。 2）allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的key。推薦使用，目前項目在用這種。 3）allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個key。應該也沒人用吧，你不刪最少使用Key,去隨機刪。 4）volatile-lru：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，移除最近最少使用的key。這種情況一般是把redis既當緩存，又做持久化存儲的時候才用。不推薦 5）volatile-random：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，隨機移除某個key。依然不推薦 6）volatile-ttl：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，有更早過期時間的key優先移除。不推薦 ps：如果沒有設置 expire 的key, 不滿足先決條件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行為, 和 noeviction(不刪除) 基本上一致。 ## 10、redis和數據庫雙寫一致性問題 ????分析:一致性問題是分布式常見問題，還可以再分為最終一致性和強一致性。數據庫和緩存雙寫，就必然會存在不一致的問題。答這個問題，先明白一個前提。就是如果對數據有強一致性要求，不能放緩存。我們所做的一切，只能保證最終一致性。另外，我們所做的方案其實從根本上來說，只能說降低不一致發生的概率，無法完全避免。因此，有強一致性要求的數據，不能放緩存。 ????首先，采取正確更新策略，先更新數據庫，再刪緩存。其次，因為可能存在刪除緩存失敗的問題，提供一個補償措施即可，例如利用消息隊列。 ## 11、如何應對緩存穿透和緩存雪崩問題 ????分析:這兩個問題，說句實在話，一般中小型傳統軟件企業，很難碰到這個問題。如果有大并發的項目，流量有幾百萬左右。這兩個問題一定要深刻考慮。回答:如下所示 緩存穿透，即黑客故意去請求緩存中不存在的數據，導致所有的請求都懟到數據庫上，從而數據庫連接異常。 解決方案: (一)利用互斥鎖，緩存失效的時候，先去獲得鎖，得到鎖了，再去請求數據庫。沒得到鎖，則休眠一段時間重試 (二)采用異步更新策略，無論key是否取到值，都直接返回。value值中維護一個緩存失效時間，緩存如果過期，異步起一個線程去讀數據庫，更新緩存。需要做緩存預熱(項目啟動前，先加載緩存)操作。 (三)提供一個能迅速判斷請求是否有效的攔截機制，比如，利用布隆過濾器，內部維護一系列合法有效的key。迅速判斷出，請求所攜帶的Key是否合法有效。如果不合法，則直接返回。 緩存雪崩，即緩存同一時間大面積的失效，這個時候又來了一波請求，結果請求都懟到數據庫上，從而導致數據庫連接異常。 解決方案: (一)給緩存的失效時間，加上一個隨機值，避免集體失效。 (二)熱key長期有效 (三)雙緩存。redis,memcache互用，兩個緩存，緩存A和緩存B。緩存A的失效時間為20分鐘，緩存B設置30 分，A找不到去B。 ## 12、如何解決redis的并發競爭key問題 ????分析:這個問題大致就是，同時有多個子系統去set一個key。這個時候要注意什么呢？大家思考過么。需要說明一下，博主提前百度了一下，發現答案基本都是推薦用redis事務機制。博主不推薦使用redis的事務機制。因為我們的生產環境，基本都是redis集群環境，做了數據分片操作。你一個事務中有涉及到多個key操作的時候，這多個key不一定都存儲在同一個redis-server上。因此，redis的事務機制，十分雞肋。回答:如下所示 (1)如果對這個key操作，不要求順序 這種情況下，準備一個分布式鎖，大家去搶鎖，搶到鎖就做set操作即可，比較簡單。 (2)如果對這個key操作，要求順序 假設有一個key1,系統A需要將key1設置為valueA,系統B需要將key1設置為valueB,系統C需要將key1設置為valueC. 期望按照key1的value值按照 valueA–>valueB–>valueC的順序變化。這種時候我們在數據寫入數據庫的時候，需要保存一個時間戳。假設時間戳如下 系統A key 1 {valueA 3:00} 系統B key 1 {valueB 3:05} 系統C key 1 {valueC 3:10} 那么，假設這會系統B先搶到鎖，將key1設置為{valueB 3:05}。接下來系統A搶到鎖，發現自己的valueA的時間戳早于緩存中的時間戳，那就不做set操作了。以此類推。 其他方法，比如利用隊列，將set方法變成串行訪問也可以。總之，靈活變通。 ## 13.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適合的場景主要局限在較小數據量的高性能操作和運算上。 ## 14.使用redis有哪些好處？ (1)速度快，因為數據存在內存中，類似于HashMap，HashMap的優勢就是查找和操作的時間復雜度都是O(1) (2)支持豐富數據類型，支持string，list，set，sorted set，hash (3)支持事務，操作都是原子性，所謂的原子性就是對數據的更改要么全部執行，要么全部不執行 (4)豐富的特性：可用于緩存，消息，按key設置過期時間，過期后將會自動刪除 ## 15.redis相比memcached有哪些優勢？ (1) memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富的數據類型 (2) redis的速度比memcached快很多 (3) redis可以持久化其數據 ## 16.Memcache與Redis的區別都有哪些？ (1) 存儲方式 Memecache把數據全部存在內存之中，斷電后會掛掉，數據不能超過內存大小。Redis有部份存在硬盤上，這樣能保證數據的持久性。 (2 )數據支持類型Memcache對數據類型支持相對簡單。Redis有復雜的數據類型。 (3) 使用底層模型不同它們之間底層實現方式以及與客戶端之間通信的應用協議不一樣。Redis直接自己構建了VM機制，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求。 ## 17.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最好在同一個局域網內 ## 18、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（驅逐）：禁止驅逐數據（報錯） ## 19.redis事物的了解CAS(check-and-set 操作實現樂觀鎖 )? 和眾多其它數據庫一樣，Redis作為NoSQL數據庫也同樣提供了事務機制。在Redis中，MULTI/EXEC/DISCARD/WATCH這四個命令是我們實現事務的基石。相信對有關系型數據庫開發經驗的開發者而言這一概念并不陌生，即便如此，我們還是會簡要的列出Redis中事務的實現特征： 1). 在事務中的所有命令都將會被串行化的順序執行，事務執行期間，Redis不會再為其它客戶端的請求提供任何服務，從而保證了事物中的所有命令被原子的執行。 2). 和關系型數據庫中的事務相比，在Redis事務中如果有某一條命令執行失敗，其后的命令仍然會被繼續執行。 3). 我們可以通過MULTI命令開啟一個事務，有關系型數據庫開發經驗的人可以將其理解為"BEGINTRANSACTION"語句。在該語句之后執行的命令都將被視為事務之內的操作，最后我們可以通過執行EXEC/DISCARD命令來提交/回滾該事務內的所有操作。這兩個Redis命令可被視為等同于關系型數據庫中的COMMIT/ROLLBACK語句。 4). 在事務開啟之前，如果客戶端與服務器之間出現通訊故障并導致網絡斷開，其后所有待執行的語句都將不會被服務器執行。然而如果網絡中斷事件是發生在客戶端執行EXEC命令之后，那么該事務中的所有命令都會被服務器執行。 5). 當使用Append-Only模式時，Redis會通過調用系統函數write將該事務內的所有寫操作在本次調用中全部寫入磁盤。然而如果在寫入的過程中出現系統崩潰，如電源故障導致的宕機，那么此時也許只有部分數據被寫入到磁盤，而另外一部分數據卻已經丟失。 Redis服務器會在重新啟動時執行一系列必要的一致性檢測，一旦發現類似問題，就會立即退出并給出相應的錯誤提示。此時，我們就要充分利用Redis工具包中提供的redis-check-aof工具，該工具可以幫助我們定位到數據不一致的錯誤，并將已經寫入的部分數據進行回滾。修復之后我們就可以再次重新啟動Redis服務器了。 ## 20.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是否被重新設置成功。 ## 21.redis持久化的幾種方式 1、快照（snapshots） 缺省情況情況下，Redis把數據快照存放在磁盤上的二進制文件中，文件名為dump.rdb。你可以配置Redis的持久化策略，例如數據集中每N秒鐘有超過M次更新，就將數據寫入磁盤；或者你可以手工調用命令SAVE或BGSAVE。 工作原理 ． Redis forks. ． 子進程開始將數據寫到臨時RDB文件中。 ． 當子進程完成寫RDB文件，用新文件替換老文件。 ． 這種方式可以使Redis使用copy-on-write技術。 2、AOF 快照模式并不十分健壯，當系統停止，或者無意中Redis被kill掉，最后寫入Redis的數據就會丟失。這對某些應用也許不是大問題，但對于要求高可靠性的應用來說，Redis就不是一個合適的選擇。Append-only文件模式是另一種選擇。你可以在配置文件中打開AOF模式 3、虛擬內存方式 當你的key很小而value很大時,使用VM的效果會比較好.因為這樣節約的內存比較大. 當你的key不小時,可以考慮使用一些非常方法將很大的key變成很大的value,比如你可以考慮將key,value組合成一個新的value. vm-max-threads這個參數,可以設置訪問swap文件的線程數,設置最好不要超過機器的核數,如果設置為0,那么所有對swap文件的操作都是串行的.可能會造成比較長時間的延遲,但是對數據完整性有很好的保證. 自己測試的時候發現用虛擬內存性能也不錯。如果數據量很大，可以考慮分布式或者其他數據庫 ## 22.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進行淘汰 ## 23.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 （5）發布/訂閱 最后（但肯定不是最不重要的）是Redis的發布/訂閱功能。發布/訂閱的使用場景確實非常多。我已看見人們在社交網絡連接中使用，還可作為基于發布/訂閱的腳本觸發器，甚至用Redis的發布/訂閱功能來建立聊天系統！ Redis提供的所有特性中，我感覺這個是喜歡的人最少的一個，雖然它為用戶提供如果此多功能。 ## 24.讀寫分離模型 通過增加Slave DB的數量，讀的性能可以線性增長。為了避免Master DB的單點故障，集群一般都會采用兩臺MasterDB做雙機熱備，所以整個集群的讀和寫的可用性都非常高。 讀寫分離架構的缺陷在于，不管是Master(主)還是Slave（從），每個節點都必須保存完整的數據，如果在數據量很大的情況下，集群的擴展能力還是受限于單個節點的存儲能力，而且對于Write-intensive類型的應用，讀寫分離架構并不適合。 ## 25.數據分片模型 為了解決讀寫分離模型的缺陷，可以將數據分片模型應用進來。 可以將每個節點看成都是獨立的master，然后通過業務實現數據分片。 結合上面兩種模型，可以將每個master設計成由一個master和多個slave組成的模型。 ## 26.使用過Redis分布式鎖么，它是什么回事？ 先拿setnx來爭搶鎖，搶到之后，再用expire給鎖加一個過期時間防止鎖忘記了釋放。 ## 27.如果這個redis正在給線上的業務提供服務，那使用keys指令會有什么問題？ 這個時候你要回答redis關鍵的一個特性：redis的單線程的。keys指令會導致線程阻塞一段時間，線上服務會停頓，直到指令執行完畢，服務才能恢復。這個時候可以使用scan指令，scan指令可以無阻塞的提取出指定模式的key列表，但是會有一定的重復概率，在客戶端做一次去重就可以了，但是整體所花費的時間會比直接用keys指令長。 ## 28.使用過Redis做異步隊列么，你是怎么用的？ 一般使用list結構作為隊列，rpush生產消息，lpop消費消息。當lpop沒有消息的時候，要適當sleep一會再重試。 如果對方追問可不可以不用sleep呢？list還有個指令叫blpop，在沒有消息的時候，它會阻塞住直到消息到來。 如果對方追問能不能生產一次消費多次呢？使用pub/sub主題訂閱者模式，可以實現1:N的消息隊列。 如果對方追問pub/sub有什么缺點？在消費者下線的情況下，生產的消息會丟失，得使用專業的消息隊列如rabbitmq等。 如果對方追問redis如何實現延時隊列？我估計現在你很想把面試官一棒打死如果你手上有一根棒球棍的話，怎么問的這么詳細。但是你很克制，然后神態自若的回答道：使用sortedset，拿時間戳作為score，消息內容作為key調用zadd來生產消息，消費者用zrangebyscore指令獲取N秒之前的數據輪詢進行處理。 ## 29.如果有大量的key需要設置同一時間過期，一般需要注意什么？ 如果大量的key過期時間設置的過于集中，到過期的那個時間點，redis可能會出現短暫的卡頓現象。一般需要在時間上加一個隨機值，使得過期時間分散一些。(分散過期時間) ## 30.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，子進程創建后，父子進程共享數據段，父進程繼續提供讀寫服務，寫臟的頁面數據會逐漸和子進程分離開來。 ## 31.Pipeline有什么好處，為什么要用pipeline？ 可以將多次IO往返的時間縮減為一次，前提是pipeline執行的指令之間沒有因果相關性。使用redis-benchmark進行壓測的時候可以發現影響redis的QPS峰值的一個重要因素是pipeline批次指令的數目。 附: 但是注意，如果使用Pipeline。當節點個數擴充后，會導致長連接數目成倍數上漲。 ## 32.Redis的同步機制了解么？ Redis可以使用主從同步，從從同步。第一次同步時，主節點做一次bgsave，并同時將后續修改操作記錄到內存buffer，待完成后將rdb文件全量同步到復制節點，復制節點接受完成后將rdb鏡像加載到內存。加載完成后，再通知主節點將期間修改的操作記錄同步到復制節點進行重放就完成了同步過程。 ## 33.是否使用過Redis集群，集群的原理是什么？ Redis Sentinal著眼于高可用，在master宕機時會自動將slave提升為master，繼續提供服務。（哨兵） Redis Cluster著眼于擴展性，在單個redis內存不足時，使用Cluster進行分片存儲。（集群）