1.Redis支援的資料型別？

　　Redis支援五種資料型別：string（字串），hash（雜湊），list（列表），set（集合）及zset(sorted set：有序集合)。

2.什麼是Redis持久化？Redis有哪幾種持久化方式？優缺點是什麼？

　　redis提供兩種方式進行持久化，一種是RDB持久化（原理是將Reids在記憶體中的資料庫記錄定時dump到磁碟上的RDB持久化），另外一種是AOF（append only file）持久化（原理是將Reids的操作日誌以追加的方式寫入檔案）。

　　RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，實際操作過程是fork一個子程序，先將資料集寫入臨時檔案，寫入成功後，再替換之前的檔案，用二進位制壓縮儲存。

AOF持久化以日誌的形式記錄伺服器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文字的方式記錄，可以開啟檔案看到詳細的操作記錄。

二者優缺點

RDB存在哪些優勢呢？

1). 一旦採用該方式，那麼你的整個Redis資料庫將只包含一個檔案，這對於檔案備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近24小時的資料，同時還要每天歸檔一次最近30天的資料。通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢復。
2). 對於災難恢復而言，RDB是非常不錯的選擇。因為我們可以非常輕鬆的將一個單獨的檔案壓縮後再轉移到其它儲存介質上。

3). 效能最大化。對於Redis的服務程序而言，在開始持久化時，它唯一需要做的只是fork出子程序，之後再由子程序完成這些持久化的工作，這樣就可以極大的避免服務程序執行IO操作了。

4). 相比於AOF機制，如果資料集很大，RDB的啟動效率會更高。

RDB又存在哪些劣勢呢？

1). 如果你想保證資料的高可用性，即最大限度的避免資料丟失，那麼RDB將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁碟的資料都將丟失。

2). 由於RDB是通過fork子程序來協助完成資料持久化工作的，因此，如果當資料集較大時，可能會導致整個伺服器停止服務幾百毫秒，甚至是1秒鐘。

AOF的優勢有哪些呢？
1). 該機制可以帶來更高的資料安全性，即資料永續性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事實上，每秒同步也是非同步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘之內修改的資料將會丟失。而每修改同步，我們可以將其視為同步持久化，即每次發生的資料變化都會被立即記錄到磁碟中。可以預見，這種方式在效率上是最低的。至於無同步，無需多言，我想大家都能正確的理解它。

2). 由於該機制對日誌檔案的寫入操作採用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞日誌檔案中已經存在的內容。然而如果我們本次操作只是寫入了一半資料就出現了系統崩潰問題，不用擔心，在Redis下一次啟動之前，我們可以通過redis-check-aof工具來幫助我們解決資料一致性的問題。

3). 如果日誌過大，Redis可以自動啟用rewrite機制。即Redis以append模式不斷的將修改資料寫入到老的磁碟檔案中，同時Redis還會建立一個新的檔案用於記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證資料安全性。

4). AOF包含一個格式清晰、易於理解的日誌檔案用於記錄所有的修改操作。事實上，我們也可以通過該檔案完成資料的重建。

AOF的劣勢有哪些呢？

1). 對於相同數量的資料集而言，AOF檔案通常要大於RDB檔案。RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。

2). 根據同步策略的不同，AOF在執行效率上往往會慢於RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效。

二者選擇的標準，就是看系統是願意犧牲一些效能，換取更高的快取一致性（aof），還是願意寫操作頻繁的時候，不啟用備份來換取更高的效能，待手動執行save的時候，再做備份（rdb）。rdb這個就更有些 eventually consistent的意思了。

常用配置
RDB持久化配置：
Redis會將資料集的快照dump到dump.rdb檔案中。此外，我們也可以通過配置檔案來修改Redis伺服器dump快照的頻率，在開啟6379.conf檔案之後，我們搜尋save，可以看到下面的配置資訊：

save 900 1 #在900秒(15分鐘)之後，如果至少有1個key發生變化，則dump記憶體快照。

save 300 10 #在300秒(5分鐘)之後，如果至少有10個key發生變化，則dump記憶體快照。

save 60 10000 #在60秒(1分鐘)之後，如果至少有10000個key發生變化，則dump記憶體快照。

AOF持久化配置：
在Redis的配置檔案中存在三種同步方式，它們分別是：

appendfsync always #每次有資料修改發生時都會寫入AOF檔案。

appendfsync everysec #每秒鐘同步一次，該策略為AOF的預設策略。

appendfsync no #從不同步。高效但是資料不會被持久化。

3.Redis 有哪些架構模式？講講各自的特點
　　單機版，主從複製，哨兵模式，叢集（proxy 型），叢集（直連型）

　　https://www.cnblogs.com/it-dennis/p/12571261.html

4.使用過Redis分散式鎖麼，它是怎麼實現的？

public class RedisTool {

    private static final Long RELEASE_SUCCESS = 1L;
    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 嘗試獲取分散式鎖
     * @param jedis Redis客戶端
     * @param lockKey 資源id
     * @param requestId 請求標識
     * @param expireTime 超期時間
     * @return 是否獲取成功
     */
    public static boolean tryGetLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

    /**
     * 釋放分散式鎖
     * @param jedis Redis客戶端
     * @param lockKey 資源id
     * @param requestId 請求標識
     * @return 是否釋放成功
     */
    public static boolean unLock(Jedis jedis, String resourceId, String requestId) {

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(resourceId), Collections.singletonList(requestId));

        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;
    }
}

5.使用過Redis做非同步佇列麼，你是怎麼用的？有什麼缺點？

1, 使用List作為佇列，RPUSH生產訊息，LPOP消費訊息

缺點：沒有等待佇列裡有值就直接消費

彌補：可以通過在應用層引入Sleep機制去呼叫LPOP去重試（BLPOP key [keys ...] timeout：阻塞直到佇列有訊息或者超時，當 timeout 為 0 是表示阻塞時間無限制。）

2,使用pub/sub：主題訂閱者模式

EventProducer：事件生產者，面向client，使用者進行操作後如果會有後續非同步操作，則會將使用者此次操作的事件加入訊息佇列，fire/push 意思是點燃這個事件，至於它啥時候爆炸（被另一執行緒 handler 處理）主執行緒就不管了，主執行緒只關心 fire/push操作。
EventModel：事件模型，下圖中的每個顏色小塊代表一種事件模型，裡面可以定義事件所屬的種類、與該事件相關的物件id、具體內容等資訊。即事件是由誰產生的、將要影響到誰、影響的內容是什麼等...
訊息佇列：具體存放訊息事件的資料結構，可以是Redis list，也可以是Java BlockingQueue等。這裡選擇Redis list實現。
EentConsumer：另開執行緒對訊息佇列中的事件進行處理，我們需要在系統初始化後將所有的Handler註冊進來（建立事件型別與Handler的對映），之後根據相應的事件找到對應的Handler進行處理。
EventHandler：具體處理事件的介面，我們可以實現不同的事件處理業務的具體Handler。

# 監聽頻道
SUBSCRIBE channel [channel ...]
# 往指定頻道釋出訊息
PUBLISH channel message

缺點：訊息的釋出是無狀態的，無法保證可達

參考：https://www.jianshu.com/p/f442962ceb98

6.什麼是快取穿透？如何避免？什麼是快取雪崩？如何避免？

快取穿透：使用者想要查詢一個數據，發現redis記憶體資料庫沒有，也就是快取沒有命中，於是向持久層資料庫查詢。發現也沒有，於是本次查詢失敗。當用戶很多的時候，快取都沒有命中，於是都去請求了持久層資料庫。這會給持久層資料庫造成很大的壓力，這時候就相當於出現了快取穿透。

快取擊穿：是指一個key非常熱點，在不停的扛著大併發，大併發集中對這一個點進行訪問，當這個key在失效的瞬間，持續的大併發就穿破快取，直接請求資料庫，就像在一個屏障上鑿開了一個洞。

快取雪崩：快取層出現了錯誤，不能正常工作了。於是所有的請求都會達到儲存層，儲存層的呼叫量會暴增，造成儲存層也會掛掉的情況。

如何避免：

1，對所有可能查詢的引數以hash形式儲存，當用戶想要查詢的時候，使用布隆過濾器發現不在集合中，就直接丟棄，不再對持久層查詢

2，當儲存層不命中後，即使返回的空物件也將其快取起來，同時會設定一個過期時間，之後再訪問這個資料將會從快取中獲取，保護了後端資料來源；

3，redis高可用，限流降級，資料預熱，不同的key，設定不同的過期時間

7.Redis常用命令

登入 redis-cli -p 5566 -a password
檢查key是否存在 EXISTS key
搜尋某關鍵字 KSYS *4
返回一個Key所影響的vsl的型別 TYPE key

1 String
設定一個鍵的值 SET key value
獲取一個建的值 GET key
刪除鍵對 DEL key
同時獲取多個 mget key1 key2

2 Hash
設定一個hash HMSET key valueKey value --<key,<valueKey,value>>
獲取hash所有key&value HGETALL key
獲取hash所有key HKEYS key
獲取hash所有keu的vslue HVALS key
獲取hash內鍵值對的長度 HLEN key
給一個hash的某個鍵值對賦值 HSET key valueKey value
當hash中valueKey不存在時賦值 HSETNX key valueKey value

3 List
給list賦值 LPUSH listName value
按照索引取值 LINDEX listName 1

8.為什麼Redis 單執行緒卻能支撐高併發？

純記憶體操作
核心是基於非阻塞的 IO 多路複用機制
單執行緒反而避免了多執行緒的頻繁上下文切換問題

redis 內部使用檔案事件處理器 file event handler，這個檔案事件處理器是單執行緒的，所以 redis 才叫做單執行緒的模型。

它採用 IO 多路複用機制同時監聽多個 socket，根據 socket 上的事件來選擇對應的事件處理器進行處理。

檔案事件處理器的結構包含 4 個部分：

• • 多個 socket
  • IO 多路複用程式
  • 檔案事件分派器
  • 事件處理器（連線應答處理器、命令請求處理器、命令回覆處理器）

9.說說Redis的記憶體淘汰策略

設定Redis最大佔用記憶體大小為100M
maxmemory 100mb

獲取redis的記憶體淘汰策略：config get maxmemory-policy

LFU一共有兩種策略：

• volatile-lfu：在設定了過期時間的key中使用LFU演算法淘汰key
• allkeys-lfu：在所有的key中使用LFU演算法淘汰資料

#最大記憶體策略：當到達最大使用記憶體時，你可以在下面5種行為中選擇，Redis如何選擇淘汰資料庫鍵，當記憶體不足以容納新寫入資料時

# volatile-lru -> remove the key with an expire set using an LRU algorithm
# volatile-lru ：在設定了過期時間的鍵空間中，移除最近最少使用的key。這種情況一般是把 redis 既當快取，又做持久化儲存的時候才用。

# allkeys-lru -> remove any key according to the LRU algorithm
# allkeys-lru ： 移除最近最少使用的key （推薦）

# volatile-random -> remove a random key with an expire set
# volatile-random ： 在設定了過期時間的鍵空間中，隨機移除一個鍵，不推薦

# allkeys-random -> remove a random key, any key
# allkeys-random ： 直接在鍵空間中隨機移除一個鍵，弄啥叻

# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
# volatile-ttl ： 在設定了過期時間的鍵空間中，有更早過期時間的key優先移除 不推薦

# noeviction -> don't expire at all, just return an error on write operations
# noeviction ： 不做過鍵處理，只返回一個寫操作錯誤。 不推薦

# 上面所有的策略下，在沒有合適的淘汰刪除的鍵時，執行寫操作時，Redis 會返回一個錯誤。下面是寫入命令：
#       At the date of writing these commands are: set setnx setex append
#       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
#       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
#       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
#       getset mset msetnx exec sort

# 過期策略預設是：
# The default is:
# maxmemory-policy noeviction

10.Redis的併發競爭問題如何解決?

多客戶端同時併發寫一個key，可能本來應該先到的資料後到了，導致資料版本錯了。或者是多客戶端同時獲取一個key，修改值之後再寫回去，只要順序錯了，資料就錯了。比如：一個key的值是1，本來按順序修改為2,3,4，最後是4，但是順序變成了4,3,2，最後變成了2.

解決方法：

方案1

利用redis自帶的incr命令，具體用法看這裡http://doc.redisfans.com/string/incr.html。

方案2

可以使用獨佔鎖的方式，類似作業系統的mutex機制。（網上有例子，http://blog.csdn.net/black_ox/article/details/48972085 不過實現相對複雜，成本較高）

方案3

使用樂觀鎖的方式進行解決（成本較低，非阻塞，效能較高）

如何用樂觀鎖方式進行解決？

本質上是假設不會進行衝突，使用redis的命令watch進行構造條件。虛擬碼如下：

watch price

get price $price

$price = $price + 10

multi

set price $price

exec

解釋一下：

watch這裡表示監控該key值，後面的事務是有條件的執行，如果從watch的exec語句執行時，watch的key對應的value值被修改了，則事務不會執行。

具體看Redis的事務功能詳解這篇文章裡的watch命令介紹。

方案4

這個是針對客戶端來的，在程式碼裡要對redis操作的時候，針對同一key的資源，就先進行加鎖（java裡的synchronized或lock）。

方案5

利用redis的setnx實現內建的鎖。