java面試---Redis

1. redis 是什麼？都有哪些使用場景？
   Redis是一個開源的 key—value型 單線程非關係型數據庫，支持string、list、set、zset和hash類型數據。
   默認端口:6379
   默認數據庫數量:16
   適用場景：
   1.數據高併發的讀寫
   2.海量數據的讀寫
   3.對擴展性要求高的數據

2. redis 有哪些功能？
   1）、會話緩存（Session Cache）
   2）、全頁緩存（FPC）
   3）、隊列
   4）、排行榜/計數器
   5）、發佈/訂閱

3. redis 和 memecache 有什麼區別？
   1、存儲方式：
   memecache 把數據全部存在內存之中，斷電後會掛掉，數據不能超過內存大小
   redis有部份存在硬盤上，這樣能保證數據的持久性。
   2、數據支持類型：
   redis在數據支持上要比memecache多的多。
   3、使用底層模型不同：
   新版本的redis直接自己構建了VM 機制 ，因爲一般的系統調用系統函數的話，會浪費一定的時間去移動和請求。
   4、運行環境不同：
   redis目前官方只支持LINUX 上去行，從而省去了對於其它系統的支持，這樣的話可以更好的把精力用於本系統 環境上的優化，雖然後來微軟有一個小組爲其寫了補丁。但是沒有放到主幹上

4. redis 爲什麼是單線程的？
   因爲Redis是基於內存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器內存的大小或者網絡帶寬。既然單線程容易實現，而且CPU不會成爲瓶頸，那就順理成章地採用單線程的方案了。

5. 什麼是緩存穿透？怎麼解決？
   緩存穿透是指查詢一個一定不存在的數據，由於緩存是不命中時被動寫的，並且出於容錯考慮，如果從存儲層查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。在流量大時，可能DB就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。
   解決：
   1、在某些特定場景下（登錄），進行驗證碼，這種方法並不是很安全，因爲目前圖像識別技術在很大程度上能夠解決驗證碼的問題，所以僅供簡單使用。
   2、布隆過濾器

6. redis 支持的數據類型有哪些？
   1、string（字符串）
   2、hash（哈希）
   　　Redis hash 是一個鍵值(key=>value)對集合。
   　　Redis hash是一個string類型的field和value的映射表，hash特別適合用於存儲對象。
   3、list（列表）
   　　Redis 列表是簡單的字符串列表，按照插入順序排序。你可以添加一個元素到列表的頭部（左邊）或者尾部（右邊）。
   4、set（集合）
   　　Redis的Set是string類型的無序集合。
   5、zset(sorted set：有序集合)Redis zset 和 set 一樣也是string類型元素的集合,且不允許重複的成員。

7. redis 支持的 java 客戶端都有哪些？
   Redisson,Jedis，lettuce等等，官方推薦使用Redisson。

8. jedis 和 redisson 有哪些區別？
   1.概況對比
   Jedis是Redis的Java實現的客戶端，其API提供了比較全面的Redis命令的支持；Redisson實現了分佈式和可擴展的Java數據結構，和Jedis相比，功能較爲簡單，不支持字符串操作，不支持排序、事務、管道、分區等Redis特性。Redisson的宗旨是促進使用者對Redis的關注分離，從而讓使用者能夠將精力更集中地放在處理業務邏輯上。
   2.編程模型
   Jedis中的方法調用是比較底層的暴露的Redis的API，也即Jedis中的Java方法基本和Redis的API保持着一致，瞭解Redis的API，也就能熟練的使用Jedis。而Redisson中的方法則是進行比較高的抽象，每個方法調用可能進行了一個或多個Redis方法調用。3. 可伸縮性
   Jedis使用阻塞的I/O，且其方法調用都是同步的，程序流需要等到sockets處理完I/O才能執行，不支持異步。Jedis客戶端實例不是線程安全的，所以需要通過連接池來使用Jedis。Redisson使用非阻塞的I/O和基於Netty框架的事件驅動的通信層，其方法調用是異步的。Redisson的API是線程安全的，所以可以操作單個Redisson連接來完成各種操作。
   4 . 數據結構
   Jedis僅支持基本的數據類型如：String、Hash、List、Set、Sorted Set。Redisson不僅提供了一系列的分佈式Java常用對象，基本可以與Java的基本數據結構通用，還提供了許多分佈式服務，其中包括（BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object service, Scheduler service）。在分佈式開發中，Redisson可提供更便捷的方法。
   5 . 第三方框架整合
   1）Redisson提供了和Spring框架的各項特性類似的，以Spring XML的命名空間的方式配置RedissonClient實例和它所支持的所有對象和服務；
   2）Redisson完整的實現了Spring框架裏的緩存機制；
   3 ）Redisson在Redis的基礎上實現了Java緩存標準規範；
   4） Redisson爲Apache Tomcat集羣提供了基於Redis的非黏性會話管理功能。該功能支持Apache Tomcat的6、7和8版。
   5）Redisson還提供了Spring Session會話管理器的實現。

9. 怎麼保證緩存和數據庫數據的一致性？
   採用延時雙刪策略、異步更新緩存(基於訂閱binlog的同步機制)

10. redis 持久化有幾種方式？
    一種RDB持久化（原理是將Reids在內存中的數據庫記錄定時dump到磁盤上的RDB持久化），另外一種是AOF（append only file）持久化（原理是將Reids的操作日誌以追加的方式寫入文件）

11. redis 怎麼實現分佈式鎖？
    獲取鎖的時候，使用setnx加鎖，並使用expire命令爲鎖添加一個超時時間，超過該時間則自動釋放鎖，鎖的value值爲一個隨機生成的UUID，通過此在釋放鎖的時候進行判斷。
    獲取鎖的時候還設置一個獲取的超時時間，若超過這個時間則放棄獲取鎖。
    釋放鎖的時候，通過UUID判斷是不是該鎖，若是該鎖，則執行delete進行鎖釋放。

12. redis 分佈式鎖有什麼缺陷？
    (一)緩存和數據庫雙寫一致性問題
    (二)緩存雪崩問題
    (三)緩存擊穿問題
    (四)緩存的併發競爭問題

13. redis 如何做內存優化？
    一. redisObject對象
    二. 縮減鍵值對象
    三. 共享對象池
    四. 字符串優化
    五. 編碼優化
    六. 控制key的數量

14. redis 淘汰策略有哪些？
    1）voltile-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（驅逐）：禁止驅逐數據

15. redis 常見的性能問題有哪些？該如何解決？
    1.Master寫內存快照
    save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫內存快照。
    2.Master AOF持久化
    如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啓的恢復速度。
    3.Master調用BGREWRITEAOF
    Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會佔大量的CPU和內存資源，導致服務load過高，出現短暫服務暫停現象。
    4.Redis主從複製的性能問題
    第一次Slave向Master同步的實現是：Slave向Master發出同步請求，Master先dump出rdb文件，然後將rdb文件全量傳輸給slave，然後Master把緩存的命令轉發給Slave，初次同步完成。第二次以及以後的同步實現是：Master將變量的快照直接實時依次發送給各個Slave。不管什麼原因導致Slave和Master斷開重連都會重複以上過程。Redis的主從複製是建立在內存快照的持久化基礎上，只要有Slave就一定會有內存快照發生。雖然Redis宣稱主從複製無阻塞，但由於Redis使用單線程服務，如果Master快照文件比較大，那麼第一次全量傳輸會耗費比較長時間，且文件傳輸過程中Master可能無法提供服務，也就是說服務會中斷，對於關鍵服務，這個後果也是很可怕的。
    5.單點故障問題
    由於目前Redis的主從複製還不夠成熟，所以存在明顯的單點故障問題，這個目前只能自己做方案解決，如：主動複製，Proxy實現Slave對Master的替換等

    解決：
    1.Master最好不要做任何持久化工作，包括內存快照和AOF日誌文件，特別是不要啓用內存快照做持久化。
    2.如果數據比較關鍵，某個Slave開啓AOF備份數據，策略爲每秒同步一次。
    3.爲了主從複製的速度和連接的穩定性，Slave和Master最好在同一個局域網內。
    4.儘量避免在壓力較大的主庫上增加從庫
    5.爲了Master的穩定性，主從複製不要用圖狀結構，用單向鏈表結構更穩定，即主從關係爲：Master<–Slave1<–Slave2<–Slave3…，這樣的結構也方便解決單點故障問題，實現Slave對Master的替換，也即，如果Master掛了，可以立馬啓用Slave1做Master，其他不變。