【*】Redis常見問題彙總

一、什麼是Redis？

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

二、Redis相比memcached有哪些優點？

劣勢：Redis是單線程，Memcached是多線程，在多核服務器上後者的性能理論上會更高一些。
優點：隨着Redis3.0的推出，標誌着memcache的全部功能都已經成了Redis的子集。同時Redis對集羣的支持使得Memcache原有的第三方集羣工具再也不成爲優點。所以，在新項目中使用Redis替代Memcache將會是很是好的選擇。

三、Redis支持哪幾種數據類型？適合存儲的數據類型？使用場景【5種 】

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

四、Redis主要消耗什麼物理資源？

內存

五、Redis的全稱是什麼？

Remote Dictionary Server（遠程數據服務）

六、Redis有哪幾種數據淘汰策略？

共六種數據淘汰策略。（分三類）
1、從已設置過時的數據集
一、volatile-lru：從已設置過時時間的數據集中，選擇最近最少使用的數據淘汰
二、volatile-ttl：從已設置過時時間的數據集中，選擇將要過時的數據淘汰
三、volatile-random：從已設置過時時間的數據集中，任意選擇數據淘汰
2、從總體數據集
四、allkeys-lru：從全數據集中，選擇最近最少使用的數據淘汰
五、allkeys-random：從全數據集中任意選擇數據淘汰
3、驅逐（默認策略-直接返回錯誤）
六、noenviction（驅逐）：不刪除任意數據(但redis還會根據引用計數器進行釋放),這時若是內存不夠時，會直接返回錯誤

七、Redis官方爲何不提供Windows版本？

目前Linux版本已經至關穩定，用戶量很大，無需開發windows版本，反而會帶來兼容性等問題。

八、字符串類型存儲的最大容量？

512M。

九、爲何Redis須要把全部數據放到內存中？

內存存取遠比磁盤IO快得多。

十、Redis集羣方案應該怎麼作？都有哪些方案？

一、Twemproxy，推特的開源方案。它會以一個代理的身份接收請求並使用一致性hash算法，將請求轉接到具體redis，將結果再返回twemproxy。 問題：redis節點數量改變時候，數據沒法自動移動到新的節點。
二、Codis，豌豆莢的開源方案。目前使用最多的集羣方案，基本和twemproxy一致的效果，它支持在 節點數量改變狀況下，舊節點數據可恢復到新hash節點。
三、Redis cluster3.0自帶的集羣，特色：他的分佈式算法不是一致性hash，而是hash槽，以及自身支持節點設置從節點。
四、業務代碼層實現，在代碼層，對key 進行hash計算，而後去對應的redis實例操做數據。 這種方式對hash層代碼要求比較高，須要重點考慮的是，節點失效後的替代算法方案，數據震盪後的自動腳本恢復，實例的監控，等等。

十一、Redis集羣方案什麼狀況下會致使整個集羣不可用？

有A，B，C三個節點的集羣,在沒有複製模型的狀況下,若是節點B失敗了，那麼整個集羣就會由於缺乏5501-11000這個範圍的槽而不可用。數據丟失

十二、有2000w數據，Redis只存20w，如何保證Redis中都是熱點數據？

先計算下這20W條數據佔用的內存，設置最大可用內存，當內存中的數據集達到上限時，redis就會啓動LRU(數據淘汰策略)。

1三、Redis應用場景？

一、會話緩存（Session Cache）
    例如：分佈式登陸信息，購物車信息，能提供持久化。
二、全頁緩存（FPC）
    除基本的會話token以外，Redis還提供很簡便的FPC平臺。即便重啓了Redis實例，由於有磁盤的持久化，用戶也不會看到頁面加載速度的降低
三、隊列
    因爲支持 list 和 set 操做，這使得Redis能做爲一個很好的消息隊列平臺來使用
四、排行榜/計數器
    incr  range
五、發佈/訂閱

1四、Redis支持的Java客戶端都有哪些？官方推薦用哪一個？

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

1五、Redis和Redisson有什麼關係？

Redisson  是一個高級的、分佈式協調Redis客戶端。

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

一、Jedis是Redis的Java實現的客戶端，其API提供了比較全面的Redis命令的支持；
二、Redisson實現了分佈式和可擴展的Java數據結構，和Jedis相比，功能較爲簡單，不支持字符串操做，不支持排序、事務、管道、分區等Redis特性。
三、Redisson的宗旨是促進使用者對Redis的關注分離，從而讓使用者可以將精力更集中地放在處理業務邏輯上。

1七、Redis如何設置密碼及驗證密碼？

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

1八、Redis哈希槽？

一、Redis 集羣中內置了 16384 個哈希槽。
二、須要在 Redis 集羣中存一個 key-value時，Redis 先對 key 使用 crc16 算法算出一個結果。
三、而後把結果對 16384 取模，這樣每一個 key 都會對應一個編號在 0-16383 之間的哈希槽。
四、Redis 會根據節點數量大體均等的將哈希槽映射到不一樣的節點。

1九、Redis集羣的主從複製模型？

爲了使在部分節點失敗或者大部分節點沒法通訊的狀況下集羣仍然可用，因此集羣使用了主從複製模型,每一個節點都會有N-1個複製品

20、Redis集羣會有寫操做丟失嗎？

Redis並不能保證數據的強一致性，這意味這在實際中集羣在特定的條件下(使用的內存超過了最大可用內存（數據淘汰策略是noenviction（驅逐）的時候）)可能會丟失寫操做。

2一、Redis集羣之間是如何複製的？

異步複製
初始化複製：
一、從數據庫啓動後，會向主數據庫發送SYNC命令。
二、主數據庫收到SYNC後會在後臺保存快照（RDB持久化過程），並將保存快照期間接收到的命令緩存起來。
三、快照完成後，Redis會將快照文件和全部緩存的命令發送給從數據庫。
四、從數據庫收到快照後會載入快照文件並執行緩存命令。
運行中複製：
當主數據庫每當收到寫命令，就會將命令同步到從數據庫。
斷線重連機制：
redis2.6以前，斷線重連後會進行所有複製（主數據庫的RDB文件發給從數據庫）
redis2.8以後，斷線重連後進行的是增量複製。

2二、Redis集羣最大節點個數是多少？

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

2三、Redis集羣如何選擇數據庫？

默認在0號數據庫。

2四、怎麼測試Redis的連通性？

ping命令測試客戶端與Redis服務鏈接是否正常，返回pong正常。

2五、Redis中的管道有什麼用?

能夠在服務端未響應時，客戶端能夠繼續向服務端發送請求，並最終一次性讀取全部服務端的響應。

2六、Redis事務？

一、提供了命令打包，順序執行的機制。
二、命令入隊，先進先出。
三、帶 WATCH 命令的事務，當鍵對應的值被修改時，事務直接返回失敗，不然成功。
四、保證了一致性和隔離性，不保證原子性和持久性（Redis的事務不是一個完整的事務）。
參考： 深刻理解Redis事務

2七、Redis事務相關命令?

一、MULTI （開啓事務）
 二、DISCARD （取消事務，若是正在使用 WATCH 命令監視某個(或某些) key，那麼取消全部監視，等同於執行命令 UNWATCH）
 三、EXEC （執行事務）
 四、WATCH （監視一個(或多個) key ，若是在事務執行以前這個(或這些) key 被其餘命令所改動，那麼事務將被打斷）

2八、Redis key的過時時間和永久有效分別怎麼設置？

一、過時時間：set key timeout value
二、永久有效：默認不設置過時時間（set key value）永久有效,可是若是實際使用內存超過你設置的最大內存，而且設置了數據淘汰策略，就會使用LRU刪除機制

2九、Redis如何作內存優化？

應使用散列表（HashSst），適合存儲對象類型。儘量的將數據模型抽象到一個散列表裏面。好比：用戶對象，不要爲這個用戶的名稱，姓氏，郵箱，密碼設置單獨的key,而是應該把這個用戶的全部信息存儲到一張散列表裏面。

30、Redis回收進程如何工做的？

一、客戶端接收到數據寫入請求後，Redis檢查內存使用狀況，若是大於maxmemory的限制, 則根據設定好的策略進行回收。一個新的命令被執行。
二、因此咱們不斷地穿越內存限制的邊界，經過不斷達到邊界而後不斷地回收回到邊界如下。

3一、Redis回收使用的算法？

LRU算法。

3二、Redis如何作大量數據插入？

Redis2.6開始redis-cli支持一種新的被稱之爲pipe mode的新模式用於執行大量數據插入。

3三、爲何要作Redis分區？

分區使得咱們原本受限於單臺計算機硬件資源的問題再也不是問題，存儲不夠，計算資源不夠，帶寬不夠，咱們均可以經過增長機器來解決這些問題。

3四、Redis的分區實現方案？

一、客戶端分區：就是在客戶端就已經決定數據會被存儲到哪一個redis節點或者從哪一個redis節點讀取。大多數客戶端已經實現了客戶端分區。
二、代理分區 ：意味着客戶端將請求發送給代理，而後代理決定去哪一個節點寫數據或者讀數據。代理根據分區規則決定請求哪些Redis實例，而後根據Redis的響應結果返回給客戶端。redis和memcached的一種代理實現就是Twemproxy
三、查詢路由(Query routing) ：意思是客戶端隨機地請求任意一個redis實例，而後由Redis將請求轉發給正確的Redis節點。Redis Cluster實現了一種混合形式的查詢路由，但並非直接將請求從一個redis節點轉發到另外一個redis節點，而是在客戶端的幫助下直接redirected到正確的redis節點。

3五、Redis分區有什麼缺點？

一、多鍵操做是不被支持的，好比咱們將要批量操做的鍵被映射到了不一樣的Redis實例中。
二、多鍵的Redis事務是不被支持的。
三、分區的最小粒度是鍵，所以咱們不能將關聯到一個鍵的很大的數據集映射到不一樣的實例。
四、當應用分區的時候，數據的處理是很是複雜的，好比咱們須要處理多個rdb/aof文件，將分佈在不一樣實例的文件彙集到一塊兒備份。
五、添加和刪除機器是很複雜的，例如Redis集羣支持幾乎運行時透明的由於增長或減小機器而須要作的rebalancing,然而像客戶端和代理分區這種方式是不支持這種功能的。

3六、Redis持久化和緩存怎麼作擴容？

一、若是Redis被當作緩存使用，使用一致性哈希實現動態擴容縮容。
二、若是Redis被當作一個持久化存儲使用，必須使用固定的keys-to-nodes映射關係，節點的數量一旦肯定不能變化。不然的話(即Redis節點須要動態變化的狀況），必須使用能夠在運行時進行數據再平衡的一套系統，而當前只有Redis集羣能夠作到這樣。

3七、分佈式Redis是前期作仍是規模上來了再作好？爲何？

一、一開始就作分區，遷移redis實例不用考慮分區
二、既然Redis是如此的輕量（單實例只使用1M內存）,爲防止之後的擴容，最好的辦法就是一開始就啓動較多實例。即使你只有一臺服務器，你也能夠一開始就讓Redis以分佈式的方式運行，使用分區，在同一臺服務器上啓動多個實例。
這樣的話，當你的數據不斷增加，須要更多的Redis服務器時，你須要作的就是僅僅將Redis實例從一臺服務遷移到另一臺服務器而已（而不用考慮從新分區的問題）。一旦你添加了另外一臺服務器，你須要將你一半的Redis實例從第一臺機器遷移到第二臺機器。

3八、Twemproxy是什麼？

Twemproxy 是一個Twitter開源的一個redis和memcache快速/輕量級代理服務器；能夠將其後端的多臺redis或memcached實例進行統一管理與分配，使應用程序只須要在Twemproxy 上進行操做，而不用關心後面具體有多少個真實的redis或memcached存儲。

3九、支持一致性哈希的客戶端有哪些？

Redis-rb、Predis等。

40、Redis與其餘key-value存儲有什麼不一樣？

一、Redis有複雜的數據結構而且提供對他們的原子性操做。
二、Redis的數據類型都是基本數據結構的同時對程序員透明，無需進行額外的抽象。
三、Redis運行在內存中可是能夠持久化到磁盤。
四、相同複雜的數據結構，在內存中操做比在磁盤操做更簡單。
五、磁盤格式方面是緊湊的以追加的方式產生的，並不須要進行隨機訪問。

4一、如何下降Redis的內存使用狀況？

利用Hash,List,Set,Sorted set(zset) 等集合類型數據，由於一般狀況下不少小的Key-Value能夠用更緊湊的方式存放到一塊兒。

4二、查看Redis使用狀況及狀態信息用什麼命令？

INFO

4三、Redis的內存用完了會發生什麼？

一、默認：若是達到設置的上限，寫命令會返回錯誤信息（可是讀命令還能夠正常返回）
二、配置淘汰機制:當Redis達到可用內存上限時會沖刷掉舊的數據。

4四、Redis是單線程的，如何提升多核CPU利用率？

一、能夠在同一個服務器部署多個Redis的實例，並把他們看成不一樣的服務器來使用。
二、若是你想使用多個CPU，你能夠考慮一下分片（shard）。

4五、一個Redis實例最多存多少key？集合最多能存多少元素？

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

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

一、 Master最好不要作任何持久化工做，如RDB內存快照和AOF日誌文件
二、若是數據比較重要，某個Slave開啓AOF備份數據，策略設置爲每秒同步一次
三、爲了主從複製的速度和鏈接的穩定性，Master和Slave最好在同一個局域網內
四、避免在壓力很大的主庫上增長從庫
五、主從複製不要用網狀結構（相似n-1結構），用單向鏈表結構更爲穩定，即：Master <- Slave1 <- Slave2 <- Slave3...這樣的結構方便解決單點故障問題，實現Slave對Master的替換。若是Master掛了，能夠馬上啓用Slave1作Master，其餘不變。

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

提供了兩種持久化方式：AOF和RDB
區別是：
AOF:append only file aof是將Redis執行的每一條命令追加到硬盤文件中（保存的執行命令）
RDB:rdb是經過快照的方式將符合條件的數據持久化到硬盤（保存的是命令執行後獲得的數據）
持久化配置規則：
save 900 20 (意思是900秒內 有超過20條數據寫入或修改，就會執行持久化操做)

4八、如何選擇合適的持久化方式？

一、若是想達到足以媲美PostgreSQL的數據安全性， 你應該同時使用兩種持久化功能。
二、若是很是關心數據， 但仍然能夠承受數分鐘之內的數據丟失，那麼能夠只使用RDB持久化。
三、有不少用戶都只使用AOF持久化，但並不推薦這種方式：由於定時生成RDB快照（snapshot）很是便於進行數據庫備份， 而且 RDB 恢復數據集的速度也要比AOF恢復的速度要快。

4九、修改配置不重啓Redis會實時生效嗎？

Config Set 命令能夠動態地調整 Redis 服務器的配置而無須重啓。

50、Redis在哪些狀況下會對數據進行快照（RDB）？

一、根據配置規則進行自動快照。 
二、用戶執行save或者bgsave命令。
三、執行flushall命令。
四、執行復制(replication)時。

5一、關於緩存擊穿的問題？

一、什麼是緩存擊穿？
  查詢一個在緩存中必然不存在的數據，致使每次請求都要在數據庫中查詢。
二、沒緩存和沒有緩存的的系統吞吐量有多大的差異？
  沒有用緩存時，mysql的併發數在300（機械硬盤）-700（固態硬盤）之間（高性能服務器）。通常的筆記本200個鏈接都撐不住。

5二、緩存失效、緩存穿透、緩存雪崩的產生緣由和解決方案？

一、對空值也作緩存，過時時間設置較短
二、對不符合規則的查詢值作過濾
三、用bitMap和布隆過濾器
四、設置KEY爲不一樣的過時時間

緩存失效：
    產生緣由：設置緩存失效的時間過於集中，致使緩存在同一時刻大面積失效。
    解決辦法：能夠爲不一樣的key設置爲不一樣的過時時間。
    
緩存穿透：
    產生緣由：查詢一個在緩存中必然不存在的數據，致使每次請求都要在數據庫中查詢。
    解決辦法：一、對不符合規則的查詢值作過濾 二、用bitMap和布隆過濾器 三、空值也作緩存
    
緩存雪崩：
    產生緣由：緩存雪崩就是指因爲緩存的緣由，致使大量請求到達後端數據庫，從而致使數據庫崩潰，整個系統崩潰，發生災難。「緩存併發」，「緩存穿透」，「緩存顛簸」等問題，其實均可能會致使緩存雪崩現象發生。
    解決辦法：從應用架構角度，咱們能夠經過限流、降級、熔斷等手段來下降影響，也能夠經過多級緩存來避免這種災難。

5三、Redis服務器高可用架構演變？

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

5四、爲何單線程的Redis比多線程的memcache的性能高？

一、數據結構簡單
二、單線程無CPU切換性能損耗 
三、沒有多線程加鎖問題

5五、Redis是不是線程安全的？

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

5六、緩存常見的問題？

緩存一致性問題
緩存併發
緩存顛簸問題
緩存失效
緩存穿透
緩存的雪崩現象
緩存無底洞現象

5七、緩存失效時，併發訪問如何讓一個KEY只被加載一次，攔截其餘的請求？

。。。

5八、Redis的集羣模式是如何實現的？Redis的key是如何尋址的？

四種實現方式：
一、推特的開源框架 twemproxy 代理
二、豌豆莢的 codis 代理 舊的數據能夠映射到新的節點
三、Redis自帶的集權 Redis cluster3.0  使用的是hash槽
四、代碼層面實現  注意數據震盪後的數據恢復

尋址方式：

原文出處：https://www.cnblogs.com/luao/p/10505273.html