redis基礎面試題 1

2.redis

3.快取問題及解決方案

3.2 快取穿透&解決方案

3.3 快取擊穿&解決方案

對於互動的要求，曾經聽過一句話：「在理想狀態下，我們的頁面跳轉需要在瞬間解決，對於頁內操作則需要在剎那間解決。另外，超過一彈指的耗時操作要有進度提示，並且可以隨時中止或取消，這樣才能給使用者最好的體驗。」

那麼瞬間、剎那、一彈指具體是多少時間呢？根據《摩訶僧祗律》記載：

一剎那者為一念，二十念為一瞬，二十瞬為一彈指，二十彈指為一羅預，二十羅預為一須臾，一日一夜有三十須臾。

那麼，經過周密的計算，一瞬間為0.36 秒,一剎那有 0.018 秒.一彈指長達 7.2 秒。

為了達到這個響應時間要求，所有的資料都走伺服器獲取顯然是滿足不了要求的。前端對於靜態資源和的快取，cdn和閘道器對於伺服器位址的快取，伺服器對於資料的快取，nosql對於資料庫的快取對於現如今大流量高併發的業務場景具有很好的支撐作用

redis是完全開源免費的，用c語言編寫的，遵守bsd協議，是乙個高效能的(key/value)分布式記憶體資料庫，基於記憶體執行並支援持久化的nosql資料庫，是當前最熱門的nosql資料庫之一,也被人們稱為資料結構伺服器

i/o多路復用機制是一種非阻塞的io模型，在netty和reactor模型中都有廣泛的應用。我們的redis-client在操作的時候，會產生具有不同事件型別的socket。在服務端，有一段i/o多路復用程式，將其置入佇列之中。然後，檔案事件分派器，依次去佇列中取，**到不同的事件處理器中。

需要說明的是，這個i/o多路復用機制，redis還提供了select、epoll、evport、kqueue等多路復用函式庫，也就是不同的selector模型。具體的後續會重新開一篇文章重點介紹i/o多路復用模型。

2.5.1 redis過期策略

2.5.2 為什麼不用定時刪除策略?

2.5.3 該策略底層的工作原理

2.5.4 為什麼還需要記憶體淘汰機制

定期刪除+惰性刪除也是有問題的，如果定期刪除沒刪除key。然後你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的記憶體會越來越高。這就是為什麼我們需要記憶體淘汰機制。

在redis.conf中有一行配置maxmemory-policy volatile-lru，該配置就是配記憶體淘汰策略的，常見的型別有以下幾種：

3.1.1 概念

快取雪崩是指在我們設定快取時採用了相同的過期時間，導致快取在某一時刻同時失效，請求全部**到db，db瞬時壓力過重雪崩。

3.1.2 解決方案3.2.1 概念

訪問乙個一定不存在的資料，這將導致這個不存在的資料每次請求都要查詢資料庫，在流量大時，可能db就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。比如這條資料在資料庫本來就不存在，我們查詢不到也就不會放到快取中，這種就是有風險的。

3.2.2 解決方案3.3.1 概念

對於一些設定了過期時間的key，如果這些key可能會在某些時間點被超高併發地訪問，是一種非常「熱點」的資料。如果快取失效了，超高併發的訪問也會同時落到資料庫，導致db瞬時壓力過重。這個和快取雪崩的區別在於這裡針對某一key快取，前者則是很多key。

3.3.2 解決方案

我們的目標是：盡量少的執行緒構建快取(甚至是乙個) + 資料一致性 + 較少的潛在危險。