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

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

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

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

voltile－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（驅逐）：禁止驅逐數據

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

Redis是一個支持持久化的內存數據庫，通過持久化機制把內存中的數據同步到硬盤文件來保證數據持久化。當Redis重啟后通過把硬盤文件重新加載到內存，就能達到恢復數據的目的。

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

實現：單獨創建fork（）一個子進程，將當前父進程的數據庫數據復制到子進程的內存中，然后由子進程寫入到臨時文件中，持久化的過程結束了，再用這個臨時文件替換上次的快照文件，然后子進程退出，內存釋放。

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

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

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

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

創建快照。

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

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

AOF（append－only file）持久化

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

開啟AOF持久化后每執行一條會更改Redis中的數據的命令，Redis就會將該命令寫入硬盤中的AOF文件。AOF文件的 保存位置和RDB文件的位置相同，都是通過dir參數設置的，默認的文件名是appendonly．aof。

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

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

為了兼顧數據和寫入性能，用戶可以考慮 appendfsync everysec選項 ，讓Redis每秒同步一次AOF文件，Redis性能 幾乎沒受到任何影響。而且這樣即使出現系統崩潰，用戶最多只會丟失一秒之內產生的數據。當硬盤忙于執行寫入操作的時候，Redis還會優雅的放慢自己的速度以便適應硬盤的最大寫入速度。

Redis 4．0 對于持久化機制的優化

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

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

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

AOF重寫可以產生一個新的AOF文件，這個新的AOF文件和原有的AOF文件所保存的數據庫狀態一樣，但體積更小。

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

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

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

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

Sentinel（哨兵）可以監聽集群中的服務器，并在主服務器進入下線狀態時，自動從服務器中選舉出新的主服務器。

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