JAVA關鍵詞彙
一: java
記錄java項目中的關鍵詞彙
1.1 HandleInterceptor攔截器
SpringMVC的處理器攔截器,類似於Servlet開發中的過濾器Filter,用於對請求進行攔截和處理。
- preHandle:在業務處理器處理請求之前被調用。預處理,可以進行編碼、安全控制、權限校驗等處理;
- postHandle:在業務處理器處理請求執行完成後,生成視圖之前執行。後處理(調用了Service並返回
- ModelAndView,但未進行頁面渲染),有機會修改ModelAndView (這個博主就基本不怎麼用了);
afterCompletion:在DispatcherServlet完全處理完請求後被調用,可用於清理資源等。返回處理(已經渲染
單個實現類的執行順序
preHandler -> Controller -> postHandler -> model渲染-> afterCompletion
1.2 instanceof
用來在運行時指出對象是否是特定類的一個實例,返回布爾類型
if (anObject instanceof String){
}else{
}
1.3 分佈式跟蹤技術
1.3.1 Dapper
- Dapper:大規模分佈式系統的跟蹤系統,幫助理解系統行爲,用於分析性能問題,
1.3.2 Sleuth框架
用於跟蹤服務的調用過程
Sleuth借鑑了Google Dapper的設計,先了解兩個概念
- Trace 表示整個跟蹤過程,從用戶發起請求到最終的響應。一次跟蹤包括多個跨度,這些跨度以樹狀結構進行保存。
- Span:跨度,表示一次調用的過程,一次跟蹤包含多次調用過程。假設用戶向A服務發起請求,A服務又要調用B服務,那麼此時將會產生兩個跨度。用戶調用A服務、A服務調用B服務。
1.3.3 RPC
- RPC(Remote Procedure Call Protocol)–遠程過程調用協議,它是一種通過網絡從遠程計算機程序上請求服務,而不需要了解底層網絡技術的協議
- RPC採用客戶機/服務器模式。請求程序就是一個客戶機,而服務提供程序就是一個服務器。
1.3.4 Zipkin
- Zipkin是一個分佈式跟蹤系統,主要用於收集、管理微服務產生的數據。Zipkin的設計基於Google Dapper,在實際用時,我們需要讓各個微服務Zipkin服務器報告過程數據。
- 對於Spring Cloud來說,已經提供了幾個模塊來實現數據報告功能,僅需要加入依賴,以及簡單配置,即可實現向Zipkin“寫入”數據
1.4 Thymeleaf
- Thymeleaf是一個流行的模板引擎,
- 頁面模板技術
- Thymeleaf的主要目標在於提供一種可被瀏覽器正確顯示的、格式良好的模板創建方式,因此也可以用作靜態建模。你可以使用它創建經過驗證的XML與HTML模板
傳統的Spring WEB技術,使用JSP頁面技術,spring boot 已不推薦,spring boot 支持以下頁面模板語言
- Thymeleaf
- FreeMarker
- Velocity
- Groovy
- JSP
二:註解
2.1 @Component
泛指組件,當組件不好歸類的時候,我們可以使用這個註解進行標記
三:理論
3.1 CAP理論
CAP理論:一個分佈式系統最多隻能同時滿足一致性(Consistency)、可用性(Availability)和分區容錯性(Partition tolerance)這三項中的兩項。
- 一致性:即更新操作成功並返回客戶端完成後,所有節點在同一時間的數據完全一致,所以,一致性,說的就是數據一致性。
- 可用性:服務一直可用,而且是正常響應時間。對於一個可用性的分佈式系統,每一個非故障的節點必須對每一個請求作出響應。所以,一般我們在衡量一個系統的可用性的時候,都是通過停機時間來計算的。
- 分區容錯性:分佈式系統在遇到某節點或網絡分區故障的時候,仍然能夠對外提供滿足一致性和可用性的服務。簡單點說,就是在網絡中斷,消息丟失的情況下,系統如果還能正常工作,就是有比較好的分區容錯性。
假設在N1和N2之間網絡斷開的時候,有用戶向N1發送數據更新請求,那N1中的數據V0將被更新爲V1,由於網絡是斷開的,所以分佈式系統同步操作M,所以N2中的數據依舊是V0;這個時候,有用戶向N2發送數據讀取請求,由於數據還沒有進行同步,應用程序沒辦法立即給用戶返回最新的數據V1,怎麼辦呢?
有二種選擇
- 第一,犧牲數據一致性,保證可用性。響應舊的數據V0給用戶;
- 第二,犧牲可用性,保證數據一致性。阻塞等待,直到網絡連接恢復,數據更新操作M完成之後,再給用戶響應最新的數據V1。
這個過程,證明了要滿足分區容錯性的分佈式系統,只能在一致性和可用性兩者中,選擇其中一個。