本期是 Redis 第二期，至此 Redis 部分就全部更新完畢了，下一彈就是常見智力題與面試剖析了，估計還有兩三期，整個逆襲進大廠系列就全部完結(jié)啦。

完結(jié)的時間，也會更新 PDF 的第四版，大家可以放心，第四版絕對值得期待！

17、假如MySQL有1000萬數(shù)據(jù)，采用Redis作為中間緩存，取其中的10萬，如何保證Redis中的數(shù)據(jù)都是熱點數(shù)據(jù)？

可以使用Redis的數(shù)據(jù)淘汰策略，Redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時候，就會施行這種策略。具體說來，主要有 6種內(nèi)存淘汰策略：

voltile－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ù)

18、Redis持久化機制可以說一說嗎？

Redis是一個支持持久化的內(nèi)存數(shù)據(jù)庫，通過持久化機制把內(nèi)存中的數(shù)據(jù)同步到硬盤文件來保證數(shù)據(jù)持久化。當(dāng)Redis重啟后通過把硬盤文件重新加載到內(nèi)存，就能達到恢復(fù)數(shù)據(jù)的目的。

很多時候我們需要持久化數(shù)據(jù)也就是將內(nèi)存中的數(shù)據(jù)寫入到硬盤里面，大部分原因是為了之后重用數(shù)據(jù)（比如重啟機 器、機器故障之后回復(fù)數(shù)據(jù)），或者是為了防止系統(tǒng)故障而將數(shù)據(jù)備份到一個遠程位置。

實現(xiàn)：單獨創(chuàng)建fork（）一個子進程，將當(dāng)前父進程的數(shù)據(jù)庫數(shù)據(jù)復(fù)制到子進程的內(nèi)存中，然后由子進程寫入到臨時文件中，持久化的過程結(jié)束了，再用這個臨時文件替換上次的快照文件，然后子進程退出，內(nèi)存釋放。

以下有兩種持久化機制快照（snapshotting）持久化（RDB持久化）

Redis可以通過創(chuàng)建快照來獲得存儲在內(nèi)存里面的數(shù)據(jù)在某個時間點上的副本。Redis創(chuàng)建快照之后，可以對快照進行 備份，可以將快照復(fù)制到其他服務(wù)器從而創(chuàng)建具有相同數(shù)據(jù)的服務(wù)器副本（Redis主從結(jié)構(gòu)，主要用來提高Redis性 能），還可以將快照留在原地以便重啟服務(wù)器的時候使用。

快照持久化是Redis默認采用的持久化方式，在Redis．conf配置文件中默認有此下配置：

save 900 1 ＃在900秒（15分鐘）之后，如果至少有1個key發(fā)生變化，Redis就會自動觸發(fā)BGSAVE命令

創(chuàng)建快照。

save 300 10 ＃在300秒（5分鐘）之后，如果至少有10個key發(fā)生變化，Redis就會自動觸發(fā)BGSAVE命令創(chuàng)建快照。

save 60 10000 ＃在60秒（1分鐘）之后，如果至少有10000個key發(fā)生變化，Redis就會自動觸發(fā)BGSAVE命令創(chuàng)建快照。

AOF（append－only file）持久化

與快照持久化相比，AOF持久化的實時性更好，因此已成為主流的持久化方案。默認情況下Redis沒有開啟 AOF（append only ?le）方式的持久化，可以通過appendonly參數(shù)開啟：appendonly yes

開啟AOF持久化后每執(zhí)行一條會更改Redis中的數(shù)據(jù)的命令，Redis就會將該命令寫入硬盤中的AOF文件。AOF文件的 保存位置和RDB文件的位置相同，都是通過dir參數(shù)設(shè)置的，默認的文件名是appendonly．a(chǎn)of。

在Redis的配置文件中存在三種不同的 AOF 持久化方式，它們分別是：

appendfsync always ＃每次有數(shù)據(jù)修改發(fā)生時都會寫入AOF文件，這樣會嚴(yán)重降低Redis的速度
appendfsync everysec  ＃每秒鐘同步一次，顯示地將多個寫命令同步到硬盤
appendfsync no  ＃讓操作系統(tǒng)決定何時進行同步

為了兼顧數(shù)據(jù)和寫入性能，用戶可以考慮 appendfsync everysec選項 ，讓Redis每秒同步一次AOF文件，Redis性能 幾乎沒受到任何影響。而且這樣即使出現(xiàn)系統(tǒng)崩潰，用戶最多只會丟失一秒之內(nèi)產(chǎn)生的數(shù)據(jù)。當(dāng)硬盤忙于執(zhí)行寫入操作的時候，Redis還會優(yōu)雅的放慢自己的速度以便適應(yīng)硬盤的最大寫入速度。

Redis 4．0 對于持久化機制的優(yōu)化

Redis 4．0 開始支持 RDB 和 AOF 的混合持久化（默認關(guān)閉，可以通過配置項 aof－use－rdb－preamble 開啟）。

如果把混合持久化打開，AOF 重寫的時候就直接把 RDB 的內(nèi)容寫到 AOF 文件開頭。這樣做的好處是可以結(jié)合 RDB 和 AOF 的優(yōu)點， 快速加載同時避免丟失過多的數(shù)據(jù)。當(dāng)然缺點也是有的， AOF 里面的 RDB 部分是壓縮格式不再是 AOF 格式，可讀性較差。

19、AOF重寫了解嗎？可以簡單說說嗎？

AOF重寫可以產(chǎn)生一個新的AOF文件，這個新的AOF文件和原有的AOF文件所保存的數(shù)據(jù)庫狀態(tài)一樣，但體積更小。

AOF重寫是一個有歧義的名字，該功能是通過讀取數(shù)據(jù)庫中的鍵值對來實現(xiàn)的，程序無須對現(xiàn)有AOF文件進行任伺讀 入、分析或者寫入操作。

在執(zhí)行 BGREWRITEAOF 命令時，Redis 服務(wù)器會維護一個 AOF 重寫緩沖區(qū)，該緩沖區(qū)會在子進程創(chuàng)建新AOF文件期間，記錄服務(wù)器執(zhí)行的所有寫命令。當(dāng)子進程完成創(chuàng)建新AOF文件的工作之后，服務(wù)器會將重寫緩沖區(qū)中的所有內(nèi)容 追加到新AOF文件的末尾，使得新舊兩個AOF文件所保存的數(shù)據(jù)庫狀態(tài)一致。最后，服務(wù)器用新的AOF文件替換舊的 AOF文件，以此來完成AOF文件重寫操作。

20、是否使用Redis集群，集群的原理是什么

Redis Sentinel（哨兵）著眼于高可用，在master宕機時會自動將slave提升為master，繼續(xù)提供服務(wù)。

Sentinel（哨兵）可以監(jiān)聽集群中的服務(wù)器，并在主服務(wù)器進入下線狀態(tài)時，自動從服務(wù)器中選舉出新的主服務(wù)器。

Redis Cluster（集群）著眼于擴展性，在單個Redis內(nèi)存不足時，使用Cluster進行分片存儲。