來討論一下這些常見的Redis面試題
1、Redis支持的數據類型？
String（字符串）
格式: set key value
string類型是二進制安全的。意思是redis的string可以包含任何數據。比如jpg圖片或者序列化的對象 。
string類型是Redis最基本的數據類型，一個鍵最大能存儲512MB。
Hash（哈希）
格式: hmset name key1 value1 key2 value2
Redis hash 是一個鍵值(key=>value)對集合。
Redis hash是一個string類型的field和value的映射表，hash特別適合用于存儲對象。
List（列表）
Redis 列表是簡單的字符串列表，按照插入順序排序。你可以添加一個元素到列表的頭部（左邊）或者尾部（右邊）
格式: lpush name value
在 key 對應 list 的頭部添加字符串元素
格式: rpush name value
在 key 對應 list 的尾部添加字符串元素
格式: lrem name index
key 對應 list 中刪除 count 個和 value 相同的元素
格式: llen name
返回 key 對應 list 的長度
Set（集合）
格式: sadd name value
Redis的Set是string類型的無序集合。
集合是通過哈希表實現的，所以添加，刪除，查找的復雜度都是O(1)。
zset(sorted set：有序集合)
格式: zadd name score value
Redis zset 和 set 一樣也是string類型元素的集合,且不允許重復的成員。
不同的是每個元素都會關聯一個double類型的分數。redis正是通過分數來為集合中的成員進行從小到大的排序。
zset的成員是唯一的,但分數(score)卻可以重復。
2、什么是Redis持久化？Redis有哪幾種持久化方式？優缺點是什么？
持久化就是把內存的數據寫到磁盤中去，防止服務宕機了內存數據丟失。
Redis 提供了兩種持久化方式：RDB（默認） 和AOF
RDB：
rdb是Redis DataBase縮寫
功能核心函數rdbSave(生成RDB文件)和rdbLoad（從文件加載內存）兩個函數
AOF:
Aof是Append-only file縮寫
每當執行服務器(定時)任務或者函數時flushAppendOnlyFile 函數都會被調用， 這個函數執行以下兩個工作
aof寫入保存：
- WRITE：根據條件，將 aof_buf 中的緩存寫入到 AOF 文件
- SAVE：根據條件，調用 fsync 或 fdatasync 函數，將 AOF 文件保存到磁盤中。
存儲結構:
內容是redis通訊協議(RESP )格式的命令文本存儲。
比較：
- aof文件比rdb更新頻率高，優先使用aof還原數據。
- aof比rdb更安全也更大
- rdb性能比aof好
- 如果兩個都配了優先加載AOF
剛剛上面你有提到redis通訊協議(RESP )，能解釋下什么是RESP？有什么特點？（可以看到很多面試其實都是連環炮，面試官其實在等著你回答到這個點，如果你答上了對你的評價就又加了一分）
RESP 是redis客戶端和服務端之前使用的一種通訊協議；
RESP 的特點：實現簡單、快速解析、可讀性好
For Simple Strings the first byte of the reply is "+" 回復
For Errors the first byte of the reply is "-" 錯誤
For Integers the first byte of the reply is ":" 整數
For Bulk Strings the first byte of the reply is "$" 字符串
For Arrays the first byte of the reply is "*" 數組
持久化在面試中問到的頻率較高，重點學一下，篇幅有限，具體點下面的文章：
10分鐘徹底理解Redis的持久化機制：RDB和AOF
3、Redis 有哪些架構模式？講講各自的特點
單機版
特點：
簡單
問題：
- 內存容量有限
- 處理能力有限
- 無法高可用。
主從復制
Redis 的復制（replication）功能允許用戶根據一個 Redis 服務器來創建任意多個該服務器的復制品，其中被復制的服務器為主服務器（master），而通過復制創建出來的服務器復制品則為從服務器（slave）。
只要主從服務器之間的網絡連接正常，主從服務器兩者會具有相同的數據，主服務器就會一直將發生在自己身上的數據更新同步 給從服務器，從而一直保證主從服務器的數據相同。
特點：
- master/slave 角色
- master/slave 數據相同
- 降低 master 讀壓力在轉交從庫
問題：
- 無法保證高可用
- 沒有解決 master 寫的壓力
哨兵
Redis sentinel 是一個分布式系統中監控 redis 主從服務器，并在主服務器下線時自動進行故障轉移。其中三個特性：
- 監控（Monitoring）：Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
- 提醒（Notification）：當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
- 自動故障遷移（Automatic failover）：當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作。
特點：
- 保證高可用
- 監控各個節點
- 自動故障遷移
缺點：
- 主從模式，切換需要時間丟數據
- 沒有解決 master 寫的壓力
集群（proxy 型）
Twemproxy 是一個 Twitter 開源的一個 redis 和 memcache 快速/輕量級代理服務器；Twemproxy 是一個快速的單線程代理程序，支持 Memcached ASCII 協議和 redis 協議。
特點：
- 多種 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins
- 支持失敗節點自動刪除
- 后端 Sharding 分片邏輯對業務透明，業務方的讀寫方式和操作單個 Redis 一致
缺點：
- 增加了新的 proxy，需要維護其高可用。
- failover 邏輯需要自己實現，其本身不能支持故障的自動轉移可擴展性差，進行擴縮容都需要手動干預
集群（直連型）：
從redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用無中心結構，每個節點保存數據和整個集群狀態,每個節點都和其他所有節點連接。
特點：
- 無中心架構（不存在哪個節點影響性能瓶頸），少了 proxy 層。
- 數據按照 slot 存儲分布在多個節點，節點間數據共享，可動態調整數據分布。
- 可擴展性，可線性擴展到 1000 個節點，節點可動態添加或刪除。
- 高可用性，部分節點不可用時，集群仍可用。通過增加 Slave 做備份數據副本 -實現故障自動 failover，節點之間通過 gossip 協議交換狀態信息，用投票機制完成 Slave到 Master 的角色提升。
缺點：
- 資源隔離性較差，容易出現相互影響的情況。
- 數據通過異步復制,不保證數據的強一致性
高可用Redis架構分析搭建，可以參考：
高可用Redis服務架構分析與搭建
4、使用過Redis分布式鎖么，它是怎么實現的？
先拿setnx來爭搶鎖，搶到之后，再用expire給鎖加一個過期時間防止鎖忘記了釋放。
如果在setnx之后執行expire之前進程意外crash或者要重啟維護了，那會怎么樣？
set指令有非常復雜的參數，這個應該是可以同時把setnx和expire合成一條指令來用的！
5、使用過Redis做異步隊列么，你是怎么用的？有什么缺點？
一般使用list結構作為隊列，rpush生產消息，lpop消費消息。當lpop沒有消息的時候，要適當sleep一會再重試。
缺點：
- 在消費者下線的情況下，生產的消息會丟失，得使用專業的消息隊列如rabbitmq等。
能不能生產一次消費多次呢？
使用pub/sub主題訂閱者模式，可以實現1:N的消息隊列。
6、什么是緩存穿透？如何避免？什么是緩存雪崩？何如避免？
緩存穿透
一般的緩存系統，都是按照key去緩存查詢，如果不存在對應的value，就應該去后端系統查找（比如DB）。一些惡意的請求會故意查詢不存在的key,請求量很大，就會對后端系統造成很大的壓力。這就叫做緩存穿透。
如何避免？
- 對查詢結果為空的情況也進行緩存，緩存時間設置短一點，或者該key對應的數據insert了之后清理緩存。
- 對一定不存在的key進行過濾。可以把所有的可能存在的key放到一個大的Bitmap中，查詢時通過該bitmap過濾。
緩存雪崩
當緩存服務器重啟或者大量緩存集中在某一個時間段失效，這樣在失效的時候，會給后端系統帶來很大壓力。導致系統崩潰。
如何避免？
- 在緩存失效后，通過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。比如對某個key只允許一個線程查詢數據和寫緩存，其他線程等待。
- 做二級緩存，A1為原始緩存，A2為拷貝緩存，A1失效時，可以訪問A2，A1緩存失效時間設置為短期，A2設置為長期
- 不同的key，設置不同的過期時間，讓緩存失效的時間點盡量均勻。
這道相當常見，詳細再參考下文，一定熟練掌握：
Redis緩存雪崩、緩存擊穿、緩存穿透和常見的幾種緩存模式
7、Redis常用命令
管理命令
- # dbsize 返回當前數據庫 key 的數量。
- # info 返回當前 redis 服務器狀態和一些統計信息。
- # monitor 實時監聽并返回redis服務器接收到的所有請求信息。
- # shutdown 把數據同步保存到磁盤上，并關閉redis服務。
- # config get parameter 獲取一個 redis 配置參數信息。（個別參數可能無法獲取）
- # config set parameter value 設置一個 redis 配置參數信息。（個別參數可能無法獲取）
- # config resetstat 重置 info 命令的統計信息。（重置包括：keyspace 命中數、
- # keyspace 錯誤數、 處理命令數，接收連接數、過期 key 數）
- # debug object key 獲取一個 key 的調試信息。
- # debug segfault 制造一次服務器當機。
- # flushdb 刪除當前數據庫中所有 key,此方法不會失敗。小心慎用
- # flushall 刪除全部數據庫中所有 key，此方法不會失敗。小心慎用
工具命令
- #redis-server：Redis 服務器的 daemon 啟動程序
- #redis-cli：Redis 命令行操作工具。當然，你也可以用 telnet 根據其純文本協議來操作
- #redis-benchmark：Redis 性能測試工具，測試 Redis 在你的系統及你的配置下的讀寫性能
- $redis-benchmark -n 100000 –c 50
- #模擬同時由 50 個客戶端發送 100000 個 SETs/GETs 查詢
- #redis-check-aof：更新日志檢查
- #redis-check-dump：本地數據庫檢查
8.Redis單例、主從模式、sentinel以及集群的配置方式及優缺點對比
Redis單例、主從模式、sentinel以及集群的配置方式及優缺點對比
9、為什么Redis 單線程卻能支撐高并發？
為什么Redis 單線程卻能支撐高并發？
10、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最好在同一個局域網內
Redis性能分析相關問題，限于篇幅，給出文章鏈接：
Redis 性能問題分析（好文推薦）
11、Redis的并發競爭問題如何解決?
Redis為單進程單線程模式，采用隊列模式將并發訪問變為串行訪問。Redis本身沒有鎖的概念，Redis對于多個客戶端連接并不存在競爭，但是在Jedis客戶端對Redis進行并發訪問時會發生連接超時、數據轉換錯誤、阻塞、客戶端關閉連接等問題，這些問題均是由于客戶端連接混亂造成。對此有2種解決方法：
- 客戶端角度，為保證每個客戶端間正常有序與Redis進行通信，對連接進行池化，同時對客戶端讀寫Redis操作采用內部鎖synchronized。
- 服務器角度，利用setnx實現鎖。
注：對于第一種，需要應用程序自己處理資源的同步，可以使用的方法比較通俗，可以使用synchronized也可以使用lock；第二種需要用到Redis的setnx命令，但是需要注意一些問題。
12、說說Redis的內存淘汰策略
直接點這里：Redis的內存淘汰策略
13、Redis最適合的場景
Redis最適合所有數據in-momory的場景，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed的功能，跟傳統意義上的持久化有比較大的差別，那么可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那么何時使用Memcached，何時使用Redis呢?
如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：
- Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
- Redis支持數據的備份，即master-slave模式的數據備份。
- Redis支持數據的持久化，可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用。
會話緩存（Session Cache）
最常用的一種使用Redis的情景是會話緩存（session cache）。用Redis緩存會話比其他存儲（如Memcached）的優勢在于：Redis提供持久化。當維護一個不是嚴格要求一致性的緩存時，如果用戶的購物車信息全部丟失，大部分人都會不高興的，現在，他們還會這樣嗎？
幸運的是，隨著 Redis 這些年的改進，很容易找到怎么恰當的使用Redis來緩存會話的文檔。甚至廣為人知的商業平臺Magento也提供Redis的插件。
全頁緩存（FPC）
除基本的會話token之外，Redis還提供很簡便的FPC平臺。回到一致性問題，即使重啟了Redis實例，因為有磁盤的持久化，用戶也不會看到頁面加載速度的下降，這是一個極大改進，類似PHP本地FPC。
再次以Magento為例，Magento提供一個插件來使用Redis作為全頁緩存后端。
此外，對WordPress的用戶來說，Pantheon有一個非常好的插件 wp-redis，這個插件能幫助你以最快速度加載你曾瀏覽過的頁面。
隊列
Reids在內存存儲引擎領域的一大優點是提供 list 和 set 操作，這使得Redis能作為一個很好的消息隊列平臺來使用。Redis作為隊列使用的操作，就類似于本地程序語言（如Python）對 list 的 push/pop 操作。
如果你快速的在Google中搜索“Redis queues”，你馬上就能找到大量的開源項目，這些項目的目的就是利用Redis創建非常好的后端工具，以滿足各種隊列需求。例如，Celery有一個后臺就是使用Redis作為broker，你可以從這里去查看。
排行榜/計數器
Redis在內存中對數字進行遞增或遞減的操作實現的非常好。集合（Set）和有序集合（Sorted Set）也使得我們在執行這些操作的時候變的非常簡單，Redis只是正好提供了這兩種數據結構。所以，我們要從排序集合中獲取到排名最靠前的10個用戶–我們稱之為“user_scores”。
當然，這是假定你是根據你用戶的分數做遞增的排序。如果你想返回用戶及用戶的分數，你需要這樣執行：ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一個很好的例子，用Ruby實現的，它的排行榜就是使用Redis來存儲數據的，你可以在這里看到。發布/訂閱
最后（但肯定不是最不重要的）是Redis的發布/訂閱功能。發布/訂閱的使用場景確實非常多。我已看見人們在社交網絡連接中使用，還可作為基于發布/訂閱的腳本觸發器，甚至用Redis的發布/訂閱功能來建立聊天系統！
