Redis的總結

1.單線程的redis爲何這麼快：

redis純內存操做；單線程操做，避免了頻繁的上下文切換；採用了非阻塞I/O多路複用機制。（I/O多路複用：單線程經過跟蹤每一個I/O流的狀態來管理多個I/O流）

1.redis和數據庫雙寫一致性問題：

一致性問題是分佈式常見問題，還能夠分爲最終一致性和強一致性。數據庫和緩存雙寫，就必然會存在不一致的問題，若是對於數據有強一致性要求，就不能放緩存，咱們所作的一切只能夠保證最終一致性。咱們所作的方案其實從根本上來講，只是能夠下降不一致發放的機率，並不會避免。所以若是有強一致性要求的數據，不能放緩存。

首先，採起正確的更新策略，先更新數據庫，再刪除緩存。其次有可能會出現刪除緩存失敗的問題，能夠利用消息隊列進行補償措施。

2.redis的過時策略以及內存淘汰機制：

redis採用 按期刪除+惰性刪除的策略，按期刪除：redis默認每隔100ms檢查是否有過時的key,有過時的key則刪除。須要說明的是redis不是將全部的key全都掃一次，而是隨機進行檢查，這樣的話會有很對key到期而沒有刪除。此時惰性刪除就會排上用處，當咱們獲取某個key的時候，redis就會檢查一下，若是這個key設置了過時時間而且過時了，就會刪除。即便使用 按期刪除+惰性刪除的策略，也不可能保證全部的key在過時時間到了及時刪除。由於當按期刪除沒有隨機掃到，而且沒有查詢的時候，這些key就不會刪除，這時咱們能夠經過 內存淘汰機制  redis.conf   maxmemory-policy allkeys-lru : 當內存不足的時候，在鍵空間中，移除最近最少使用的key。

 3.如何應對緩存穿透和緩存雪崩問題：

緩存穿透：黑客故意去請求緩存中不存在的數據，致使全部的請求都懟到數據庫上，致使數據庫鏈接異常。

緩存雪崩：緩存同一時間大面積的失效，這個時候又來了一大波請求，結果請求都懟到數據庫上，從而致使數據庫鏈接異常。

緩存雪崩的解決方案：1.給緩存的失效時間加一個隨機值，避免集體失效；2.雙緩存，咱們有兩個緩存A和B。緩存A的失效時間爲20分鐘，緩存B不設置失效時間。本身作預熱操做， 其中：從緩存A中讀取數據，有則直接返回；A沒有數據，直接從B讀取數據，直接返回，而且異步啓動一個更新線程；更新線程同時更新緩存A和緩存B。