常見問題：

1、為什麼使用redis

• （一）效能
  • 我們在碰到需要執行耗時特別久，且結果不頻繁變動的SQL，就特別適合將執行結果放入快取。這樣，後面的請求就去快取中讀取，使得請求能夠迅速響應。
• （二）併發
  • 在大併發的情況下，所有的請求直接訪問資料庫，資料庫會出現連線異常。這個時候，就需要使用redis做一個緩衝操作，讓請求先訪問到redis，而不是直接訪問資料庫。

2.使用redis有什麼缺點

• (一)快取和資料庫雙寫一致性問題
• (二)快取雪崩問題
• (三)快取擊穿問題
• (四)快取的併發競爭問題

3、單執行緒的redis為什麼這麼快

• (一)純記憶體操作
• (二)單執行緒操作，避免了頻繁的上下文切換
• (三)採用了非阻塞I/O多路複用機制

    參照上圖，簡單來說，就是。我們的redis-client在操作的時候，會產生具有不同事件型別的socket。在服務端，有一段I/0多路複用程式，將其置入佇列之中。然後，檔案事件分派器，依次去佇列中取，轉發到不同的事件處理器中。

4、redis的資料型別，以及每種資料型別的使用場景

• 回答：一共五種
• (一)String
  • 這個其實沒啥好說的，最常規的set/get操作，value可以是String也可以是數字。一般做一些複雜的計數功能的快取。
• (二)hash
  • 這裡value存放的是結構化的物件，比較方便的就是操作其中的某個欄位。博主在做單點登入的時候，就是用這種資料結構儲存使用者資訊，以cookieId作為key，設定30分鐘為快取過期時間，能很好的模擬出類似session的效果。
• (三)list
  • 使用List的資料結構，可以做簡單的訊息佇列的功能。另外還有一個就是，可以利用lrange命令，做基於redis的分頁功能，效能極佳，使用者體驗好。本人還用一個場景，很合適—取行情資訊。就也是個生產者和消費者的場景。LIST可以很好的完成排隊，先進先出的原則。
• (四)set
  • 因為set堆放的是一堆不重複值的集合。所以可以做全域性去重的功能。為什麼不用JVM自帶的Set進行去重？因為我們的系統一般都是叢集部署，使用JVM自帶的Set，比較麻煩，難道為了一個做一個全域性去重，再起一個公共服務，太麻煩了。
  • 另外，就是利用交集、並集、差集等操作，可以計算共同喜好，全部的喜好，自己獨有的喜好等功能。
• (五)sorted set
  • sortedset多了一個權重引數score,集合中的元素能夠按score進行排列。可以做排行榜應用，取TOP N操作。

5、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(不刪除) 基本上一致。

6、redis和資料庫雙寫一致性問題

    分析:一致性問題是分散式常見問題，還可以再分為最終一致性和強一致性。資料庫和快取雙寫，就必然會存在不一致的問題。答這個問題，先明白一個前提。就是如果對資料有強一致性要求，不能放快取。我們所做的一切，只能保證最終一致性。另外，我們所做的方案其實從根本上來說，只能說降低不一致發生的概率，無法完全避免。因此，有強一致性要求的資料，不能放快取。

    首先，採取正確更新策略，先更新資料庫，再刪快取。其次，因為可能存在刪除快取失敗的問題，提供一個補償措施即可，例如利用訊息佇列。

7、如何應對快取穿透和快取雪崩問題

    分析:這兩個問題，說句實在話，一般中小型傳統軟體企業，很難碰到這個問題。如果有大併發的專案，流量有幾百萬左右。這兩個問題一定要深刻考慮。回答:如下所示

快取穿透，即黑客故意去請求快取中不存在的資料，導致所有的請求都懟到資料庫上，從而資料庫連線異常。

解決方案:

(一)利用互斥鎖，快取失效的時候，先去獲得鎖，得到鎖了，再去請求資料庫。沒得到鎖，則休眠一段時間重試

(二)採用非同步更新策略，無論key是否取到值，都直接返回。value值中維護一個快取失效時間，快取如果過期，非同步起一個執行緒去讀資料庫，更新快取。需要做快取預熱(專案啟動前，先載入快取)操作。

(三)提供一個能迅速判斷請求是否有效的攔截機制，比如，利用布隆過濾器，內部維護一系列合法有效的key。迅速判斷出，請求所攜帶的Key是否合法有效。如果不合法，則直接返回。

快取雪崩，即快取同一時間大面積的失效，這個時候又來了一波請求，結果請求都懟到資料庫上，從而導致資料庫連線異常。

解決方案:

(一)給快取的失效時間，加上一個隨機值，避免集體失效。

(二)使用互斥鎖，但是該方案吞吐量明顯下降了。

(三)雙快取。我們有兩個快取，快取A和快取B。快取A的失效時間為20分鐘，快取B不設失效時間。自己做快取預熱操作。然後細分以下幾個小點

I 從快取A讀資料庫，有則直接返回
II A沒有資料，直接從B讀資料，直接返回，並且非同步啟動一個更新執行緒。
III 更新執行緒同時更新快取A和快取B。

8、如何解決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方法變成序列訪問也可以。總之，靈活變通。

9.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適合的場景主要侷限在較小資料量的高效能操作和運算上。

10.使用redis有哪些好處？

(1)速度快，因為資料存在記憶體中，類似於HashMap，HashMap的優勢就是查詢和操作的時間複雜度都是O(1)

(2)支援豐富資料型別，支援string，list，set，sorted set，hash

(3)支援事務，操作都是原子性，所謂的原子性就是對資料的更改要麼全部執行，要麼全部不執行

(4)豐富的特性：可用於快取，訊息，按key設定過期時間，過期後將會自動刪除

11.redis相比memcached有哪些優勢？

(1) memcached所有的值均是簡單的字串，redis作為其替代者，支援更為豐富的資料型別

(2) redis的速度比memcached快很多

(3) redis可以持久化其資料

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

(1) 儲存方式 Memecache把資料全部存在記憶體之中，斷電後會掛掉，資料不能超過記憶體大小。Redis有部份存在硬碟上，這樣能保證資料的永續性。

(2 )資料支援型別Memcache對資料型別支援相對簡單。Redis有複雜的資料型別。

(3) 使用底層模型不同它們之間底層實現方式以及與客戶端之間通訊的應用協議不一樣。Redis直接自己構建了VM機制，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求。

13.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最好在同一個區域網內

14.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（驅逐）：禁止驅逐資料

15.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伺服器了。

16.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是否被重新設定成功。

17.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檔案的操作都是序列的.可能會造成比較長時間的延遲,但是對資料完整性有很好的保證.
自己測試的時候發現用虛擬記憶體效能也不錯。如果資料量很大，可以考慮分散式或者其他資料庫

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

19.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提供的所有特性中，我感覺這個是喜歡的人最少的一個，雖然它為使用者提供如果此多功能。

20.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適合的場景主要侷限在較小資料量的高效能操作和運算上。

21.讀寫分離模型

通過增加Slave DB的數量，讀的效能可以線性增長。為了避免Master DB的單點故障，叢集一般都會採用兩臺MasterDB做雙機熱備，所以整個叢集的讀和寫的可用性都非常高。

讀寫分離架構的缺陷在於，不管是Master還是Slave，每個節點都必須儲存完整的資料，如果在資料量很大的情況下，叢集的擴充套件能力還是受限於單個節點的儲存能力，而且對於Write-intensive型別的應用，讀寫分離架構並不適合。

22.資料分片模型

為了解決讀寫分離模型的缺陷，可以將資料分片模型應用進來。

可以將每個節點看成都是獨立的master，然後通過業務實現資料分片。

結合上面兩種模型，可以將每個master設計成由一個master和多個slave組成的模型。

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

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

24.如果在setnx之後執行expire之前程序意外crash或者要重啟維護了，那會怎麼樣？

【loading…】

25.如果這個redis正在給線上的業務提供服務，那使用keys指令會有什麼問題？

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

26.使用過Redis做非同步佇列麼，你是怎麼用的？

一般使用list結構作為佇列，rpush生產訊息，lpop消費訊息。當lpop沒有訊息的時候，要適當sleep一會再重試。

如果對方追問可不可以不用sleep呢？list還有個指令叫blpop，在沒有訊息的時候，它會阻塞住直到訊息到來。

如果對方追問能不能生產一次消費多次呢？使用pub/sub主題訂閱者模式，可以實現1:N的訊息佇列。

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

如果對方追問redis如何實現延時佇列？我估計現在你很想把面試官一棒打死如果你手上有一根棒球棍的話，怎麼問的這麼詳細。但是你很剋制，然後神態自若的回答道：使用sortedset，拿時間戳作為score，訊息內容作為key呼叫zadd來生產訊息，消費者用zrangebyscore指令獲取N秒之前的資料輪詢進行處理。

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

27.如果有大量的key需要設定同一時間過期，一般需要注意什麼？

如果大量的key過期時間設定的過於集中，到過期的那個時間點，redis可能會出現短暫的卡頓現象。一般需要在時間上加一個隨機值，使得過期時間分散一些。

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

29.Pipeline有什麼好處，為什麼要用pipeline？

可以將多次IO往返的時間縮減為一次，前提是pipeline執行的指令之間沒有因果相關性。使用redis-benchmark進行壓測的時候可以發現影響redis的QPS峰值的一個重要因素是pipeline批次指令的數目。
附: 但是注意，如果使用Pipeline。當節點個數擴充後，會導致長連線數目成倍數上漲。

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

Redis可以使用主從同步，從從同步。第一次同步時，主節點做一次bgsave，並同時將後續修改操作記錄到記憶體buffer，待完成後將rdb檔案全量同步到複製節點，複製節點接受完成後將rdb映象載入到記憶體。載入完成後，再通知主節點將期間修改的操作記錄同步到複製節點進行重放就完成了同步過程。

31.是否使用過Redis叢集，叢集的原理是什麼？

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

Redis Cluster著眼於擴充套件性，在單個redis記憶體不足時，使用Cluster進行分片儲存。