1、Redis持久化策略選擇

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

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

3、 但在多數(shù)情況下，我們都會配置主從環(huán)境，slave的存在既可以實現(xiàn)數(shù)據(jù)的熱備，也可以進(jìn)行讀寫分離分擔(dān)Redis讀請求，以及在master宕掉后繼續(xù)提供服務(wù)。

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

1、 Master最好不要寫內(nèi)存快照，如果Master寫內(nèi)存快照，save命令調(diào)度rdbSave函數(shù)，會阻塞主線程的工作，當(dāng)快照比較大時對性能影響是非常大的，會間斷性暫停服務(wù)

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

3、 為了主從復(fù)制的速度和連接的穩(wěn)定性，Master和Slave最好在同一個局域網(wǎng)

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

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

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

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

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

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

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

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

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

5、Redis與Memcached相比有哪些優(yōu)勢?

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

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

3、 Redis可以持久化其數(shù)據(jù)Redis可以持久化其數(shù)據(jù)

6、Redis持久化的幾種方式

1、 快照(snapshots)

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

工作原理

Redis forks.

子進(jìn)程開始將數(shù)據(jù)寫到臨時RDB文件中。

當(dāng)子進(jìn)程完成寫RDB文件，用新文件替換老文件。

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

2、 AOF

快照模式并不十分健壯，當(dāng)系統(tǒng)停止，或者無意中Redis被kill掉，最后寫入Redis的數(shù)據(jù)就會丟失。

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

3、 虛擬內(nèi)存方式

當(dāng)你的key很小而value很大時,使用VM的效果會比較好.因為這樣節(jié)約的內(nèi)存比較大.

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

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

自己測試的時候發(fā)現(xiàn)用虛擬內(nèi)存性能也不錯。如果數(shù)據(jù)量很大，可以考慮分布式或者其他數(shù)據(jù)庫。

7、為什么Redis需要把所有數(shù)據(jù)放到內(nèi)存中?

Redis為了達(dá)到最快的讀寫速度將數(shù)據(jù)都讀到內(nèi)存中，并通過異步的方式將數(shù)據(jù)寫入磁盤。

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

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

8、Redis集群方案應(yīng)該怎么做?都有哪些方案?

1、 codis。

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

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

3、 在業(yè)務(wù)代碼層實現(xiàn)，起幾個毫無關(guān)聯(lián)的Redis實例，在代碼層，對key 進(jìn)行hash計算，然后去對應(yīng)的Redis實例操作數(shù)據(jù)。 這種方式對hash層代碼要求比較高，考慮部分包

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

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

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

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

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

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

no-enviction( 驅(qū)逐) ： 禁止驅(qū)逐數(shù)據(jù)

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

使用策略規(guī)則：

1、 如果數(shù)據(jù)呈現(xiàn)冪律分布，也就是一部分?jǐn)?shù)據(jù)訪問頻率高，一部分?jǐn)?shù)據(jù)訪問頻率 低， 則使用 allkeys-lru

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

10、AOF常用配置總結(jié)

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

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和硬盤的負(fù)載(尤其是硬盤)，但是可能會丟失AOF重寫期間的數(shù)據(jù);需要在負(fù)載和安全性之間進(jìn)行平衡

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

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

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

以上就是“市面上比較全面的redis面試題及答案”，你能回答上來嗎?如果想要了解更多的Java面試題相關(guān)內(nèi)容，可以關(guān)注動力節(jié)點Java官網(wǎng)。