1.談?wù)凴edis集群數(shù)據(jù)hash分片算法

Redis 集群將所有數(shù)據(jù)劃分16384個slots，每個節(jié)點負(fù)責(zé)其中一部分槽位。當(dāng)Redis 集群的客戶端來連接集群時，它也會得到一份集群的槽位信息并將其緩存到客戶端本地，這樣當(dāng)客戶端要查找某個key時，可以根據(jù)槽位定位算法定位到目標(biāo)節(jié)點。

槽位定位算法

集群默認(rèn)會對key值使用crc16算法進行hash，得到一個整數(shù)值，然后這個整數(shù)值對16384進行取模運算來得到具體的槽位。

Hash_slot = CRC16(key)mod13684

再根據(jù)槽位和節(jié)點的對應(yīng)關(guān)系就可以定位到key具體是在那個Redis節(jié)點上。

2.Redis執(zhí)行命令竟然有死循環(huán)阻塞Bug

Redis有個RANDOMKEY命令可以從Redis中隨機取出一個key，這個命令可能導(dǎo)致Redis死循環(huán)阻塞。

RANDOMKEY在隨機拿出一個key之后，首先會檢驗這個key是否過期，如果該key過期，那么Redis會刪除它，這個過程就是惰性刪除，但是清理完了之后還不能結(jié)束，Redis會再找出一個沒過期的key返回給客戶端。

此時，Redis則會繼續(xù)隨機拿出一個key，然后再判斷它是否過期，直到找到一個沒過期的key返回給客戶端。

這里就有一個問題，如果此時Redis中有大量的key過期，但還未來得及被清理掉，這個循環(huán)就會持續(xù)很久才能結(jié)束，這樣就會導(dǎo)致RANDOMKEY命令執(zhí)行耗時變長，影響Redis性能。

以上流程，其實是master上執(zhí)行的。如果在slave上執(zhí)行RANDOMKEY，那么問題更嚴(yán)重。

slave是不會自己清理過期的key，當(dāng)一個key要過期時，master會先清理刪除它，之后master向slave發(fā)送一個DEL命令，告知slave也刪除這個key，以此達(dá)到主從一致。

假設(shè)Redis中存在大量已過期還未來得及清理的key，那么在slave上執(zhí)行RANDOMKEY時，就會發(fā)生一下問題：

1、slave隨機取出一個key，判斷是否已經(jīng)過期。

2、key已經(jīng)過期，但是slave不會刪除它，而是繼續(xù)隨機尋找不過期的key

3、由于大量key都已過期，那slave就會找不到符合條件的key，就會進入死循環(huán)。

這個Bug直到5.0才被修復(fù)，修復(fù)方法就是在slave中設(shè)置一個最大查找次數(shù)，無論找到與否，到了這個最大次數(shù)就退出循環(huán)。

3.一次線上事故，Redis主從切換導(dǎo)致了緩存雪崩

我們假設(shè)，slave的機器時鐘比master走的快很多。

此時，Redis master 里設(shè)置了過期時間的key，從slave角度來看，可能會有很多在master里沒過期，在slave里面已經(jīng)過期了的數(shù)據(jù)。

如果此時操作主從切換，把slave提升為新的master，新的master就會開始大量清理過期的key，此時就會導(dǎo)致以下結(jié)果：

1、master大量清理過期key，主線程可能會發(fā)生阻塞，無法及時處理客戶端請求。

2、Redis中數(shù)據(jù)大量過期，引發(fā)緩存雪崩。

所以，我們一定要保證主從庫的機器時鐘一致，避免發(fā)生這些問題。

4.Redis持久化RDB、AOF、混合持久化

Redis持久化分為：RDB、AOF、混合持久化(redis4.0引入)

RDB的實現(xiàn)原理、優(yōu)缺點

描述：類似于快照。在某個時間點，將 Redis 在內(nèi)存中的數(shù)據(jù)庫狀態(tài)(數(shù)據(jù)庫的鍵值對等信息)保存到磁盤里面。RDB 持久化功能生成的 RDB 文件是經(jīng)過壓縮的二進制文件。

有兩個 Redis 命令可以用于生成 RDB 文件，一個是 SAVE，另一個是 BGSAVE。

開啟：使用 save point 配置

save 900 1 #900秒內(nèi)有1個key發(fā)生了變化，則觸發(fā)保存RDB文件
save 300 10 #300秒內(nèi)有10個key發(fā)生了變化，則觸發(fā)保存RDB文件
save 60 10000 #60秒內(nèi)有10000個key發(fā)生了變化，則觸發(fā)保存RDB文件

關(guān)閉：1)注釋掉所有save point 配置可以關(guān)閉 RDB 持久化。2)在所有 save point 配置后增加：save ""，該配置可以刪除所有之前配置的 save point。

SAVE：生成 RDB 快照文件，但是會阻塞主進程，服務(wù)器將無法處理客戶端發(fā)來的命令請求，所以通常不會直接使用該命令。

BGSAVE：fork 子進程來生成 RDB 快照文件，阻塞只會發(fā)生在 fork 子進程的時候，之后主進程可以正常處理請求.

RDB 的優(yōu)點：1)RDB 文件是是經(jīng)過壓縮的二進制文件，占用空間很小，它保存了 Redis 某個時間點的數(shù)據(jù)集，很適合用于做備份。 比如說，你可以在最近的 24 小時內(nèi)，每小時備份一次 RDB 文件，并且在每個月的每一天，也備份一個 RDB 文件。這樣的話，即使遇上問題，也可以隨時將數(shù)據(jù)集還原到不同的版本。

2)RDB 非常適用于災(zāi)難恢復(fù)(disaster recovery)：它只有一個文件，并且內(nèi)容都非常緊湊，可以(在加密后)將它傳送到別的數(shù)據(jù)中心。

3)RDB 可以最大化 redis 的性能。父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無須執(zhí)行任何磁盤 I/O 操作。

4)RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快。

RDB 的缺點：1)RDB 在服務(wù)器故障時容易造成數(shù)據(jù)的丟失

2)RDB 保存時使用 fork 子進程進行數(shù)據(jù)的持久化，如果數(shù)據(jù)比較大的話，fork 可能會非常耗時，造成 Redis 停止處理服務(wù)N毫秒。如果數(shù)據(jù)集很大且 CPU 比較繁忙的時候，停止服務(wù)的時間甚至?xí)揭幻搿?/p>

3)Linux fork 子進程采用的是 copy-on-write 的方式。在 Redis 執(zhí)行 RDB 持久化期間，如果 client 寫入數(shù)據(jù)很頻繁，那么將增加 Redis 占用的內(nèi)存，最壞情況下，內(nèi)存的占用將達(dá)到原先的2倍。剛 fork 時，主進程和子進程共享內(nèi)存，但是隨著主進程需要處理寫操作，主進程需要將修改的頁面拷貝一份出來，然后進行修改。極端情況下，如果所有的頁面都被修改，則此時的內(nèi)存占用是原先的2倍。

AOF的實現(xiàn)原理、優(yōu)缺點

描述：保存 Redis 服務(wù)器所執(zhí)行的所有寫操作命令來記錄數(shù)據(jù)庫狀態(tài)，并在服務(wù)器啟動時，通過重新執(zhí)行這些命令來還原數(shù)據(jù)集。

可以通過配置：appendonly yes 開啟，使用配置 appendonly no 可以關(guān)閉 AOF 持久化

AOF 持久化功能的實現(xiàn)可以分為三個步驟：命令追加、文件寫入、文件同步。

appendfsync 參數(shù)有三個選項：

1)always：每處理一個命令都將 aof_buf 緩沖區(qū)中的所有內(nèi)容寫入并同步到AOF 文件，即每個命令都刷盤。

2)everysec：將 aof_buf 緩沖區(qū)中的所有內(nèi)容寫入到 AOF 文件，如果上次同步 AOF 文件的時間距離現(xiàn)在超過一秒鐘， 那么再次對 AOF 文件進行同步， 并且這個同步操作是異步的，由一個后臺線程專門負(fù)責(zé)執(zhí)行，即每秒刷盤1次。

3)no：將 aof_buf 緩沖區(qū)中的所有內(nèi)容寫入到 AOF 文件， 但并不對 AOF 文件進行同步， 何時同步由操作系統(tǒng)來決定。即不執(zhí)行刷盤，讓操作系統(tǒng)自己執(zhí)行刷盤。

• AOF 的優(yōu)點：1)AOF 比 RDB可靠。你可以設(shè)置不同的 fsync 策略：no、everysec 和 always。默認(rèn)是 everysec，在這種配置下，redis 仍然可以保持良好的性能，并且就算發(fā)生故障停機，也最多只會丟失一秒鐘的數(shù)據(jù)。

2)AOF文件是一個純追加的日志文件。即使日志因為某些原因而包含了未寫入完整的命令(比如寫入時磁盤已滿，寫入中途停機等等)， 我們也可以使用 redis-check-aof 工具也可以輕易地修復(fù)這種問題。

3)當(dāng) AOF文件太大時，Redis 會自動在后臺進行重寫：重寫后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。整個重寫是絕對安全，因為重寫是在一個新的文件上進行，同時 Redis 會繼續(xù)往舊的文件追加數(shù)據(jù)。當(dāng)新文件重寫完畢，Redis 會把新舊文件進行切換，然后開始把數(shù)據(jù)寫到新文件上

4)AOF 文件有序地保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作以 Redis 協(xié)議的格式保存， 因此 AOF 文件的內(nèi)容非常容易被人讀懂， 對文件進行分析(parse)也很輕松。如果你不小心執(zhí)行了 FLUSHALL 命令把所有數(shù)據(jù)刷掉了，但只要 AOF 文件沒有被重寫，那么只要停止服務(wù)器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)。

• AOF 的缺點

1)對于相同的數(shù)據(jù)集，AOF 文件的大小一般會比 RDB 文件大。

2)根據(jù)所使用的 fsync 策略，AOF 的速度可能會比 RDB 慢。通常 fsync 設(shè)置為每秒一次就能獲得比較高的性能，而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快。

生產(chǎn)環(huán)境都可以啟用，redis啟動時如果既有rdb文件，又有aof文件則優(yōu)先選擇aof文件恢復(fù)數(shù)據(jù)，因為aof一般來說數(shù)據(jù)更安全一點。

混合持久化

通過如下配置開啟混合持久化(必須先開啟aof)

aof-use-rdb-preamble yes

混合持久化本質(zhì)是通過 AOF 后臺重寫(bgrewriteaof 命令)完成的，不同的是當(dāng)開啟混合持久化時，fork 出的子進程先將當(dāng)前全量數(shù)據(jù)以 RDB 方式寫入新的 AOF 文件，然后再將 AOF 重寫緩沖區(qū)(aof_rewrite_buf_blocks)的增量命令以 AOF 方式寫入到文件，寫入完成后通知主進程將新的含有 RDB 格式和 AOF 格式的 AOF 文件替換舊的的 AOF 文件。

優(yōu)點：結(jié)合 RDB 和 AOF 的優(yōu)點, 更快的重寫和恢復(fù)。

缺點：AOF 文件里面的 RDB 部分不再是 AOF 格式，可讀性差。

以上就是“距離進入大廠就只差redis集群面試題”，你能回答上來嗎?如果想要了解更多的Java面試題相關(guān)內(nèi)容，可以關(guān)注動力節(jié)點Java官網(wǎng)。