一、你用redis的應用場景是什麼？
秒殺的庫存扣減，APP首頁的訪問流量高峯，緩存，排行榜，短信驗證碼（限流），點贊、好友等相互關係的存儲，限時業務的運用
二、redis與memecache有區別？
1、集羣：
redis 和memcached都支持集羣
2、數據類型
Redis支持的數據類型要豐富得多,Redis不僅僅支持簡單的k/v類型的數據，同時還提供String，List,Set,Hash,Sorted
Set,pub/sub,Transactions數據結構的存儲。其中Set是HashMap實現的，value永遠爲null而已
memcache支持簡單數據類型，需要客戶端自己處理複雜對象
3、持久性
redis支持數據落地持久化存儲,可以將內存中的數據保持在磁盤中，重啓的時候可以再次加載進行使用。
memcache不支持數據持久存儲
4、分佈式存儲
redis支持master-slave複製模式
memcache可以使用一致性hash做分佈式
5、value大小不同
memcache是一個內存緩存，key的長度小於250字符，單個item存儲要小於1M，不適合虛擬機使用
6、數據一致性不同
Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。
而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，
但是比起Memcached，還是稍有遜色。
redis使用的是單線程模型，保證了數據按順序提交。
memcache需要使用cas保證數據一致性。CAS（Check and Set）是一個確保併發一致性的機制，
屬於“樂觀鎖”範疇；原理很簡單：拿版本號，操作，對比版本號，如果一致就操作，不一致就放棄任何操作
7、cpu利用
redis單線程模型只能使用一個cpu，可以開啓多個redis進程
三、基礎知識部分
1、說說常見的數據結構？
a、5種常見數據結構
String
Hash
List
Set
SortedSet
b、其它數據類型
HyperLogLog、Geo、Pub/Sub
2、如果有大量的key需要設置同一時間過期，一般需要注意什麼？
如果將大量的 key 設置在同一時間過期，到這個時間點，redis 會出現短暫的卡頓現象。嚴重的話會出現緩存雪崩。
所以我們一般在時間上加一個隨即值，使過期時間分散
3、你使用過Redis分佈式鎖麼，它是什麼回事？
先拿 setnx 來搶鎖，搶到之後，再用expire給鎖加一個過期時間防止忘記釋放鎖
4、假如Redis裏面有10w個key是以某個固定的已知的前綴開頭的，如何將它們全部找出來？
使用 keys 指令可以全部掃出
5、如果redis正在提供服務，那麼使用 keys 指令會有什麼問題？
由於 redis 是單線程的，keys 指令會導致線程阻塞一段時間，服務會停頓，直到 keys 執行完畢。所以，
這個時候要用 scan 指令。scan 可以設置每次取出的個數，但是有可能會重複，所以要在客戶端作一次去重。
6、redis是怎麼進行數據持久化的？
目前 redis 持久化有三種實現方式：
（1） RDB
（2） AOF
（3） RDB-AOF混合
先上結論：公司用得最多的是第三種，也就是混合方式。
RDB和AOF比較：
RDB 將數據庫的快照（snapshot）以二進制的方式保存到磁盤中。
AOF 則以協議文本的方式，將所有對數據庫進行過寫入的命令（及其參數）記錄到 AOF 文件，
以此達到記錄數據庫狀態的目的。
RDB 理解爲一整個表全量的數據，AOF 理解爲每次操作的日誌。
由於這兩種方式各自存在優缺點，所以目前使用RDB 做鏡像全量持久化，AOF 做增量持久化。
服務器重啓的時候先把表的數據全部搞進去，但是他可能不完整，你再回放一下日誌，數據不就完整了嘛。
7、RDB的原理可以講講嗎？
fork 和 cow。fork 是指 redis 通過創建子進程來進行 RDB 操作，cow 指的是 copy on write，子進程創建後，
父子進程共享數據段，父進程繼續提供讀寫服務，寫髒的頁面數據會逐漸和子進程分離開來。
8、redis的主從同步瞭解嗎？
第一次同步時，主節點做一次 bgsave，並同時將後續修改操作記錄到內存 buffer，
待完成後將 RDB 文件全量同步到複製節點，
複製節點接受完成後將 RDB 鏡像加載到內存。加載完成後，
再通知主節點將期間修改的操作記錄同步到複製節點進行重放就完成了同步過程。
後續的增量數據通過 AOF 日誌同步即可，有點類似數據庫的 binlog。
爲了方便同學們的理解，我這裏用兩臺docker做實驗。
修改兩臺 redis 的 /etc/redis.cof 文件，將這裏改爲 0.0.0.0
bind 0.0.0.0
主機 ip:172.17.0.2 從機 ip：172.17.0.3
主機連接從機，可以看到直接進入了從機的 bash
redis-cli 查看主機信息：
從機連接主機
redis-cli 查看從機信息：：
從機設置了只讀，這裏我們測試從機是否可寫
報錯：從機只有讀權限，無寫權限。
測試成功！
9、能說說redis哨兵模式嗎？
Redis Sentinal 着眼於高可用，在master宕機時會自動將slave提升爲master，繼續提供服務。
配置過 Sentinal 的哨兵模式
架構圖：
這裏用 3個 redis，3個 sentinel 來實驗
起6個docker
redis：
主：172.17.0.2
從1：172.17.0.3
從2:：172.17.0.4
sentinel:
leader：172.17.0.5
slave1：172.17.0.6
slave2：172.17.0.7
配置哨兵
vi /etc/redis-sentinel.conf
# 添加如下3條
bind 0.0.0.0
protected-mode yes
daemonize yes
啓動 /usr/bin/redis-sentinel /etc/redis-sentinel.conf
redis主機：可以看到兩臺從機，分別是 3 和 4
sentinel：主機是 2，兩臺從機
模擬主機宕機： 將2 停掉
使用從機1 也就是 3 查看：主機已經變成 4 了
再查看哨兵：主機變成4了
恢復 2，查看 2：
結果：2 自動加入集羣，併成爲從機，監聽主機 4
測試成功！
