Redis常見問題彙總

1、什麼是Redis？

Redis是一個開源、高性能、基于鍵值對的緩存與存儲系統。           

2、Redis相比memcached有哪些優勢？

劣勢：Redis是單線程，Memcached是多線程，在多核伺服器上後者的性能理論上會更高一些。
優勢：随着Redis3.0的推出，标志着memcache的所有功能都已經成了Redis的子集。同時Redis對叢集的支援使得Memcache原有的第三方叢集工具不再成為優勢。是以，在新項目中使用Redis替代Memcache将會是非常好的選擇。           

3、Redis支援哪幾種資料類型？适合存儲的資料類型？使用場景【5種 】

（1）字元串類型（Key-Value 使用最多的類型
（2）散列類型（Hash）适合存儲對象
（3）清單類型（List）
（4）集合類型（Set）
（5）有序集合類型（Zset）           

4、Redis主要消耗什麼實體資源？

記憶體           

5、Redis的全稱是什麼？

Remote Dictionary Server（遠端資料服務）           

6、Redis有哪幾種資料淘汰政策？

共六種資料淘汰政策。（分三類）
一、從已設定過期的資料集
1、volatile-lru：從已設定過期時間的資料集中，選擇最近最少使用的資料淘汰
2、volatile-ttl：從已設定過期時間的資料集中，選擇将要過期的資料淘汰
3、volatile-random：從已設定過期時間的資料集中，任意選擇資料淘汰
二、從整體資料集
4、allkeys-lru：從全資料集中，選擇最近最少使用的資料淘汰
5、allkeys-random：從全資料集中任意選擇資料淘汰
三、驅逐（預設政策-直接傳回錯誤）
6、noenviction（驅逐）：不删除任意資料(但redis還會根據引用計數器進行釋放),這時如果記憶體不夠時，會直接傳回錯誤           

7、Redis官方為什麼不提供Windows版本？

目前Linux版本已經相當穩定，使用者量很大，無需開發windows版本，反而會帶來相容性等問題。           

8、字元串類型存儲的最大容量？

512M。           

9、為什麼Redis需要把所有資料放到記憶體中？

記憶體存取遠比磁盤IO快得多。           

10、Redis叢集方案應該怎麼做？都有哪些方案？

1、Twemproxy，推特的開源方案。它會以一個代理的身份接收請求并使用一緻性hash算法，将請求轉接到具體redis，将結果再傳回twemproxy。 問題：redis節點數量改變時候，資料無法自動移動到新的節點。
2、Codis，豌豆莢的開源方案。目前使用最多的叢集方案，基本和twemproxy一緻的效果，它支援在 節點數量改變情況下，舊節點資料可恢複到新hash節點。
3、Redis cluster3.0自帶的叢集，特點：他的分布式算法不是一緻性hash，而是hash槽，以及自身支援節點設定從節點。
4、業務代碼層實作，在代碼層，對key 進行hash計算，然後去對應的redis執行個體操作資料。 這種方式對hash層代碼要求比較高，需要重點考慮的是，節點失效後的替代算法方案，資料震蕩後的自動腳本恢複，執行個體的監控，等等。           

11、Redis叢集方案什麼情況下會導緻整個叢集不可用？

有A，B，C三個節點的叢集,在沒有複制模型的情況下,如果節點B失敗了，那麼整個叢集就會因為缺少5501-11000這個範圍的槽而不可用。資料丢失           

12、有2000w資料，Redis隻存20w，如何保證Redis中都是熱點資料？

先計算下這20W條資料占用的記憶體，設定最大可用記憶體，當記憶體中的資料集達到上限時，redis就會啟動LRU(資料淘汰政策)。           

13、Redis應用場景？

1、會話緩存（Session Cache）
    例如：分布式登入資訊，購物車資訊，能提供持久化。
2、全頁緩存（FPC）
    除基本的會話token之外，Redis還提供很簡便的FPC平台。即使重新開機了Redis執行個體，因為有磁盤的持久化，使用者也不會看到頁面加載速度的下降
3、隊列
    由于支援 list 和 set 操作，這使得Redis能作為一個很好的消息隊列平台來使用
4、排行榜/計數器
    incr  range
5、釋出/訂閱           

14、Redis支援的Java用戶端都有哪些？官方推薦用哪個？

Redisson、Jedis等等，官方推薦使用Redisson。           

15、Redis和Redisson有什麼關系？

Redisson  是一個進階的、分布式協調Redis用戶端。           

16、Jedis與Redisson對比有什麼優缺點？

1、Jedis是Redis的Java實作的用戶端，其API提供了比較全面的Redis指令的支援；
2、Redisson實作了分布式和可擴充的Java資料結構，和Jedis相比，功能較為簡單，不支援字元串操作，不支援排序、事務、管道、分區等Redis特性。
3、Redisson的宗旨是促進使用者對Redis的關注分離，進而讓使用者能夠将精力更集中地放在處理業務邏輯上。           

17、Redis如何設定密碼及驗證密碼？

設定密碼：兩種方式
        需重新開機redis:打開redis.conf中的  requirepass foobared
        不重新開機redis: config set requirepass 123456
驗證密碼：兩種方式
        方式一、登入的時候驗證 例如：redis-cli  -h 127.0.0.1 -p 6379 -a cfadata@2016
        方式二、登入時不指定密碼，而在執行操作前進行認證。使用auth 指令認證。           

18、Redis哈希槽？

1、Redis 叢集中内置了 16384 個哈希槽。
2、需要在 Redis 叢集中存一個 key-value時，Redis 先對 key 使用 crc16 算法算出一個結果。
3、然後把結果對 16384 取模，這樣每個 key 都會對應一個編号在 0-16383 之間的哈希槽。
4、Redis 會根據節點數量大緻均等的将哈希槽映射到不同的節點。           

19、Redis叢集的主從複制模型？

為了使在部分節點失敗或者大部分節點無法通信的情況下叢集仍然可用，是以叢集使用了主從複制模型,每個節點都會有N-1個複制品           

20、Redis叢集會有寫操作丢失嗎？

Redis并不能保證資料的強一緻性，這意味這在實際中叢集在特定的條件下(使用的記憶體超過了最大可用記憶體（資料淘汰政策是noenviction（驅逐）的時候）)可能會丢失寫操作。           

21、Redis叢集之間是如何複制的？

異步複制
初始化複制：
1、從資料庫啟動後，會向主資料庫發送SYNC指令。
2、主資料庫收到SYNC後會在背景儲存快照（RDB持久化過程），并将儲存快照期間接收到的指令緩存起來。
3、快照完成後，Redis會将快照檔案和所有緩存的指令發送給從資料庫。
4、從資料庫收到快照後會載入快照檔案并執行緩存指令。
運作中複制：
當主資料庫每當收到寫指令，就會将指令同步到從資料庫。
斷線重連機制：
redis2.6之前，斷線重連後會進行全部複制（主資料庫的RDB檔案發給從資料庫）
redis2.8之後，斷線重連後進行的是增量複制。           

22、Redis叢集最大節點個數是多少？

16384個，但是建議最多有1000個節點。           

23、Redis叢集如何選擇資料庫？

預設在0号資料庫。           

24、怎麼測試Redis的連通性？

ping指令測試用戶端與redis服務連接配接是否正常，傳回pong正常。           

25、Redis中的管道有什麼用?

可以在服務端未響應時，用戶端可以繼續向服務端發送請求，并最終一次性讀取所有服務端的響應。           

26、Redis事務？

1、提供了指令打包，順序執行的機制。
2、指令入隊，先進先出。
3、帶 WATCH 指令的事務，當鍵對應的值被修改時，事務直接傳回失敗，否則成功。
4、保證了一緻性和隔離性，不保證原子性和持久性（Redis的事務不是一個完整的事務）。
參考： 深入了解Redis事務           

27、Redis事務相關指令?

1、MULTI （開啟事務）
 2、DISCARD （取消事務，如果正在使用 WATCH 指令監視某個(或某些) key，那麼取消所有監視，等同于執行指令 UNWATCH）
 3、EXEC （執行事務）
 4、WATCH （監視一個(或多個) key ，如果在事務執行之前這個(或這些) key 被其他指令所改動，那麼事務将被打斷）           

28、Redis key的過期時間和永久有效分别怎麼設定？

1、過期時間：set key timeout value
2、永久有效：預設不設定過期時間（set key value）永久有效,但是如果實際使用記憶體超過你設定的最大記憶體，并且設定了資料淘汰政策，就會使用LRU删除機制           

29、Redis如何做記憶體優化？

應使用散清單（HashSst），适合存儲對象類型。盡可能的将資料模型抽象到一個散清單裡面。比如：使用者對象，不要為這個使用者的名稱，姓氏，郵箱，密碼設定單獨的key,而是應該把這個使用者的所有資訊存儲到一張散清單裡面。           

30、Redis回收程序如何工作的？

1、用戶端接收到資料寫入請求後，Redis檢查記憶體使用情況，如果大于maxmemory的限制, 則根據設定好的政策進行回收。一個新的指令被執行。
2、是以我們不斷地穿越記憶體限制的邊界，通過不斷達到邊界然後不斷地回收回到邊界以下。           

31、Redis回收使用的算法？

LRU算法。           

32、Redis如何做大量資料插入？

Redis2.6開始redis-cli支援一種新的被稱之為pipe mode的新模式用于執行大量資料插入。           

33、為什麼要做Redis分區？

分區使得我們本來受限于單台計算機硬體資源的問題不再是問題，存儲不夠，計算資源不夠，帶寬不夠，我們都可以通過增加機器來解決這些問題。           

34、Redis的分區實作方案？

1、用戶端分區：就是在用戶端就已經決定資料會被存儲到哪個redis節點或者從哪個redis節點讀取。大多數用戶端已經實作了用戶端分區。
2、代理分區 ：意味着用戶端将請求發送給代理，然後代理決定去哪個節點寫資料或者讀資料。代理根據分區規則決定請求哪些Redis執行個體，然後根據Redis的響應結果傳回給用戶端。redis和memcached的一種代理實作就是Twemproxy
3、查詢路由(Query routing) ：意思是用戶端随機地請求任意一個redis執行個體，然後由Redis将請求轉發給正确的Redis節點。Redis Cluster實作了一種混合形式的查詢路由，但并不是直接将請求從一個redis節點轉發到另一個redis節點，而是在用戶端的幫助下直接redirected到正确的redis節點。           

35、Redis分區有什麼缺點？

1、多鍵操作是不被支援的，比如我們将要批量操作的鍵被映射到了不同的Redis執行個體中。
2、多鍵的Redis事務是不被支援的。
3、分區的最小粒度是鍵，是以我們不能将關聯到一個鍵的很大的資料集映射到不同的執行個體。
4、當應用分區的時候，資料的處理是非常複雜的，比如我們需要處理多個rdb/aof檔案，将分布在不同執行個體的檔案聚集到一起備份。
5、添加和删除機器是很複雜的，例如Redis叢集支援幾乎運作時透明的因為增加或減少機器而需要做的rebalancing,然而像用戶端和代理分區這種方式是不支援這種功能的。           

36、Redis持久化和緩存怎麼做擴容？

1、如果Redis被當做緩存使用，使用一緻性哈希實作動态擴容縮容。
2、如果Redis被當做一個持久化存儲使用，必須使用固定的keys-to-nodes映射關系，節點的數量一旦确定不能變化。否則的話(即Redis節點需要動态變化的情況），必須使用可以在運作時進行資料再平衡的一套系統，而目前隻有Redis叢集可以做到這樣。           

37、分布式Redis是前期做還是規模上來了再做好？為什麼？

1、一開始就做分區，遷移redis執行個體不用考慮分區
2、既然Redis是如此的輕量（單執行個體隻使用1M記憶體）,為防止以後的擴容，最好的辦法就是一開始就啟動較多執行個體。即便你隻有一台伺服器，你也可以一開始就讓Redis以分布式的方式運作，使用分區，在同一台伺服器上啟動多個執行個體。
這樣的話，當你的資料不斷增長，需要更多的Redis伺服器時，你需要做的就是僅僅将Redis執行個體從一台服務遷移到另外一台伺服器而已（而不用考慮重新分區的問題）。一旦你添加了另一台伺服器，你需要将你一半的Redis執行個體從第一台機器遷移到第二台機器。           

38、Twemproxy是什麼？

Twemproxy 是一個Twitter開源的一個redis和memcache快速/輕量級代理伺服器；可以将其後端的多台redis或memcached執行個體進行統一管理與配置設定，使應用程式隻需要在Twemproxy 上進行操作，而不用關心後面具體有多少個真實的redis或memcached存儲。           

39、支援一緻性哈希的用戶端有哪些？

Redis-rb、Predis等。           

40、Redis與其他key-value存儲有什麼不同？

1、Redis有複雜的資料結構并且提供對他們的原子性操作。
2、Redis的資料類型都是基本資料結構的同時對程式員透明，無需進行額外的抽象。
3、Redis運作在記憶體中但是可以持久化到磁盤。
4、相同複雜的資料結構，在記憶體中操作比在磁盤操作更簡單。
5、磁盤格式方面是緊湊的以追加的方式産生的，并不需要進行随機通路。           

41、如何降低Redis的記憶體使用情況？

利用Hash,List,Set,Sorted set(zset) 等集合類型資料，因為通常情況下很多小的Key-Value可以用更緊湊的方式存放到一起。           

42、檢視Redis使用情況及狀态資訊用什麼指令？

INFO           

43、Redis的記憶體用完了會發生什麼？

1、預設：如果達到設定的上限，寫指令會傳回錯誤資訊（但是讀指令還可以正常傳回）
2、配置淘汰機制:當Redis達到可用記憶體上限時會沖刷掉舊的資料。           

44、Redis是單線程的，如何提高多核CPU使用率？

1、可以在同一個伺服器部署多個Redis的執行個體，并把他們當作不同的伺服器來使用。
2、如果你想使用多個CPU，你可以考慮一下分片（shard）。           

45、一個Redis執行個體最多存多少key？集合最多能存多少元素？

理論上Redis可以處理2的32次方keys，任何list、set、和sorted set都可以放2的32次方個元素。           

46、Redis常見性能問題和解決方案？

1、 Master最好不要做任何持久化工作，如RDB記憶體快照和AOF日志檔案
2、如果資料比較重要，某個Slave開啟AOF備份資料，政策設定為每秒同步一次
3、為了主從複制的速度和連接配接的穩定性，Master和Slave最好在同一個區域網路内
4、避免在壓力很大的主庫上增加從庫
5、主從複制不要用網狀結構（類似n-1結構），用單向連結清單結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3...這樣的結構友善解決單點故障問題，實作Slave對Master的替換。如果Master挂了，可以立刻啟用Slave1做Master，其他不變。           

47、Redis提供了哪幾種持久化方式？

提供了兩種持久化方式：AOF和RDB
差別是：
AOF:append only file aof是将Redis執行的每一條指令追加到硬碟檔案中（儲存的執行指令）
RDB:rdb是通過快照的方式将符合條件的資料持久化到硬碟（儲存的是指令執行後得到的資料）
持久化配置規則：
save 900 20 (意思是900秒内 有超過20條資料寫入或修改，就會執行持久化操作)           

48、如何選擇合适的持久化方式？

1、如果想達到足以媲美PostgreSQL的資料安全性， 你應該同時使用兩種持久化功能。
2、如果非常關心資料， 但仍然可以承受數分鐘以内的資料丢失，那麼可以隻使用RDB持久化。
3、有很多使用者都隻使用AOF持久化，但并不推薦這種方式：因為定時生成RDB快照（snapshot）非常便于進行資料庫備份， 并且 RDB 恢複資料集的速度也要比AOF恢複的速度要快。           

49、修改配置不重新開機Redis會實時生效嗎？

Config Set 指令可以動态地調整 Redis 伺服器的配置而無須重新開機。           

50、Redis在哪些情況下會對資料進行快照（RDB）？

1、根據配置規則進行自動快照。 
2、使用者執行save或者bgsave指令。
3、執行flushall指令。
4、執行複制(replication)時。           

51、關于緩存擊穿的問題？

1、什麼是緩存擊穿？
  查詢一個在緩存中必然不存在的資料，導緻每次請求都要在資料庫中查詢。
2、沒緩存和沒有緩存的的系統吞吐量有多大的差别？
  沒有用緩存時，mysql的并發數在300（機械硬碟）-700（固态硬碟）之間（高性能伺服器）。一般的筆記本200個連接配接都撐不住。           

52、緩存失效、緩存穿透、緩存雪崩的産生原因和解決方案？

1、對空值也做緩存，過期時間設定較短
2、對不符合規則的查詢值做過濾
3、用bitMap和布隆過濾器
4、設定KEY為不同的過期時間

緩存失效：
    産生原因：設定緩存失效的時間過于集中，導緻緩存在同一時刻大面積失效。
    解決辦法：可以為不同的key設定為不同的過期時間。
    
緩存穿透：
    産生原因：查詢一個在緩存中必然不存在的資料，導緻每次請求都要在資料庫中查詢。
    解決辦法：1、對不符合規則的查詢值做過濾 2、用bitMap和布隆過濾器 3、空值也做緩存
    
緩存雪崩：
    産生原因：緩存雪崩就是指由于緩存的原因，導緻大量請求到達後端資料庫，進而導緻資料庫崩潰，整個系統崩潰，發生災難。“緩存并發”，“緩存穿透”，“緩存颠簸”等問題，其實都可能會導緻緩存雪崩現象發生。
    解決辦法：從應用架構角度，我們可以通過限流、降級、熔斷等手段來降低影響，也可以通過多級緩存來避免這種災難。           

53、Redis伺服器高可用架構演變？

連接配接：如何搭建高可用的redis服務 （Redis高可用架構的演變）           

54、為什麼單線程的Redis比多線程的memcache的性能高？

1、資料結構簡單
2、單線程無CPU切換性能損耗 
3、沒有多線程加鎖問題           

55、Redis是否是線程安全的？

線程安全的。（單線程沒有線程安全一說）           

56、緩存常見的問題？

緩存一緻性問題
緩存并發
緩存颠簸問題
緩存失效
緩存穿透
緩存的雪崩現象
緩存無底洞現象           

57、緩存失效時，并發通路如何讓一個KEY隻被加載一次，攔截其他的請求？

。。。           

58、Redis的叢集模式是如何實作的？Redis的key是如何尋址的？

四種實作方式：
1、推特的開源架構 twemproxy 代理
2、豌豆莢的 codis 代理 舊的資料可以映射到新的節點
3、Redis自帶的集權 Redis cluster3.0  使用的是hash槽
4、代碼層面實作  注意資料震蕩後的資料恢複

尋址方式：