SpringMVC處理請求的過程：
1、用戶發送請求，dispatchersevlet捕獲；
2、dispatchersevlet進行解析得到請求資源標誌符，然後調用HandlerMapping獲得該Handler配置的所有相關對象（包括Handler對象和對應的攔截器），最後以HandlerExcutionChain形式返回；
3、根據獲得的Handler選擇一個合適得HandlerAdapter（如果成功獲取HandlerAdapter後，將會執行攔截器的preHandler方法）；
4、提取request中的模型數據，填充Handler入參，開始執行Handler。在填充Handler的入參過程中，根據配置spring將做一些額外工作；
5、handler執行完成後，將向dispatcherservlet返回一個modelAndView對象；
6、根據返回的modelAndView選擇一個合適得視圖解析器，返回給dispatcherServlet；
7，視圖解析器（viewResolver）結合modelAndView，進行視圖渲染
8、將渲染結果返回給客戶端；
springboot自動配置原理：
在spring程序中的main方法中添加@SpringBootApplication或者EnableAutoConfiguration，Spring會自動去maven中讀取每個starter中的spring.factories文件，該文件配置了所有需要被創建的spring容器的bean
springcloud如何實現服務的註冊與發現？
服務發佈時，指定對應的服務名，將服務註冊到Euraka，這一過程是springcloud自動實現的，只需要在服務的main方法上添加@EnableDiscoveryClient，同一個服務修改端口就可實現啓動多個實例
調用方法：傳遞服務名，通過註冊中心獲取所有的可用實例，通過負載均衡策略調用（ribbon和feign）對應的服務
ribbon和feign的區別
ribbon添加maven依賴spring-starter-ribbon，使用@RibbonClient（value=“服務名”）使用RestTemplate調用遠程服務對應的方法
feign添加maven依賴spring-starter-feign，服務提供方提供對外接口，調用方在接口上使用@FeignClient（“服務名”）
1、啓動類註解不同，@RibbonClient，@FeignClient
2、服務指定的位置不同，Ribbon是在@RibbonClient註解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明
3、調用方式不同，Ribbon需要構建自己的http請求，模擬http請求然後使用RestTemplate發送給其他服務，相較繁瑣；Feign則只需要將調用其他服務的方法定義爲抽象方法即可，不需要構建自己的http請求。不過要注意抽象方法的註解和方法簽名要和提供服務的方法完全一致
springcloud斷路器的作用
當一個服務調用另一個服務時，由於網絡原因，調用者會等待被調用者的響應，當更多的請求到達這些資源的時候，導致更多的等待，這樣容易發生連鎖效應，斷路器就是爲了解決這一問題。
spring的運行原理：
IOC：spring利用反射原理（在運行期間進行動態創建），讓對象操作者不必再手動創建對象，spring將自動創建對象，將對象的創建和業務邏輯代碼剝離開來。
AOP：面向切面編程，爲某一對象或者方法進行監督和控制（在調用此方法前後調用指定的其他方法或模塊），從而達到一個模塊擴充的功能
目的：讓對象和對象之間的關係沒有通過代碼相互關聯，都是通過配置類進行管理
redis內存不夠怎麼處理：
redis內存模型【數據區，進程本身所需內存，緩衝內存，內存碎片】
處理方式：1、增加內存；2、使用內存淘汰策略；3、redis集羣
內存淘汰策略：LRU（least recentlyUsed）最近最少使用算法【隨機抽取三個鍵，刪除其中使用最少的鍵】
集羣處理：
redis僅支持單實例，內存一般在20G左右，當需緩存數據量過大時，就需要通過集羣進行配置
集羣方式【客戶端分片，代理分片，rediscluster】
客戶端分片：
通過業務代碼自定義路由（優勢：可以控制分片算法，性能比代理好；劣勢：維護成本高，擴容運維等需要自己研發）
代理分片：
代理根據業務程序的請求，根據路由規則，將這些請求分發給正確的redis實例並返回給業務程序，類似使用wemproxy，codis等中間件（優勢：運維方便，程序不關心如何連接redis；劣勢：會帶來性能消耗，無法平滑擴容，需要腳本遷移數據，不方便）
redis cluster：
官方集羣解決方案（優勢：無中心節點，和客戶端直連，性能較好；劣勢：方案太重，無法平滑擴容，需要執行相應的腳本）
redis服務器掛掉後怎麼恢復數據：
先停止，在複製，在啓動
RDB方式（默認）：數據庫出問題期間，RDB將不再進行，所以會造成一部分數據丟失；
AOF方式：類似日誌記錄等方式，將redis收到的每一條命令通過write函數追加到文件中，redis重啓後通過重新執行文件中保存的命令進行數據重建；
redis和memcache有什麼區別：
1、memcached還可以存儲圖片，視頻等
2、redis不僅支持K/V形式，同時也支持list set hash等數據結構
3、虛擬內存技術（當內存用完時，可以將一些很久沒有使用的value交換到硬盤）
4、過期策略不同，memcached在set時指定，redis還可以通過expire命令指定
5、分佈式方式，memcached利用magent一主多從，redis可自實現一主多從
6、數據安全，服務掛掉後，memcached數據丟失，redis可以恢復
7、redis支持數據備份
8、使用場景：redis（nosql，消息隊列，數據堆棧，數據緩存）；memcached（緩存sql語句，數據集，用戶臨時數據，延遲查詢數據，session）
redis爲什麼這麼快：
1、基於內存操作
2、數據結構簡單，操作也相對簡單
3、單線程，不用考慮線程競爭，鎖機制，避免上下文切換和互相競爭
4、使用多路I/O複用，費阻塞IO
5、底層實現VM，避免調用系統函數
spring bean的生命週期：
bean實例化（構造方法，工廠方法，反射）---setter注入（依賴注入）---根據實現接口，執行不同的方法---傳遞bean實例給前置處理器---調用初始化方法---將bean實例傳遞給後置處理器---使用---銷燬
springbean的作用域：
singleton：IOC只會存在一個共享的bean實例【創建容器的同時自動創建一個bean對象，不管使用與否，均存在，且每次調用與返回都是同一個對象，是spring的缺省作用域】
prototype：表示一個bean定義對應多個對象實例【每次對該bean進行請求時，都會創建一個新的bean對象；原形類型，創建容器的時候並沒有實例化，而是每次調用的時候進行實例化，且每次獲取的bean對象都不是同一個】
request：表示在一次http請求中都有自己的bean實例【僅在當前的http request內有效，可以放心更改當前bean實例的屬性和內部狀態】
session：在一個http session對應一個實例【同樣可以放心更改此實例的內部狀態】
global session：在一個全局的http session中，一個bean對應一個實例【只有在基於portel的web應用纔有效，類似於http session】
注：request，session global session 都僅在基於web的spring applicationcontext情形下才有效
springMVC處理請求的過程：
dispatcherservlet接受請求---handlerMapping找到相應的handlerAdapter---處理功能請求，返回modelAndView---viewResolver解析具體視圖【視圖渲染】---返回到前端
MySQL和Oracle的區別：
1、Oracle沒有自增主鍵，需要創建sequence，在insert的時候進行調用
2、語法層面（Oracle沒有limit，翻頁處理較爲繁瑣；Oracle自帶樹狀圖函數connect ）
3、字符串比較函數instr（字段名，‘字符串’）>0可以代替%like%
外鍵的作用：
1、表達參照的完整性；2、簡單直觀；3、確保數據有效性
多服務怎麼實現session共享：
1、通過數據庫實現session共享
2、通過cookie實現session共享
3、通過服務器數據同步實現
4、通過NFS【網絡文件服務器】（專門的session服務器）實現
5、通過memcached和redis實現
springcloud怎麼實現負載均衡：
zuul