之前在平安雲面試，面試官問的最多的就是源碼知識，比如Spring的源碼，Redis的源碼，mybatis源碼等主要圍繞的是spring，Spring Boot源碼大家族進行開展。平時在項目上很多東西都是大牛們搭建好的架構，我們只要去寫業務就行，不是很注重底層。
自從這次面試以後就非常注重對框架底層的探索。說研究？真的，java框架更新太快根本研究不完，我感覺只要弄懂底層的一些知識，框架再怎麼變換都可以理解。而且技術永遠學習不完。記得前段時間在微信公衆號上看到的文章《千萬不要一輩子靠技術生存》我覺得寫的挺有道理的（文章鏈接：https://mp.weixin.qq.com/s/1MSQrpamVaxOcUW1pZKBLA），在沒有高等學歷，沒有異於常人的鑽研技術能力（可以說天賦）下，技術研究的越深可能反而越容易迷失自己，使自己迷茫。但是想要提升自己，技術又不得不學，這就變成了哲學問題了，哲學引人深思。
面試官問了我三個問題關於redis的問題：redis持久化方式有什麼哪些？Redis兩種集羣有什麼不用？前兩個我回答不上來，後面又問了，maven引入的reids名字叫什麼？我都沒有答上，當時做的項目用多線程，所有自己圍繞多線程知識點準備了很久？圍繞三個面試題，在京東上買了《Redis設計與實現》，其實可以根據redis官方文檔去學習。今天圍繞redis兩種持久化模式去說一說，面試時應該怎麼回答？
RDB持久化
- RDB基本概念
RDB持久化既可以手動執行，也可以根據服務器配置選項定期執行，該功能可以將某個時間點上的數據庫狀態保存到一個RDB文件中。
RDB持久化功能所生成的RDB文件是一個經壓縮的二進制文件，通過該文件可以還原RDB文件時的數據庫狀態。
RDB持久化通過保存數據庫中的鍵值對來記錄數據庫狀態的不同。
- RDB文件的創建與載入
有兩個redis命令用於生成RDB文件，一個是SVAE，一個是BGSAVE。
1.SAVE命令有服務器進程直接指向保存操作，會阻塞服務器。
2.BGASVE命令由子進程執行保存操作，所有該命令不會阻塞服務器。
第三. 服務器載入文件流程
RDB文件的載入工作是在服務器啓動時自動執行的，所有redis並沒有專門用於載入RDB文件的命令，只要Redis啓動時檢測到了RDB文件，它就會自動載入RDB文件。但AOF文件的更新頻率通常比RDB文件的更新頻率高，於是就涉及到載入文件的流程。
Redis服務啓動載入文件流程
1. 服務器啓動。
2. 執行載入程序。
3. 判斷是否開啓AOF持久化。
4. 是就載入AOF，不是就載入RDB。
小結：也就是說，RDB的載入不是一定會被載入的。另外服務器在載入RDB文件期間，會一直處於阻塞狀態，知道載入工作完成爲止。
第四.通過設置save去滿足RDB特定時間持久化
通過設置save選項設置多個保存條件：
如：
Save 900 1 服務器在900秒之內，對數據庫進行至少1次修改
Save 300 10 服務器在300秒之內，對數據庫進行至少10次修改
Save 60 10000 服務器在60秒之內，對數據庫進行至少10000 次修改
AOF（append only file）持久化
- AOF基本概念
- AOF持久化是通過Redis服務器所執行的寫命令來記錄數據庫狀態。
2. 命令請求會保存到AOF緩衝區裏面，之後再定期寫入並同步到AOF文。
AOF持久化的實現
AOF持久化的實現，三個步驟：
1. 命令追加（append）
2. 文件寫入
3. 文件同步（Sync）
AOF重寫
AOF重寫，因爲AOF持久化是通過保存被執行的寫命令來記錄數據庫狀態的，所有AOF文件中的內容會越來越多，文件的體積也會越來越大，如果不加以控制的話，體積過大AOF文件很可能會對Redis、甚至整個計算造成影響，並且AOF體積越大，數據庫還原的時間也越多。而AOF重寫就是爲了解決體積膨脹的問題。
AOF重寫：redis可以創建一個新的AOF文件來替代現有的AOF文件，兩個文件數據庫狀態一致，但新的AOF不會浪費任何空間命令，所有新的文件比舊的文件小很多。
AOF重寫原理：
比如：第一條命令push list ‘a’
第二條命令push list ‘b’
第三條命令push list ‘c’
這樣，AOF舊文件上面就會有三條命令，但重寫之後就變成了：push list ‘a’ ’b’ ’c’一條，大大的減少了很多浪費的空間。
- AOF緩衝區AOF後臺重寫有關
因爲在AOF重寫的時候有大量的寫操作，所有會堵塞，因爲redis是單線程的，如果直接使用服務器來執行的話就會阻塞其他的操作。而AOF又是一種維護數據的輔佐性功能，也就是說redis不是主要來進行AOF重寫的，所有redis決定把AOF重寫程序放在子進程裏面執行。這樣也會造成一個問題：主進行如果對數據庫進行了狀態修改怎麼辦？爲了解決主進程與子進程的問題。Redis設計設置了一個AOF重寫緩衝區。主進行的所有寫命令都寫入這個緩衝區。AOF重寫的時候，所有的命令都在緩衝區，把內容寫到新AOF文件中，然後創建舊文件一樣的名字，覆蓋舊的文件。
總結：
1.RDB文件爲壓縮的二進制文件，保存數據庫所有的鍵值對數據
2.SAVE和BGSAVE前者會阻塞服務器，後者不會阻塞服務器
3.AOF文件通過保存所有修改數據庫的寫命令請求記錄服務器數據狀態
4.AOF文件中的所有命令都是以Redis命令請求格式保存的
5.命令請求先保存到AOF緩衝區，然後在定期寫入並同步到AOF文件
6.AOF文件可能會膨脹，AOF重寫可以解決整個問題
7.AOF重寫會生產一個新的AOF文件覆蓋舊的AOF文件，新的AOF文件很比舊的文件小很多
8.在AOF重寫期間可能會出現主進程與子進程數據不同步的問題，用了一個AOF重寫緩衝區解決了這個問題。
RDB和AOF不同點
1.RDB和AOF存儲的數據格式不一樣
2.RDB特定時間持久化，如果宕機了，載入RDB文件的話，宕機期間的數據可能會丟失。而AOF採用每秒，和緩衝區的設計一般不會有數據丟失的問題
3.RDB載入會堵塞服務器，AOF載入不會阻塞，因爲AOF載入的時候回創建一個僞客戶端去載入AOF裏面的命令
·
RDB和AOF到底如何選擇
1.不要僅僅使用RDB這樣會丟失很多數據。
2.也不要僅僅使用AOF，因爲這一會有兩個問題，第一通過AOF做冷備沒有RDB做冷備恢復的速度快；第二RDB每次簡單粗暴生成數據快照，更加健壯。
3.綜合AOF和RDB兩種持久化方式，用AOF來保證數據不丟失，作爲恢復數據的第一選擇；用RDB來做不同程度的冷備，在AOF文件都丟失或損壞不可用的時候，可以使用RDB進行快速的數據恢復。
有更多的技術可以一起分享，一起成長。
