如果有疑問，歡迎在評論區留言，大家一起討論

1、Spring AOP 底層原理

aop 底層是采用動態代理機制實作的：介面+實作類

• 如果要代理的物件，實作了某個介面，那么 Spring AOP 會使用 JDK Proxy，去創建代理物件，
• 沒有實作介面的物件，就無法使用 JDK Proxy 去進行代理了，這時候 Spring AOP 會使用Cglib生成一個被代理物件的子類來作為代理，

就是由代理創建出一個和 impl 實作類平級的一個物件，但是這個物件不是一個真正的物件， 只是一個代理物件，但它可以實作和 impl 相同的功能，這個就是 aop 的橫向機制原理，這樣就不需要修改源代碼，

2、HashMap 的底層資料結構是怎樣的 ？

JDK1.8 之前

• JDK1.8 之前 HashMap 底層是陣列和鏈表結合在一起使用也就是鏈表散列，
• HashMap 通過 key 的 hashCode 經過擾動函式處理過后得到 hash 值，然后通過 (n - 1) & hash 判斷當前元素存放的位置（這里的 n 指的是陣列的長度），如果當前位置存在元素的話，就判斷該元素與要存入的元素的 hash 值以及 key 是否相同，如果相同的話，直接覆寫，不相同就通過拉鏈法解決沖突，
• 所謂擾動函式指的就是 HashMap 的 hash 方法，使用 hash 方法也就是擾動函式是為了防止一些實作比較差的 hashCode() 方法 換句話說使用擾動函式之后可以減少碰撞，

JDK1.8 之后

當鏈表長度大于閾值（默認為8）時，會首先呼叫 treeifyBin()方法，這個方法會根據 HashMap 陣列來決定是否轉換為紅黑樹，只有當陣列長度大于或者等于 64 的情況下，才會執行轉換紅黑樹操作，以減少搜索時間，否則，就是只是執行 resize() 方法對陣列擴容，

3、HashMap 的擴容機制是怎樣的？

一般情況下，當元素數量超過閾值時便會觸發擴容，每次擴容的容量都是之前容量的 2 倍， HashMap 的容量是有上限的，必須小于 1<<30，即 1073741824，如果容量超出了這個 數，則不再增長，且閾值會被設定為 Integer.MAX_VALUE，
JDK7 中的擴容機制

• 空引數的建構式：以默認容量、默認負載因子、默認閾值初始化陣列，內部陣列是空數 組，
• 有參建構式：根據引數確定容量、負載因子、閾值等，
• 第一次 put 時會初始化陣列，其容量變為不小于指定容量的 2 的冪數，然后根據負載因 子確定閾值，
• 如果不是第一次擴容，則 新容量=舊容量 x 2 ，新閾值=新容量 x 負載因子 ，

JDK8 的擴容機制

• 空引數的建構式：實體化的 HashMap 默認內部陣列是 null，即沒有實體化，第一次 呼叫 put 方法時，則會開始第一次初始化擴容，長度為 16，
• 有參建構式：用于指定容量，會根據指定的正整數找到不小于指定容量的 2 的冪數， 將這個數設定賦值給閾值（threshold），第一次呼叫 put 方法時，會將閾值賦值給容量， 然后讓 閾值 = 容量 x 負載因子，
• 如果不是第一次擴容，則容量變為原來的 2 倍，閾值也變為原來的 2 倍，（容量和閾值 都變為原來的 2 倍時，負載因子還是不變），

此外還有幾個細節需要注意：

• 首次 put 時，先會觸發擴容（算是初始化），然后存入資料，然后判斷是否需要擴容；
• 不是首次 put，則不再初始化，直接存入資料，然后判斷是否需要擴容；

4、ConcurrentHashMap 的存盤結構是怎樣的？

• Java7 中 ConcurrnetHashMap 使用的分段鎖，也就是每一個 Segment 上同時只有一個執行緒可以操作，每一個 Segment 都是一個類似 HashMap 陣列的結構，它可以擴容， 它的沖突會轉化為鏈表，但是 Segment 的個數一但初始化就不能改變，默認 Segment 的個數是 16 個，
• Java8 中的 ConcurrnetHashMap 使用的 Synchronized 鎖加 CAS 的機制，結構也由 Java7 中的 Segment 陣列 + HashEntry 陣列 + 鏈表 進化成了 Node 陣列 + 鏈表 / 紅 黑樹，Node 是類似于一個 HashEntry 的結構，它的沖突再達到一定大小時會轉化成紅 黑樹，在沖突小于一定數量時又退回鏈表

5、執行緒池大小如何設定？

• CPU 密集型任務(N+1)： 這種任務消耗的主要是 CPU 資源，可以將執行緒數設定為 N （CPU 核心數）+1，比 CPU 核心數多出來的一個執行緒是為了防止執行緒偶發的缺頁中斷， 或者其它原因導致的任務暫停而帶來的影響，一旦任務暫停，CPU 就會處于空閑狀態， 而在這種情況下多出來的一個執行緒就可以充分利用 CPU 的空閑時間，
• I/O 密集型任務(2N)： 這種任務應用起來，系統會用大部分的時間來處理 I/O 互動，而線 程在處理 I/O 的時間段內不會占用 CPU 來處理，這時就可以將 CPU 交出給其它執行緒使 用，因此在 I/O 密集型任務的應用中，我們可以多配置一些執行緒，具體的計算方法是 2N，

如何判斷是 CPU 密集任務還是 IO 密集任務？

??CPU 密集型簡單理解就是利用 CPU 計算能力的任務比如你在記憶體中對大量資料進行排序， 單凡涉及到網路讀取，檔案讀取這類都是 IO 密集型，這類任務的特點是 CPU 計算耗費時間 相比于等待 IO 操作完成的時間來說很少，大部分時間都花在了等待 IO 操作完成上，

6、IO 密集=Ncpu*2 是怎么計算出來？

??I/O 密集型任務任務應用起來，系統會用大部分的時間來處理 I/O 互動，而執行緒在處理 I/O 的時間段內不會占用 CPU 來處理，這時就可以將 CPU 交出給其它執行緒使用，因此在 I/O 密集型任務的應用中，我們可以多配置一些執行緒，例如：資料庫互動，檔案上傳下載， 網路傳輸等，IO 密集型，即該任務需要大量的 IO，即大量的阻塞，故需要多配置執行緒數，

7、G1 收集器有哪些特點？

G1 的全稱是 Garbage-First，意為垃圾優先，哪一塊的垃圾最多就優先清理它，

• G1 GC 最主要的設計目標是：將 STW 停頓的時間和分布，變成可預期且可配置的， 被視為 JDK1.7 中 HotSpot 虛擬機的一個重要進化特征，它具備一下特點：
  • 并行與并發：G1 能充分利用 CPU、多核環境下的硬體優勢，使用多個 CPU（CPU 或者 CPU 核心）來縮短 Stop-The-World 停頓時間，部分其他收集器原本需要停頓 Java 線 程執行的 GC 動作，G1 收集器仍然可以通過并發的方式讓 java 程式繼續執行，
  • 分代收集：雖然 G1 可以不需要其他收集器配合就能獨立管理整個 GC 堆，但是還是保留 了分代的概念，
  • 空間整合：與 CMS 的“標記-清理”演算法不同，G1 從整體來看是基于“標記-整理”算 法實作的收集器；從區域上來看是基于“標記-復制”演算法實作的，
  • 可預測的停頓：這是 G1 相對于 CMS 的另一個大優勢，降低停頓時間是 G1 和 CMS 共 同的關注點，但 G1 除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明 確指定在一個長度為 M 毫秒的時間片段內，

G1 收集器在后臺維護了一個優先串列，每次根據允許的收集時間，優先選擇回收價值最大的 Region（這也就是它的名字 Garbage-First 的由來）

8、你有哪些手段來排查 OOM 的問題？

• 增加兩個引數 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof，當 OOM 發生時自動 dump 堆記憶體資訊到指定目錄，
• 同時 jstat 查看監控 JVM 的記憶體和 GC 情況，先觀察問題大概出在什么區域，
• 使用 MAT 工具載入到 dump 檔案，分析大物件的占用情況，比如 HashMap 做快取未清理，時間長了就會記憶體溢位，可以把改為弱參考，

9、請你談談 MySQL 事務隔離級別，MySQL 的默認隔離級別是什么？

為了達到事務的四大特性，資料庫定義了 4 種不同的事務隔離級別：

• READ-UNCOMMITTED（讀取未提交）：最低的隔離級別，允許臟讀，也就是可能讀取 到其他會話中未提交事務修改的資料，可能會導致臟讀、幻讀或不可重復讀，
• READ-COMMITTED（讀取已提交）： 只能讀取到已經提交的資料，Oracle 等多數數 據庫默認都是該級別 （不重復讀），可以阻止臟讀，但是幻讀或不可重復讀仍有可能發生，
• REPEATABLE-READ（可重復讀）：對同一欄位的多次讀取結果都是一致的，除非資料 是被本身事務自己所修改，可以阻止臟讀和不可重復讀，但幻讀仍有可能發生，
• SERIALIZABLE（可串行化）：最高的隔離級別，完全服從 ACID 的隔離級別，所有的事務依次逐個執行，這樣事務之間就完全不可能產生干擾，也就是說，該級別可以防止臟讀、不可重復讀以及幻讀，
• MySQL 默認采用的 REPEATABLE_READ 隔離級別，

10、可重復讀解決了哪些問題？

• 可重復讀的核心就是一致性讀(consistent read);保證多次讀取同一個資料時，其值都和事務開始時候的內容是一致，禁止讀取到別的事務未提交的資料，會造成幻讀，
• 而事務更新資料的時候，只能用當前讀，如果當前的記錄的行鎖被其他事務占用的話，就需要進入鎖等待，
• 查詢只承認在事務啟動前就已經提交完成的資料，
• 可重復讀解決的是重復讀的問題，可重復讀在快照讀的情況下是不會有幻讀，但當前讀的時候會有幻讀，

11、對 SQL 慢查詢會考慮哪些優化 ？

分析陳述句，是否加載了不必要的欄位/資料，

• 分析 SQL 執行計劃（explain extended），思考可能的優化點，是否命中索引等，
• 查看 SQL 涉及的表結構和索引資訊，
• 如果 SQL 很復雜，優化 SQL 結構，
• 按照可能的優化點執行表結構變更、增加索引、SQL 改寫等操作，
• 查看優化后的執行時間和執行計劃，
• 如果表資料量太大，考慮分表，
• 利用快取，減少查詢次數，

12、談一談快取穿透、快取擊穿和快取雪崩，以及解決辦法？

快取穿透

• 問題：大量并發查詢不存在的 KEY，在快取和資料庫中都不存在，同時給快取和資料庫帶來壓力，
• 原因：一般而言，快取穿透有 2 種可能性：業務資料被誤刪，導致快取和資料庫中都沒有資料，惡意進行 ddos 攻擊，
• 分析：為什么會多次透傳呢？不存在一直為空，需要注意讓快取能夠區分 KEY 不存在和 查詢到一個空值，
• 解決辦法：快取空值的 KEY，這樣第一次不存在也會被加載會記錄，下次拿到有這個 KEY，Bloom 過濾或 RoaingBitmap 判斷 KEY 是否存在，如果布隆過濾器中沒有查到這個資料，就不去資料庫中查，在處理請求前增加惡意請求檢查，如果檢測到是惡意攻擊， 則拒絕進行服務，完全以快取為準，使用延遲異步加載的策略（異步執行緒負責維護快取的 資料，定期或根據條件觸發更新），這樣就不會觸發更新，

快取擊穿

• 問題：某個 KEY 失效的時候，正好有大量并發請求訪問這個 KEY，
• 分析：跟穿透其實很像，屬于比較偶然的，
• 解決辦法：KEY 的更新操作添加全域互斥鎖，完全以快取為準，使用延遲異步加載的策略（異步執行緒負責維護快取的資料，定期或根據條件觸發更新），這樣就不會觸發更新，

快取雪崩

• 問題：當某一時刻發生大規模的快取失效的情況，導致大量的請求無法獲取資料，從而將 流量壓力傳導到資料庫上，導致資料庫壓力過大甚至宕機，

• 原因：一般而言，快取雪崩有 2 種可能性：大量的資料同一個時間失效：比如業務關系 強相關的資料要求同時失效 Redis 宕機

• 分析：一般來說，由于更新策略、或者資料熱點、快取服務宕機等原因，可能會導致快取 資料同一個時間點大規模不可用，或者都更新，所以，需要我們的更新策略要在時間上合適，資料要均勻分享，快取服務器要多臺高可用，

• 解決辦法：更新策略在時間上做到比較平均，如果資料需要同一時間失效，可以給這批數 據加上一些隨機值，使得這批資料不要在同一個時間過期，降低資料庫的壓力，使用的熱 資料盡量分散到不同的機器上，多臺機器做主從復制或者多副本，實作高可用，做好主從 的部署，當主節點掛掉后，能快速的使用從結點頂上，實作熔斷限流機制，對系統進行負 載能力控制，對于非核心功能的業務，拒絕其請求，只允許核心功能業務訪問資料庫獲取資料，服務降價：提供默認回傳值，或簡單的提示資訊，

13、LRU 是什么？如何實作？

最近最少使用策略 LRU（Least Recently Used）是一種快取淘汰演算法，是一種快取淘汰機制，

• 使用雙向鏈表實作的佇列，佇列的最大容量為快取的大小，在使用程序中，把最近使用的頁面移動到佇列頭，最近沒有使用的頁面將被放在佇列尾的位置
• 使用一個哈希表，把頁號作為鍵，把快取在佇列中的節點的地址作為值，只需要把這個頁對應的節點移動到佇列的前面，如果需要的頁面在記憶體中，此時需要把這個頁面加載到記憶體中，簡單的說，就是將一個新節點添加到佇列前面，并在哈希表中跟新相應的節點地址， 如果佇列是滿的，那么就從隊尾移除一個節點，并將新節點添加到佇列的前面，

14、什么是堆記憶體？引數如何設定？

堆記憶體是指由程式代碼自由分配的記憶體，與堆疊記憶體作區分， 在 Java 中，堆記憶體主要用于分配物件的存盤空間，只要拿到物件參考，所有執行緒都可以訪問堆記憶體，

• -Xmx, 指定最大堆記憶體， 如 -Xmx4g. 這只是限制了 Heap 部分的最大值為 4g，這個記憶體不包括堆疊記憶體，也不包括堆外使用的記憶體，
• -Xms, 指定堆記憶體空間的初始大小， 如 -Xms4g， 而且指定的記憶體大小，并不是作業系統實際分配的初始值，而是 GC 先規劃好，用到才逐步分配，物件占用記憶體越來越多后，Xms不夠用就會逐漸擴大到Xmx數值， 專用服務器上需要保持 –Xms 和 –Xmx 一致(一般服務器也建議這樣設定)，否則應用剛啟動可能就有好幾個 FullGC，當兩者配置不一致時，堆記憶體擴容可能會導致性能抖動，
• -Xmn, 等價于 -XX:NewSize，使用 G1 垃圾收集器不應該設定該選項，在其他的某些業務場景下可以設定，除了 G1 外Xmn在其他垃圾回收器中表示的young區的大小，官方建議設定為 -Xmx 的 1/2 ~ 1/4.
• -XX：MaxPermSize=size, 這是 JDK1.7 之前使用的持久代的大小，Java8 稱為元資料區（MetaSpace），默認允許的 Meta 空間無限大，Java8 中此引數無效，
• -XX：MaxMetaspaceSize=size, Java8 默認不限制 Meta 空間, 一般不允許設定該選項，
• -XX：MaxDirectMemorySize=size，系統可以使用的最大堆外記憶體，這個引數跟 - Dsun.nio.MaxDirectMemorySize 效果相同， 這個就是配置直接記憶體的，這塊記憶體不受GC管理，
• -Xss, 設定每個執行緒堆疊能使用多少記憶體， 一般JDK8以上 -Xss1m 指定執行緒堆疊使用 1MB，與- XX:ThreadStackSize=1m 等價 ，每個執行緒有自己的執行緒堆疊，執行緒堆疊上有很多堆疊幀，每呼叫一個方法就會新建一個堆疊幀，這樣堆疊幀的深度可能很深，如果發現某些執行緒的堆疊溢位，那就是我們呼叫方法的深度很深，比如死回圈兩個方法來回呼叫，會導致堆疊幀使用的記憶體超過了Xss的限制，就會溢位，

??必須要強調，假設一臺機器4G記憶體，如果你設定-Xmx4g，表示最大可以使用的堆記憶體是4g，而Xmx配置的僅僅是堆內記憶體，JVM行程還會使用一些非堆記憶體（比如各種語言資料）、堆外記憶體（比如一些直接記憶體），并且JVM自己會再消耗一點系統記憶體，整個作業系統物理記憶體RAM就是4G，作業系統和其他一些非Java行程也會消耗一定的記憶體，整個Java能夠使用的記憶體大概是3.8G，非堆+堆外等記憶體估計得占個300~500M，最后留給堆內記憶體只有3.2G左右了，所以配置的Xmx要<=3.2G才是合適的值，

??有的架構師機器記憶體有多大，他就Xmx設定多大，沒多久就OOM，結果還一個勁的加機器來緩解，這也是常見的錯誤，

??Xmx一般是配置物理記憶體的60~80%，不要去按記憶體最大值配，

15、堆疊和佇列，舉個使用場景例子？

• 堆疊（后進先出）可以用于字符匹配，資料反轉等場景
• 佇列（先進先出）可以用于任務佇列，共享列印機等場景

16、MySQL 為什么 InnoDB 是默認引擎？

??聚集索引是指資料庫表行中資料的物理順序與鍵值的邏輯（索引）順序相同，一個表只能有一個聚集索引，因為一個表的物理順序只有一種情況，所以，對應的聚集索引只能有一個，聚集索引的葉子節點就是資料節點，既存盤索引值，又在葉子節點存盤行資料， Innodb 創建表后生成的檔案有： frm:創建表的陳述句 idb:表里面的資料+索引檔案

17、MySQL 索引底層結構為什么使用 B+樹？

• 哈希雖然能夠提供 O(1) 的單資料行操作性能，但是對于范圍查詢和排序卻無法很好地支持，最終導致全表掃描；B 樹能夠在非葉節子點中存盤資料，但是這也導致在查詢連續數 據時可能會帶來更多的隨機 I/O，而 B+樹的所有葉節點可以通過指標相互連接，能夠減少順序遍歷時產生的額外隨機 I/O；
• 第一，B 樹一個節點里存的是資料，而 B+樹存盤的是索引（地址），所以 B 樹里一個節 點存不了很多個資料，但是 B+樹一個節點能存很多索引，B+樹葉子節點存所有的資料，
• 第二，B+樹的葉子節點是資料階段用了一個鏈表串聯起來，便于范圍查找，

18、B+ 樹的葉子節點鏈表是單向還是雙向？

??索引就是 B+ 樹，葉子結點就是用戶的資料頁，非葉子節點就是目錄頁，頁與頁之間是雙向鏈表，頁中的用戶記錄是單向鏈表，

19、MVCC 是什么？它的底層原理是什么？

MVCC，多版本并發控制,它是通過讀取歷史版本的資料，來降低并發事務沖突，從而提高并發性能的一種機制，

• 事務版本號
• 表的隱藏列
• undo log
• read view

20、undo log 具體怎么回滾事務 ？

舉個例子：

• 對于 insert 型別的 sql，會在 undo log 中記錄下方才你 insert 進來的資料的 ID，當你想 roll back 時，根據 ID 完成精準的洗掉，
• 對于 delete 型別的 sql，會在 undo log 中記錄方才你洗掉的資料，當你回滾時會將洗掉前的資料 insert 進去，
• 對于 update 型別的 sql，會在 undo log 中記錄下修改前的資料，回滾時只需要反向 update 即可，
• 對于 select 型別的 sql，想啥呢，select 不需要回滾，

21、如何查詢慢 SQL 產生的原因

• 分析 SQL 執行計劃（explain extended），思考可能的優化點，是否命中索引等，
• 沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是程式設計的缺陷)，
• 記憶體不足，
• 網路速度慢，
• 是否查詢出的資料量過大（可以采用多次查詢，其他的方法降低資料量），
• 是否回傳了不必要的行和列，
• 鎖或者死鎖，
• I/O 吞吐量小，形成了瓶頸效應，
• sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源，

22、索引失效的情況有哪些？

• like 以%開頭索引無效，當 like 以&結尾，索引有效，
• or 陳述句前后沒有同時使用索引，當且僅當 or 陳述句查詢條件的前后列均為索引時，索引生效，
• 聯合索引使用的不是第一列索引時候，不滿足最左匹配規則，索引失效，
• 資料型別出現隱式轉換，如 varchar 不加單引號的時候可能會自動轉換為 int 型別，這個時候索引失效，
• 對索引欄位進行計算操作，函式操作時不會使用索引，
• 當優化器計算查詢成本發現全表掃描的成本比索引的成本低的時候不會使用索引，

擴展閱讀B+樹使用場景大全的文章：IS NULL、IS NOT NULL、!=、BETWEEN、IN等等不能用索引嗎？必須辟謠！

23、一個 Redis 實體最多能存放多少的 keys？List、Set、Sorted Set 它們最多能存放多少元素？

理論上 Redis 可以處理多達 232 的 keys，并且在實際中進行了測驗，每個實體至少存放 了 2 億 5 千萬的 keys，我們正在測驗一些較大的值，任何 list、set、和 sorted set 都可以放 232 個元素，換句話說，Redis 的存盤極限是系統中的可用記憶體值，

24、Redis 資料結構壓縮串列和跳躍表的區別

• 壓縮串列（ziplist）本質上就是一個位元組陣列，是 Redis 為了節約記憶體而設計的一種線性資料結構，可以包含多個元素，每個元素可以是一個位元組陣列或一個整數，
• 跳躍表（skiplist）是一種有序資料結構，它通過在每個節點中維持多個指向其他節點的指標，從而達到快速訪問節點的目的，跳躍表支持平均 O（logN）、最壞 O（N）復雜度的節點查找，還可以通過順序性操作來批量處理節點，

25、為什么資料量小的時候用壓縮串列 ?

為了省記憶體，

26、Redis 主從同步是怎么實作的？

全量同步

master 服務器會開啟一個后臺行程用于將 redis 中的資料生成一個 rdb 檔案，與此同時， 服務器會快取所有接收到的來自客戶端的寫命令（包含增、刪、改），當后臺保存行程處理完畢后，會將該 rdb 檔案傳遞給 slave 服務器，而 slave 服務器會將 rdb 檔案保存在磁盤并通過讀取該檔案將資料加載到記憶體，在此之后 master 服務器會將在此期間快取的命令通過 redis 傳輸協議發送給 slave 服務器，然后 slave 服務器將這些命令依次作用于自己本地的資料集上最終達到資料的一致性，

增量同步

從 redis 2.8 版本以前，并不支持部分同步，當主從服務器之間的連接斷掉之后，master 服務器和 slave 服務器之間都是進行全量資料同步， 從 redis 2.8 開始，即使主從連接中途斷掉，也不需要進行全量同步，因為從這個版本開始融入了部分同步的概念，部分同步的實作依賴于在 master 服務器記憶體中給每個 slave 服務 器維護了一份同步日志和同步標識，每個 slave 服務器在跟 master 服務器進行同步時都會 攜帶自己的同步標識和上次同步的最后位置，當主從連接斷掉之后，slave 服務器隔斷時間 （默認 1s）主動嘗試和 master 服務器進行連接，如果從服務器攜帶的偏移量標識還在 master 服務器上的同步備份日志中，那么就從 slave 發送的偏移量開始繼續上次的同步操作，如果 slave 發送的偏移量已經不再 master 的同步備份日志中（可能由于主從之間斷掉 的時間比較長或者在斷掉的短暫時間內 master 服務器接收到大量的寫操作），則必須進行一次全量更新，在部分同步程序中，master 會將本地記錄的同步備份日志中記錄的指令依次發送給 slave 服務器從而達到資料一致，

Redis 主從同步策略

主從剛剛連接的時候，進行全量同步；全同步結束后，進行增量同步，當然，如果有需要， slave 在任何時候都可以發起全量同步，redis 策略是，無論如何，首先會嘗試進行增量同步， 如不成功，要求從機進行全量同步，

27、Redis 持久化 RDB 和 AOF 優缺點

RDB

RDB 持久化方式，是將 Redis 某一時刻的資料持久化到磁盤中，是一種快照式的持久化方法，

RDB 優點：

• RDB 是一個非常緊湊（有壓縮）的檔案,它保存了某個時間點的資料,非常適用于資料的備份，
• RDB 作為一個非常緊湊（有壓縮）的檔案，可以很方便傳送到另一個遠端資料中心 ，非常適用于災難恢復，
• RDB 在保存 RDB 檔案時父行程唯一需要做的就是 fork 出一個子行程,接下來的作業全部由子行程來做，父行程不需要再做其他 IO 操作，所以 RDB 持久化方式可以最大化 redis 的性能，
• 與 AOF 相比，在恢復大的資料集的時候，RDB 方式會更快一些，

RDB 缺點：

• Redis 意外宕機時，會丟失部分資料，
• 當 Redis 資料量比較大時，fork 的程序是非常耗時的，fork 子行程時是會阻塞的，在這期間 Redis 是不能回應客戶端的請求的，

AOF

AOF 方式是將執行過的寫指令記錄下來，在資料恢復時按照從前到后的順序再將指令都執行一遍，

AOF 優點：

• 使用 AOF 會讓你的 Redis 更加持久化，
• AOF 檔案是一個只進行追加的日志檔案，不需要在寫入時讀取檔案，
• Redis 可以在 AOF 檔案體積變得過大時，自動地在后臺對 AOF 進行重寫 ，
• AOF 檔案可讀性高，分析容易，

AOF 缺點：

• 對于相同的資料來說，AOF 檔案大小通常要大于 RDB 檔案，
• 根據所使用的 fsync 策略，AOF 的速度可能會慢于 RDB，

28、談談自己對于 Spring AOP 的了解？

AOP(Aspect-Oriented Programming:面向切面編程)能夠將那些與業務無關，卻為業務模塊所共同呼叫的邏輯或責任（例如事務處理、日志管理、權限控制等）封裝起來，便于減少系統的重復代碼，降低模塊間的耦合度，并有利于未來的可拓展性和可維護性，

29、 Spring Bean 容器的生命周期是什么樣的？

• Bean 容器找到組態檔中 Spring Bean 的定義，
• Bean 容器利用 Java Reflection API 創建一個 Bean 的實體，
• 如果涉及到一些屬性值 利用 set()方法設定一些屬性值，
• 如果 Bean 實作了 BeanNameAware 介面，呼叫 setBeanName()方法，傳入 Bean 的名字，
• 如果 Bean 實作了 BeanClassLoaderAware 介面，呼叫 setBeanClassLoader()方法， 傳入 ClassLoader 物件的實體，
• 如果 Bean 實作了 BeanFactoryAware 介面，呼叫 setBeanFactory()方法，傳入 BeanFactory 物件的實體，
• 與上面的類似，如果實作了其他 *.Aware 介面，就呼叫相應的方法，
• 如果有和加載這個 Bean 的 Spring 容器相關的 BeanPostProcessor 物件，執行 postProcessBeforeInitialization() 方法
• 如果 Bean 實作了 InitializingBean 介面，執行 afterPropertiesSet()方法，
• 如果 Bean 在組態檔中的定義包含 init-method 屬性，執行指定的方法，
• 如果有和加載這個 Bean 的 Spring 容器相關的 BeanPostProcessor 物件，執行 postProcessAfterInitialization() 方法
• 當要銷毀 Bean 的時候，如果 Bean 實作了 DisposableBean 介面，執行 destroy() 方法，
• 當要銷毀 Bean 的時候，如果 Bean 在組態檔中的定義包含 destroy-method 屬性， 執行指定的方法，

30、RabbitMQ 如何保證訊息不丟失 ？

生產者：
方案 1：開啟 RabbitMQ 事務(同步，性能差)
方案 2：開啟 confirm 模式(異步，性能較好)
MQ：(1) exchange 持久化 (2) queue 持久化 (3)訊息持久化

消費者：關閉自動 ACK