https://blog.csdn.net/weixin_42167717/article/details/106527006 - redis
https://blog.csdn.net/HarderXin/article/details/105224796 - Redis面試題答案整理
https://blog.csdn.net/xuezhiwu001/article/details/105072544 - 緩存穿透、緩存擊穿、緩存雪崩區別和解決方案
https://blog.csdn.net/zzti_erlie/article/details/104655455 - 緩存雪崩，緩存穿透，緩存擊穿出現的原因及解決方案
https://blog.csdn.net/weixin_45749011/article/details/106454525 - Redis -- 高頻面試題
總結：
爲什麼使用緩存?
緩存兩個用途：高性能、高併發
（1）高性能
對於一些需要複雜操作耗時查詢出結果的，確定後期不怎麼變化但是有很多讀的請求的、直接把結果放在緩存中，後面直接讀取緩存就好了(這個使用的場景)
假設有一個場景：一個請求過來之後，各種操作數mysql，查詢很久查詢出一個結果，耗時600ms，但是結果在幾個小時不會變化，或者是變化了不用立即返回給客戶那麼就用緩存
一個600ms的查詢，扔緩存裏，一個key 對應一個value，在查詢的時候就直接從緩存裏拿，2ms ，性能提高300倍
（2）高併發
高峯期請求數據超過1W，mysql支持不好，緩存支持高併發。
爲什麼數據庫不能支撐高併發，緩存可以支撐？
因爲緩存是走的內存，內存就可以支撐大量請求，但是數據庫一般併發請求不超過2000/s
一般公司不會有很大的併發，所以一般都是爲了高性能
注：redis最簡單的使用方法，當用戶的請求訪問查詢接口的時候可以使用設置redis做中間緩存。而更新、插入等操作可以直接訪問數據庫，再寫回redis。。。簡單粗暴~~
緩存使用不當的不良後果
這個其實就是請求更新數據的時候，更新了數據庫的信息，但是沒有立即在redis緩存中更新該字段信息。所以用戶查詢改信息的時候依然是舊信息。
2. 緩存穿透
緩存穿透其實就是用戶發送請求的時候，訪問的是redis緩存中沒有的key值，直接查詢數據庫，但請求數量大的時候。數據庫io出問題。數據庫io能支持並量遠遠小於內存。
解決方法：
（1）這個數據沒有的話，在redis中存儲這個key，返回一個null 。（這個其實就是用戶請求的key值在redis不存在，再查詢數據庫不存在。就相當於立即加個補丁。把key值放入到redis緩存中，當別人再訪問這個key的時候，就只能訪問到緩存中了。。） - 簡稱加補丁
如果有一個IP頻繁的一直訪問這個key 的話 可以判定他是惡意的，監控這個IP，操作這個IP。
（2）在接口層校驗
黑客頻繁更換key訪問，這樣會頻繁訪問數據庫，redis也會頻繁存儲（這個就是惡意操作了。好，你採取發現一個不存在（漏洞）就加一個補丁，那我不斷換你redis沒有存儲的key值發送請求，那你就要不斷打補丁，但是之前就已經請求到數據庫了。這個時候如果把這個ip禁了，就是用戶請求發送來的數據包，檢測數據頭，如果一直是這個ip,直接丟棄）
解決 ： 在redis 和數據庫之間 加一個過濾器，布隆過濾器。
布隆過濾器基本概念：如果想判斷一個元素是不是在一個集合裏，一般想到的是將集合中所有元素保存起來，然後通過比較確定。鏈表、樹、散列表（又叫哈希表，Hash table）等等數據結構都是這種思路。但是隨着集合中元素的增加，我們需要的存儲空間越來越大。同時檢索速度也越來越慢，上述三種結構的檢索時間複雜度分別爲{\displaystyle O(n),O(\log n),O(1)}。
布隆過濾器的原理是，當一個元素被加入集合時，通過K個散列函數將這個元素映射成一個位數組中的K個點，把它們置爲1。檢索時，我們只要看看這些點是不是都是1就（大約）知道集合中有沒有它了：如果這些點有任何一個0，則被檢元素一定不在；如果都是1，則被檢元素很可能在。這就是布隆過濾器的基本思想。
布隆過濾器其實就是把數據庫的primaryKey值數據全部放入到redis緩存中，而value設置爲1，可以大大節約內存。當用戶發送請求的時候，直接在緩存中搜索該值，不存在返回。
3.緩存雪崩
查詢redis的時候 大量的key 同一時間都過期了，結果就是請求直接到數據庫，對數據庫造成壓力，這樣redis失去存在意義，只需要
保證key不同時過期，可以在過期時間之後隨機抽取一個random隨機數字作爲時間，錯開過期時間
如果一個key被頻繁訪問那麼他就是一個熱點key 數據庫數據不會頻繁改變的話，那麼就不設置過期時間
其實就是隨機設置redis中的key值的過期時間，不然大量的key值在同一時間過期。如果這個時間請求忽然暴增，而對應單應的key值直接訪問到數據庫了。。就會出問題。
4.緩存擊穿
緩存擊穿跟緩存雪崩有點類似，不同的是雪崩是大面積的緩存失效，緩存擊穿是一個熱點key，緩存失效的瞬間大併發會擊破緩存直接請求到數據庫。
5、redis併發競爭
就是多個客戶端同事併發寫一個key，可能是本來先到的數據後到了，導致數據版本錯了；
同時獲取一個key進行修改回寫、只要順序錯了數據就錯了。
解決 ： 使用分佈式鎖（zookeeper）
基於zookeeper實現分佈式鎖，確保同一時間只能有一個系統實例在操作某個key，別人不允許讀寫
寫入緩存數據都是從mysql查詢出來的，都得寫入mysql，寫入的時候保存一個時間戳，查詢的時候也查詢出時間戳，寫之前判斷時間戳是否比緩存中的時間戳新，是的話可以寫，否則就不能用舊數據覆蓋新的數據。
6.Redis和Memcached區別
redis支持複雜的數據結構、可以支持更復雜的場景，更好用。
redis原生支持集羣模式
7.爲什麼redis單線程模型效率比較高
7.1、純內存操作
7.2、核心是基於非阻塞IO多路複用機制
7.3、單線程避免了多線程頻繁上線問切換問題，預防多線程可能產生的競爭問題
8.redis數據結構
String（最基本的，在hash和set，zset，list中最基本的就是String）
單值緩存 key String
對想緩存 key json
大小512M
hash （當然去存儲key-value值。查詢速度快，以供用戶請求時查詢）
類似於map的一種結構，主要是存放一些對象
set （去重，set數據結構的特性：不保留相同的key值）
無序集合，自動去重，基於set做交集
zset （排序）
排序
list（分頁查詢，返回一個有序列表。。分頁不用list那用set，string，hash（無序）？）
可以通過 lrange 命令，讀取某個閉區間內的元素，可以基於 list 實現分頁查詢
9.redis 剔除策略
redis過期策略是：定期刪除+惰性刪除
定期刪除是redis 默認每100ms隨機抽取一些設置過期的時間的key，檢查是否過期，過期就刪除；（定期）
獲取key的時候，如果已經過期了，就刪除，不會反悔任何東西
內存淘汰機制（惰性）
allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的 key
10.redis 持久化（其實也就是備份）
1、RDB 快照的形式雪茹磁盤，把整個redis數據存儲到單一文件中，可以做災備，但是在宕機的瞬間快照沒有保存完數據會丟失
2、AOF 日誌文件寫入，支持每秒同步、每次修改同步不同步，運行效率比RDB低
總結：RDB（間隔備份文件），AOF（時刻備份文件）
11.redis高併發
redis不能支撐高併發的瓶頸在哪裏？
單機；單機的redisQPS不會超過10W+
redis主從架構
redis通過主從實現讀寫分離支撐高併發（10W+）
redis架構做成主從架構，一主多從，主負責寫入，並且把數據聽賦值到其他slave節點上，從節點負責讀，所有的讀請求全部走從節點（這個其實就是可以很靈活地分配利用服務器的性能）
可以水平擴容，繼續增加redis slave
redis面試
redis 接口冪
總結：以前也曾看過書，但是沒參與企業級開發，redis只停留在認識上；這一兩個月時間參與需要上線企業開發的項目，感覺真的學習到很多，，後端大佬跑路，剩下我和另一個技術人員負責後端接口的修改和前後端聯調，不斷熟悉項目，而且根據需求，求，和兩個10多年的程序老兵（都有深厚的後端開發經驗，不斷學習他們的開發思想，和不斷接觸新技術，新工具）。經過1年後再看redis，感覺有了更深刻的認識，也是隨着自己的開發經驗上去而慢慢認識的。後序還會做微服務和高併發~~~，值得期待。後序內容再更~