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、代碼層面實現 注意數據震盪後的數據恢復
尋址方式：
原文出處：https://www.cnblogs.com/luao/p/10505273.html