Redis為單線程

1、Redis 有哪些數據類型

• String
• 哈希
• list
• set
• 有序set

2、Redis 內部結構

參考：https://www.cnblogs.com/chenpingzhao/archive/2017/06/10/6965164.html

3、Redis 使用場景

緩存，會話緩存，時效性，訪問頻率，計數器，社交列表，記錄用戶判定信息，交集、並集和差集，熱門列表與排行榜，最新動態等。

4、Redis 持久化機制

• 快照（snapshotting）：將整個Redis內存中的所有的數據遍歷一遍存儲到一個擴展名為rdb的數據文件中。
• AOF（Append onlyfile）
  ：在使用aof時，redis會將每一個收到的寫命令都通過write函數追加到文件中，當redis重啟時會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。

更詳細的說明參考：https://blog.csdn.net/u013905744/article/details/52787413

5、Redis 為什麽是單線程

Redis操作的對象是內存中的數據結構。如果在多線程中操作，那就需要為這些對象加鎖。最終來說，多線程性能有提高，但是每個線程的效率嚴重下降了。而且程序的邏輯嚴重復雜化。Redis的數據結構並不全是簡單的Key-Value，還有列表，hash，map等等復雜的結構，這些結構有可能會進行很細粒度的操作，比如在很長的列表後面添加一個元素，在hash當中添加或者刪除一個對象，等等。這些操作還可以合成MULTI/EXEC的組。這樣一個操作中可能就需要加非常多的鎖，導致的結果是同步開銷大大增加。這還帶來一個惡果就是吞吐量雖然增大，但是響應延遲可能會增加。
6、緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級

• 緩存雪崩：由於原有緩存失效，新緩存未到期間所有原本應該訪問緩存的請求都去查詢數據庫了，而對數據庫CPU和內存造成巨大壓力，嚴重的會造成數據庫宕機。從而形成一系列連鎖反應，造成整個系統崩潰。
• 緩存穿透：是指用戶查詢數據，在數據庫沒有，自然在緩存中也不會有。這樣就導致用戶查詢的時候，在緩存中找不到，每次都要去數據庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的 bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。
• 緩存預熱：系統上線後，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然後再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！
• 緩存更新：除了redis自帶的6種策略，可以根據業務需求自定義清除緩存。
• 緩存降級：當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵數據進行自動降級，也可以配置開關實現人工降級。

詳解參考：https://blog.csdn.net/xlgen157387/article/details/79530877

7、使用緩存的合理性問題

1. 熱點數據，緩存才有價值。
2. 頻繁修改的數據，看情況考慮使用緩存。
3. 數據的不一致
4. 緩存更新機制
5. 緩存可用性
6. 緩存服務降級
7. 緩存預熱
8. 緩存穿透

詳細解析參考：https://blog.csdn.net/diyhzp/article/details/54892358

8、Redis常見的回收策略

1. volatile-lru：從已設置過期時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰。
2. volatile-ttl：從已設置過期時間的數據集（server.db[i].expires）中挑選將要過期的數據淘汰。
3. volatile-random：從已設置過期時間的數據集（server.db[i].expires）中任意選擇數據淘汰。
4. allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰。
5. allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰。
6. no-enviction（驅逐）：禁止驅逐數據

JAVA面試常見問題之Redis篇