1、為什么使用redis

主要是從兩個角度去考慮:性能和并發。當然，redis還具備可以做分布式鎖等其他功能，但是如果只是為了分布式鎖這些其他功能，完全還有其他中間件(如zookpeer等)代替，并不是非要使用redis

性能:我們在碰到需要執行耗時特別久，且結果不頻繁變動的SQL，就特別適合將運行結果放入緩存。這樣，后面的請求就去緩存中讀取，使得請求能夠迅速響應。

并發:在大并發的情況下，所有的請求直接訪問數據庫，數據庫會出現連接異常。這個時候，就需要使用redis做一個緩沖操作，讓請求先訪問到redis，而不是直接訪問數據庫。

2.單線程的redis為什么這么快

(一)純內存操作

(二)單線程操作，避免了頻繁的上下文切換

(三)采用了非阻塞I/O多路復用機制

3、redis的數據類型，以及每種數據類型的使用場景

(1)、String

(2)、hash

(3)、list

(4)、set

(5)、sorted set

4、redis的過期策略以及內存淘汰機制

redis采用的是定期刪除+惰性刪除策略。

為什么不用定時刪除策略?

定時刪除,用一個定時器來負責監視key,過期則自動刪除。雖然內存及時釋放，但是十分消耗CPU資源。在大并發請求下，CPU要將時間應用在處理請求，而不是刪除key,因此沒有采用這一策略.

定期刪除+惰性刪除是如何工作的呢?

定期刪除，redis默認每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。因此，如果只采用定期刪除策略，會導致很多key到時間沒有刪除。

于是，惰性刪除派上用場。也就是說在你獲取某個key的時候，redis會檢查一下，這個key如果設置了過期時間那么是否過期了？如果過期了此時就會刪除。

采用定期刪除+惰性刪除就沒其他問題了么?

不是的，如果定期刪除沒刪除key。然后你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的內存會越來越高。那么就應該采用內存淘汰機制。

在redis.conf中有一行配置

# maxmemory-policy volatile-lru

該配置就是配內存淘汰策略的(什么，你沒配過？好好反省一下自己)

1）noeviction：當內存不足以容納新寫入數據時，新寫入操作會報錯。應該沒人用吧。

2）allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的key。推薦使用

3）allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個key。應該也沒人用吧，你不刪最少使用Key,去隨機刪。

4）volatile-lru：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，移除最近最少使用的key。這種情況一般是把redis既當緩存，又做持久化存儲的時候才用。不推薦

5）volatile-random：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，隨機移除某個key。依然不推薦

6）volatile-ttl：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，有更早過期時間的key優先移除。不推薦

ps：如果沒有設置 expire 的key, 不滿足先決條件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行為, 和 noeviction(不刪除) 基本上一致。

5、使用redis有什么缺點

(一)緩存和數據庫雙寫一致性問題

(二)緩存雪崩問題

(三)緩存擊穿問題

(四)緩存的并發競爭問題