1.Redis的應用場景?
1.Token令牌的生成
2.短信驗證碼的code
3.可以實現緩存查詢數據 a. 減輕我們的數據庫的訪問壓力 Redis與mysql數據庫不同步的問題
4.Redis幫助實現計數器
5.分佈式鎖
6.延遲操作 分佈式消息中間件
注意：Redis官方是沒有windows版本的，只有linux，這時候因爲 在nio中epoll只有linux操作系統獨有
2.Redis線程模型?
Redis的採用NIO的IO多路複用原則,也就是一個線程維護多個不同的Redis客戶端連接,從而提高處理
併發效率和保證線程安全問題.底層採用linux操作系統的epoll技術避免空輪詢.
3.Redis數據結構?
String類型、Hsh類型、List類型、Set類型 、Sorted-Sets
String: 存儲 set key value ; 獲取 get key
Hsh: 存儲 hmset key zhang 28 li 27 liu 23; 獲取 hget key zhang/li/liu
list: 存儲 lpush key xiaomi xiaojun xiaoqiang ;獲取 lrange key 0(開始位置) 3(結束)
移出第一個元素並獲得: lpop key
set: 存儲 sadd key xiao1 xiao2 xiao3 xiao3(不能重複,無序) 存儲3個元素
獲取 smembers key
sortset:存儲 zadd key 1 zhang zadd key 2 li zadd key 3 zhang
(序號 值 ;有序的,值不能重複,重複存入,序號會覆蓋之前序號,取值按照序號排序)
獲取 zrange key 0 10 withscores(帶上此參數,取值包含序號)
4.SpringBoot整合redis使用注意事項:
1.使用對象必須序列化 implements Serializable
2. private RedisTemplate<String ,Object> redisTemplate;使用@Resource注入,
不能使用@Autowired,因爲按照類型找的autoWired找不到這種泛型類
5.Mysql和Redis的數據不同步的問題如何解決?
方式一 直接清理Redis的緩存,重新查詢數據庫即可.
方式二 直接採用MQ訂閱mysql binlog日誌文件增量同步到redis中.
方式三 使用alibaba的canal框架
6.Redis的持久化機制?
大部分的緩存框架都會有基本功能淘汰策略,持久機制.
Redis的持久化的機制有兩種:
AOF(增量):基於數據日誌操作實現的持久化. 開啓方式:redis.conf中 appendonly改爲 yes
AOF的三種同步方式:
appendfsync always 每次有數據修改發生時都會寫入AOF文件,能夠數據不丟失,
但是效率非常低.例1S1000個請求,就會顯得低效
appendfsync everysec 每秒鐘同步一次,該策略爲AOF的缺省(默認)策略(缺點:1秒內數據可能丟失)
appendfsync no 從不同步,高效但是數據不會被持久化
建議最好使用everysec既能夠保證數據的同步,效率還可以.
RDB(默認,全量):採用定時持久化機制,但是服務器因爲某種原因宕機可能會數據丟失.
全量同步和增量同步區別:
全量:就是每天定時(避開高峯期)或者是採用一種週期的實現將數據拷貝另外一個地方.頻率不是很大,但是可能會造
成數據的丟失.
增量:增量同步採用行爲操作對數據的實現同步,頻率非常高,對服務器同步的壓力非常大,能保證數據不丟失.
7.RDB和AOF同步的區別?
1.RDB屬於全量同步(定時同步)
優點:同步效率非常高 缺點:數據可能會丟失
2.AOF屬於增量同步 有點偏向實時
優點:同步效率稍稍有些低,最多隻會丟失1s中的數據
平衡點:既要求效率高,數據不丟失,肯定使用AOFd everysec
8.Redis六種淘汰策略? 設置Redis 內存大小的限制，我們可以設置maxmemory 比如：maxmemory 300mb
noeviction：當內存使用達到閾值的時候，執行命令直接報錯
allkeys-lru：在所有的key中，優先移除最近未使用的key。(推薦)
volatile-lru：在設置了過期時間的鍵空間中，優先移除最近未使用的key。
allkeys-random：在所有的key中，隨機移除某個key。
volatile-random：在設置了過期時間的鍵空間中，隨機移除某個key。
volatile-ttl：在設置了過期時間的鍵空間中，具有更早過期時間的key優先移除。
9.Redis事務操作
1.Multi : 開啓事務
2.EXEC : 提交事務
3.Watch : 可以監聽一個或者多個key,在提交事務之前是否有發生了變化,如果發生了變化就不會提交事務,
沒有發生變化纔可以提交事務.(版本號 ,樂觀鎖)
4.Discard : 取消提交事務 (注意:redis官方是沒有提供回滾方法,只提供了取消事務)
在Redis中使用multi對key開啓事務,其他的線程開始可以對該key執行set操作.
(該key的value最終值爲最後一個提交事務對此key賦的值)
Watch監聽我們的key在提交事務之前是否有發生過變化,如果有發生過變化時無法提交數據的.
10.取消事務和回滾有什麼區別呢?
1.mysql中開啓事務,對該行數據上行鎖 commit提交事務
回滾:對事物取消和行鎖都會撤銷
redis沒有回滾,單純取消事務(不提交事務) 不上鎖
11.什麼是分佈式鎖?
1.本地鎖:在多個線程中,保證只有一個線程執行(線程安全的問題)
2.分佈式鎖:在分佈式中,保證只有一個jvm執行(多個jvm線程安全問題)
如果我們服務器是集羣的時候,定時任務可能會重複執行,可以採用分佈式鎖解決.
12.分佈式鎖實現方案:
1.基於數據庫方式實現(low不用)
2.基於ZK方式實現,採用臨時節點+事件通知
3.基於Redis方式實現, setNX方式
13.解決分佈式鎖核心思路?
1.獲取鎖: 多個不同的jvm同時創建一個相同的標記(全局唯一的(Setnx命令,redis的key必須保證是唯一的))
,只要誰能夠創建成功,誰就能獲取鎖.
2.釋放鎖: (對我們的redis的key設置一個有效期,或者主動刪除key),可以靈活自動釋放該全局唯一的標記,
其他jvm重新進入到獲取鎖資源.
3.超時鎖, 等待獲取鎖的超時時間 ,已經獲取到鎖,設置鎖的有效期
14.redis主從複製原理過程?
1.需要在從redis服務器上配置slaveof 指向主redis服務器ip地址和端口號和密碼.
2.從redis服務器和主redis服務器建立Socket長連接
3.採用全量和增量形式將數據同步給從Redis服務器
全量:從Redis首次啓動的時候(二進制執行dump文件) rdb
增量:主Redis每次有新的set請求時候aof日誌文件
15.redis主從複製有哪些缺陷?
如果主的節點宕機之後,可能會導致整個redis服務不能夠實現寫操作,需要我們人爲重新修改新的主的操作.
16.什麼是哨兵機制?
就是解決我們在主從複製中,選舉問題.
17.Redis哨兵底層原理?
1.哨兵機制每隔10秒時間,只需要配置監聽我們的主(Master)的Redis服務器,就可以採用遞歸的形式獲取到
整個redis集羣服務列表,原理就是info replication
2.哨兵不建議單臺,哨兵的集羣數量建議和Redis服務數量一致.
3.Redis哨兵機制底層是如何實現一個羣體呢?多個哨兵都會同時執行監聽到同一個master節點,訂閱相同
通道(主題),有新的哨兵加入的時候都會將自己服務器的信息發送到主題中,隨後相互實現建立長連接.
4.master節點如果宕機時候 ,如何實現選舉策略?
單個哨兵會向主master節點發送ping的命令,如果這時候master節點沒有及時的響應的話,這時候單個哨兵
會認爲該master主觀不可用狀態;這時候單個哨兵會通知其他的哨兵去確認該master節點是否是宕機狀態,
如果有超過>=配置文件配置 認爲宕機狀態,就開始實現重新選舉新的領導.
18.Redis安全相關內容
緩存穿透:緩存穿透是指使用指定key(不存在的key),頻繁的高併發查詢,導致緩存無法命中;
每次的查詢都會一直查詢數據庫 ,那麼這時候對我們的數據庫壓力是非常大的.
(例:根據id查信息,使用一個無效的id不停的高併發查詢.就會繞過緩存,且數據庫查不到數據也無法保存到redis)
解決方案:1.接口實現api的限流 , 防禦ddos攻擊.接口頻率限制 (網關實現黑名單)
2.從數據庫和redis如果都查詢不到數據情況下,將數據庫的空值寫入到緩存中,
加上短時間的有效期(只適合單個key)
3.布隆過濾器
緩存擊穿:
熱點key:經常使用到key
在高併發的情況下.當一個熱點key過期時,因爲訪問該key請求過多,多個請求同時發現改緩存key過期,
這時候同時查詢數據庫,同時將數據庫內容放入到我們的redis緩存中,對我們數據庫壓力非常大.
解決方案: 1.使用分佈式鎖技術:多個請求同時只要誰能夠獲取到鎖,誰就能夠去查詢數據庫查詢,
將數據查詢的結果放入redis中,沒有獲取到鎖的請求先等待;獲取到鎖的請求將數據寫入
成功到redis中,通知沒有獲取鎖的請求直接從redis獲取數據即可.(適合服務器集羣)
2.本地鎖與分佈式鎖一樣的;
3.軟過期 ,對熱點key設置無限有效期或者異步延長時間
緩存雪崩:
緩存雪崩指的就是我們的redis服務器重啓(沒有持久化)或者是大量的key集中失效,
突然對我們的數據庫壓力非常大
解決思路:過期時間隨機或者是設置不一樣的過期時間;
19.傳統的哨兵集羣方式存在哪些缺陷?
1.redis的哨兵集羣方式,每個節點都保存相同的同步數據,可能會存在冗餘的數據;
其次只能允許有一個主的節點;屬於中心化集羣;
20.Redis Cluster 從3.0開始是Redis官方推出一種去中心化的集羣方式.採用hash槽分片的將數據存放到多個
不同的Redis中,從而可以去減少冗餘的數據.
核心原理:
採用hash槽,預先分配16384個卡槽,並且將卡槽分配到具體Redis的節點,通過key進行crc16(key)%16384=卡槽
可以根據卡槽存到具體Redis節點,注意一個卡槽可以存放多個不同的key.只有主的節點纔會分配卡槽,
從節點沒有卡槽.
卡槽作用:
決定key存放具體的服務器位置,從而實現均攤存放數據.類似我們的數據庫中具體的分表, 優點:動態實現擴容和縮容;