1、Redis持久化策略選擇

1、 如果Redis中的數據完全丟棄也沒有關系(如Redis完全用作DB層數據的cache)，那么無論是單機，還是主從架構，都可以不進行任何持久化。

2、 在單機環境下(對于個人開發者，這種情況可能比較常見)，如果可以接受十幾分鐘或更多的數據丟失，選擇RDB對Redis的性能更加有利;如果只能接受秒級別的數據丟失，應該選擇AOF。

3、 但在多數情況下，我們都會配置主從環境，slave的存在既可以實現數據的熱備，也可以進行讀寫分離分擔Redis讀請求，以及在master宕掉后繼續提供服務。

2、Redis常見性能問題和解決方案：

1、 Master最好不要寫內存快照，如果Master寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務

2、 如果數據比較重要，某個Slave開啟AOF備份數據，策略設置為每秒同步一

3、 為了主從復制的速度和連接的穩定性，Master和Slave最好在同一個局域網

4、 盡量避免在壓力很大的主庫上增加從

5、 主從復制不要用圖狀結構，用單向鏈表結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3…這樣的結構方便解決單點故障問題，實現Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。

3、Redis修改配置不重啟Redis會實時生效嗎?

針對運行實例，有許多配置選項可以通過 CONFIG SET 命令進行修改，而無需執行任何形式的重啟。 從 Redis 2.2 開始，可以從 AOF 切換到 RDB 的快照持久性或其他方式而不需要重啟 Redis。檢索 ‘CONFIG GET *’ 命令獲取更多信息。

但偶爾重新啟動是必須的，如為升級 Redis 程序到新的版本，或者當你需要修改某些目前 CONFIG 命令還不支持的配置參數的時候。

4、Redis過期鍵的刪除策略?

1、 定時刪除:在設置鍵的過期時間的同時，創建一個定時器timer)、讓定時器在鍵的過期時間來臨時，立即執行對鍵的刪除操作。

2、 惰性刪除:放任鍵過期不管，但是每次從鍵空間中獲取鍵時，都檢查取得的鍵是否過期，如果過期的話，就刪除該鍵;如果沒有過期，就返回該鍵。

3、 定期刪除:每隔一段時間程序就對數據庫進行一次檢查，刪除里面的過期鍵。至于要刪除多少過期鍵，以及要檢查多少個數據庫，則由算法決定。

5、Redis與Memcached相比有哪些優勢?

1、 Memcached所有的值均是簡單的字符串，Redis作為其替代者，支持更為豐富的數據類型

2、 Redis的速度比Memcached快很多Redis的速度比Memcached快很多

3、 Redis可以持久化其數據Redis可以持久化其數據

6、Redis持久化的幾種方式

1、 快照(snapshots)

缺省情況情況下，Redis把數據快照存放在磁盤上的二進制文件中，文件名為dump.rdb。你可以配置Redis的持久化策略，例如數據集中每N秒鐘有超過M次更新，就將數據寫入磁盤;或者你可以手工調用命令SAVE或BGSAVE。

工作原理

Redis forks.

子進程開始將數據寫到臨時RDB文件中。

當子進程完成寫RDB文件，用新文件替換老文件。

這種方式可以使Redis使用copy-on-write技術。

2、 AOF

快照模式并不十分健壯，當系統停止，或者無意中Redis被kill掉，最后寫入Redis的數據就會丟失。

這對某些應用也許不是大問題，但對于要求高可靠性的應用來說，Redis就不是一個合適的選擇。Append-only文件模式是另一種選擇。你可以在配置文件中打開AOF模式

3、 虛擬內存方式

當你的key很小而value很大時,使用VM的效果會比較好.因為這樣節約的內存比較大.

當你的key不小時,可以考慮使用一些非常方法將很大的key變成很大的value,比如你可以考慮將key,value組合成一個新的value.

vm-max-threads這個參數,可以設置訪問swap文件的線程數,設置最好不要超過機器的核數,如果設置為0,那么所有對swap文件的操作都是串行的.可能會造成比較長時間的延遲,但是對數據完整性有很好的保證.

自己測試的時候發現用虛擬內存性能也不錯。如果數據量很大，可以考慮分布式或者其他數據庫。

7、為什么Redis需要把所有數據放到內存中?

Redis為了達到最快的讀寫速度將數據都讀到內存中，并通過異步的方式將數據寫入磁盤。

所以Redis具有快速和數據持久化的特征，如果不將數據放在內存中，磁盤I/O速度為嚴重影響Redis的性能。

在內存越來越便宜的今天，Redis將會越來越受歡迎， 如果設置了最大使用的內存，則數據已有記錄數達到內存限值后不能繼續插入新值。

8、Redis集群方案應該怎么做?都有哪些方案?

1、 codis。

目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在 節點數量改變情況下，舊節點數據可恢復到新hash節點。

2、 Redis cluster3.0自帶的集群，特點在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自身支持節點設置從節點。具體看官方文檔介紹。

3、 在業務代碼層實現，起幾個毫無關聯的Redis實例，在代碼層，對key 進行hash計算，然后去對應的Redis實例操作數據。 這種方式對hash層代碼要求比較高，考慮部分包

9、Redis 的回收策略(淘汰策略)

volatile-lru：從已設置過期時間的數據集( server.db[i].expires)中挑選最近最少使用的數據淘汰

volatile-ttl： 從已設置過期時間的數據集( server.db[i].expires) 中挑選將要過期的數據淘汰

volatile-random： 從已設置過期時間的數據集( server.db[i].expires) 中任意選擇數據淘汰

allkeys-lru： 從數據集( server.db[i].dict) 中挑選最近最少使用的數據淘汰

allkeys-random： 從數據集( server.db[i].dict) 中任意選擇數據淘汰

no-enviction( 驅逐) ： 禁止驅逐數據

注意這里的 6 種機制，volatile 和 allkeys 規定了是對已設置過期時間的數據集淘汰數據還是從全部數據集淘汰數據， 后面的 lru、ttl 以及 random 是三種不同的淘汰策略， 再加上一種 no-enviction 永不回收的策略。

使用策略規則：

1、 如果數據呈現冪律分布，也就是一部分數據訪問頻率高，一部分數據訪問頻率 低， 則使用 allkeys-lru

2、 如果數據呈現平等分布， 也就是所有的數據訪問頻率都相同， 則使用allkeys-random

10、AOF常用配置總結

下面是AOF常用的配置項，以及默認值;前面介紹過的這里不再詳細介紹。

1、 appendonly no：是否開啟AOF

2、 appendfilename "appendonly.aof"：AOF文件名

3、 dir ./：RDB文件和AOF文件所在目錄

4、 appendfsync everysec：fsync持久化策略

5、 no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync;如果開啟該選項，可以減輕文件重寫時CPU和硬盤的負載(尤其是硬盤)，但是可能會丟失AOF重寫期間的數據;需要在負載和安全性之間進行平衡

6、 auto-aof-rewrite-percentage 100：文件重寫觸發條件之一

7、 auto-aof-rewrite-min-size 64mb：文件重寫觸發提交之一

8、 aof-load-truncated yes：如果AOF文件結尾損壞，Redis啟動時是否仍載入AOF文件

以上就是“市面上比較全面的redis面試題及答案”，你能回答上來嗎?如果想要了解更多的Java面試題相關內容，可以關注動力節點Java官網。