redis
常見問題做乙個總結，希望能夠彌補大家的知識盲點。
使用 redis 有什麼缺點
單執行緒的 redis 為什麼這麼快
redis 的資料型別，以及每種資料型別的使用場景
redis 的過期策略以及記憶體淘汰機制
redis 和資料庫雙寫一致性問題
如何應對快取穿透和快取雪崩問題
如何解決 redis 的併發競爭 key 問題
為什麼使用 redis
效能忽然想聊一下這個迅速響應的標準。根據互動效果的不同，這個響應時間沒有固定標準。
"在理想狀態下，我們的頁面跳轉需要在瞬間解決，對於頁內操作則需要在剎那間解決。
根據《摩訶僧祗律》記載：
一剎那者為一念，二十念為一瞬，二十瞬為一彈指，二十彈指為一羅預，二十羅預為一須臾，一日一夜有三十須臾。
併發使用 redis 有什麼缺點
快取雪崩問題
快取擊穿問題
快取的併發競爭問題
單執行緒的 redis 為什麼這麼快
單執行緒操作，避免了頻繁的上下文切換
採用了非阻塞 i/o 多路復用機制
我們現在要仔細的說一說 i/o 多路復用機制，因為這個說法實在是太通俗了，通俗到一般人都不懂是什麼意思。
經營方式一
隨著快遞的增多，快遞員也越來越多，小曲發現快遞店裡越來越擠，沒辦法僱傭新的快遞員了。
快遞員之間的協調很花時間。
經營方式二
每個快遞→每個 socket(i/o 流)
快遞的送達地點→socket 的不同狀態
客戶送快遞請求→來自客戶端的請求
小曲的經營方式→服務端執行的**
一輛車→cpu 的核數
每個 i/o 流(快遞)都有乙個新的執行緒(快遞員)管理。
經營方式二就是 i/o 多路復用。
只有單個執行緒(乙個快遞員)，通過跟蹤每個 i/o 流的狀態(每個快遞的送達地點)，來管理多個 i/o 流。
redis 的資料型別，以及每種資料型別的使用場景
string
hash
list
setsorted set
redis 的過期策略以及記憶體淘汰機制
為什麼不用定時刪除策略
定期刪除+惰性刪除是如何工作
於是，惰性刪除派上用場。
這樣，redis
的記憶體會越來越高。那麼就應該採用記憶體淘汰機制。
# maxmemory-policy volatile-lru
當記憶體不足以容納新寫入資料時，新寫入操作會報錯。應該沒人用吧。
allkeys-lru：
當記憶體不足以容納新寫入資料時，在鍵空間中，移除最近最少使用的 key。推薦使用，目前專案在用這種。
allkeys-random：
當記憶體不足以容納新寫入資料時，在鍵空間中，隨機移除某個 key。應該也沒人用吧，你不刪最少使用 key，去隨機刪。
volatile-lru：
當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，移除最近最少使用的 key。這種情況一般是把 redis 既當快取，又做持久化儲存的時候才用。不推薦。
volatile-random：
當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，隨機移除某個 key。依然不推薦。
volatile-ttl：
當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，有更早過期時間的 key 優先移除。不推薦。
redis 和資料庫雙寫一致性問題
首先，採取正確更新策略，先更新資料庫，再刪快取。其次，因為可能存在刪除快取失敗的問題，提供乙個補償措施即可，例如利用訊息佇列。
如何應對快取穿透和快取雪崩問題
即黑客故意去請求快取中不存在的資料，導致所有的請求都懟到資料庫上，從而資料庫連線異常。
快取失效的時候，先去獲得鎖，得到鎖了，再去請求資料庫。沒得到鎖，則休眠一段時間重試。
採用非同步更新策略，無論 key 是否取到值，都直接返回。
value 值中維護乙個快取失效時間，快取如果過期，非同步起乙個執行緒去讀資料庫，更新快取。需要做快取預熱(專案啟動前，先載入快取)操作。
提供乙個能迅速判斷請求是否有效的攔截機制，
比如，利用布隆過濾器，內部維護一系列合法有效的 key。迅速判斷出，請求所攜帶的 key 是否合法有效。如果不合法，則直接返回。
即快取同一時間大面積的失效，這個時候又來了一波請求，結果請求都懟到資料庫上，從而導致資料庫連線異常。
加上乙個隨機值，避免集體失效。
使用互斥鎖，
但是該方案吞吐量明顯下降了。
雙快取。
我們有兩個快取，快取 a 和快取 b。快取 a 的失效時間為 20 分鐘，快取 b 不設失效時間。自己做快取預熱操作。
然後細分以下幾個小點：
從快取 a 讀資料庫，有則直接返回；a 沒有資料，直接從 b 讀資料，直接返回，並且非同步啟動乙個更新執行緒，更新執行緒同時更新快取 a 和快取 b。
如何解決 redis 的併發競爭 key 問題
如果對這個 key 操作，不要求順序
如果對這個 key 操作，要求順序
系統a key 1
系統b key 1
系統c key 1
總結
為什麼分布式一定要有Redis
使用 redis 有什麼缺點 單執行緒的 redis 為什麼這麼快 redis 的資料型別，以及每種資料型別的使用場景 redis 的過期策略以及記憶體淘汰機制 redis 和資料庫雙寫一致性問題 如何應對快取穿透和快取雪崩問題 如何解決 redis 的併發競爭 key 問題 為什麼使用 redis...
分布式為什麼使用Redis
在專案中使用 redis，主要考慮兩個角度 效能和併發。如果只是為了分布式鎖這些其他功能，還有其他中介軟體 zookpeer 等代替，並非一定要使用 redis。效能 如下圖所示，我們在碰到需要執行耗時特別久，且結果不頻繁變動的 sql，就特別適合將執行結果放入快取。這樣，後面的請求就去快取中讀取，...
閘道器是什麼 為什麼微服務一定要有閘道器
服務閘道器 路由 過濾器1 路由 接收一切外界請求，到後端的微服務上去 2 過濾器 在服務網關中可以完成一系列的橫切功能，例如許可權校驗 限流以及監控等，這些都可以通過過濾器完成 其實路由 也是通過過濾器實現的 上述所說的橫切功能 以許可權校驗為例 可以寫在三個位置 第一種，缺點太明顯，基本不用 第...