Interview Ready, set, go

1. SpringMVC的執行流程

   封裝了 Servlet，提供更有好的開發模型

   用戶發起請求 - > DispatcherServlet 收到請求，轉發給 Handler Mapping -> Handler Mapping 解析請求，根據請求信息和配置信息找到匹配的 Controller 類別 OR

   如果有配置攔截器的話，會按照攔截器裡的順序執行 preHandle 方法 ->

   找到匹配的 Controller 後，會把請求參數傳遞給 Controller 裡面的方法 ->

   Controller 裡面的方法完成後，會返回一個 ModelAndView (包含視圖名稱和需要傳遞給視途的模型數據) ->

   視圖解析器 View Resolver 會根據名字找到視圖

2. MySQL binlog 和 redolog 有什麼區別？

   這兩個都是用來記錄數據庫數據變更操作的日誌

   binlog(binary log)：

   • 數據備份、數據恢復、數據同步

   redolog：

   • 主要是在MySQL數據庫事務的ACID特性裡面，用來保證數據的持久化特性
   • 也可以在數據庫崩潰時，通過 RedoLog 來恢復未完成的數據，保證數據的完整性

   Conclusion:

   #	binlog	redolog
   使用場景不同	數據備份、數據恢復、主從集群的數據同步	實現Mysql數據庫的事務恢復、保證事務的ACID特性當數據庫崩潰時，redolog 可以把未提交的事務回滾，把已經提交的事務進行持久化
   記錄信息不同	紀錄數據庫的邏輯變化提供三種日誌格式：statement, row, mixed	紀錄數據的物理變化i.e. 數據頁的變化結果
   紀錄時機不同	執行SQL語句時，在主線程生成邏輯變化，寫入disk『語句級別』的紀錄方式	是在 Ｍysql 後台線程中去生成，並寫入到disk『事務級別』的紀錄方式

3. limit 1000000, 10加載很慢，如何解決？

查詢一百萬頁，每頁展示十個數據，看要不要改回傳分析過的資料

4. 有一張200W數據量的會員表，每個會員有長短不一的到期時件，現在想在快到期之前發送郵件通知提醒續費，如何實現？

   1. 系統不主動輪詢，而是等用戶登錄到系統以後，觸發一次檢查

      如果發現『會員過期時間』< 『設定的閾值』，就觸發一次彈窗和郵件提醒

      Pros: 規避了輪詢問題，不會對數據庫和後端應用程序造成任何壓力

      Cons: 如果用戶一直不登錄，就一直無法實現會員過期，並且也無法提前去根據運營策略發送郵件或續期的提醒消息。

   2. 可以直接使用搜尋引擎，例如 Solr 或者 ElasticSearch 把會員表裡面的會員id和會員到期時間存儲一份到搜尋引擎裡面

      Pros: 搜尋引擎優點在於大數據量的快速檢索， 並且具有高可擴展性和高可靠性，非常適合大規模數據的處理

   3. 可以直接使用 Redis 來實現：

      用戶開通會員以後，在Redis裡面存儲這個會員的ID，並設置這個id的過期時間

      接著，可以使用 Redis 裡面的過期提醒功能

      notify-keyspace-events
      notify-keyspace-events "Ex"
      

      當 Redis 裡面的 key過期以後，會觸發一個key過期事件，

      可以在應用程序裡監聽這個事件來進行處理

   4. 可以直接使用MQ提供的延遲隊列

      當用戶開通以後，直接計算這個會員的過期時間，然後發送一個延遲消息到MQ裡面

      一旦消息達到過期時間， 消費者就可以消費這樣ㄧ個消息，來觸發會員過期的一個提醒

5. 數據庫索引的原理，為什麼要用B+樹？

   可以減少跟磁盤的交互次數

   B樹：每一個節點上都會存索引和數據

   B+樹：只有葉子節點才會存數據，非葉子節點存儲的是索引

6. 詢問 offer, select 和 epoll的區別

   select 和 epoll 都是多路複用的機制，可以讓一個線程去監聽多個文件描述符的IO事件，或者連接事件

   區別

   1. select 基於輪詢的機制，需要遍歷整個監聽集合，直到找到就緒的文件描述符

      epoll 基於事件通知機制，它只需要遍歷當前就緒的文件描述符集合，大大減少了遍歷的次數和開銷

   2. select 的監聽集合大小受到操作系統限制， 而epoll 沒有這個限制，可以監聽大量的文件描述符

   3. 在處理大量文件描述符時，select的性能隨著監聽集合的增大而逐漸下降， 而epoll的性能則能夠保持穩定

   4. 在多線程環境下，select 需要將監聽集合傳遞給每個線程，

      而epoll可以在一個線程中處理多個文件描述符，避免了線程問題的切換和數據複製等開銷

7. 如何處理消息隊列中的消息積壓問題？

   原因：生產者的生產速度 > 消費者的消費速度

   需要先排查原因，如果不是因為系統bug導致的消息積壓，那可以優化消費端的邏輯，例如：

   • 通過異步的方式來處理消息
   • 通過批量處理的方式來消費

   如果以上兩種方法還不行緩解，可以考慮對消費端進行水平擴容

8. volatile 為什麼不能保證原子性？

   不可分割… 以下三個步驟如果沒有額外加鎖，則是非原子的

   • 讀取數據
   • 進行運算 — 多個 CPU 同時執行，可能造成髒讀
   • 寫入內存

   volatile 只能保證可見性和有序性

9. 多線程中存在的 CPU 緩存一致性問題，要如何解決？

   每個CPU之間有獨佔的緩存空間L1, L2

   Solution: 多個 CPU 核心裡面，都存在相同的數據的時候

   CPU1改了數據的時候，CPU2 不知道，CPU2改了數據時，CPU1不知道

   可以在 CPU 的總線上加鎖

   鎖分為兩類：(1) 總線鎖 (2) 緩存鎖

11. 1

12. 1

13. 1

14. 1

15. 1

16. 1

17. 1

18. 1

19. 1

20. 1