猴哥面經

前臺Contrller在用戶發起請求時用前臺發來的數據接參例如:
1,前臺定義的返回值類型是EazyUItable類型,參數是總記錄數和當前頁的具體數據
2,後臺經過接受這幾個參數,和返回值類型去數據庫查詢
3,返回給頁面
問題:在查詢完商品詳情信息後,商品類目顯示列爲亂碼,在jsp頁面查找了不少標籤的類型都是utf-8,都沒錯
後來百度了一下在RequsetMapping里加了一個屬性
produces: 指定返回值類型,不但能夠設置返回值類型還能夠設定返回值的字符編碼
consumes:指定處理請求的提交內容類型(Content-Type),例如application/json, text/html;html

1,在查詢時返回值類型爲具體的對象,和消息狀態值java

2,在刪除和修改時返回值類型爲一個封裝的值對象,一個是msg,status,data對象redis


3,文件上傳(MultipartFile uploadFile)(兩個工具,getname,transforto上傳)
1,獲取圖片信息
2,對其驗證,分文件儲存,加密
3,防止重名UUID
4,上傳路徑用nginux實現反向代理
5,上傳
6,前臺的url和參數是uploadFile算法

@PathVariable 是restful風格的註解spring

單點登陸系統
實現redis 的緩存登陸
1.用戶進行登陸操做時,輸入用戶名和密碼.
2. JT-WEB接收用戶請求時.將用戶信息進行封裝對用戶密碼進行加密,利用httpClient技術,發送給JT-SSO.單點登陸系統.
3. JT-SSO單點登陸系統,接收前臺數據以後進行校驗.若是用戶名和密碼不正確.直接提示返回.
4. 若是用戶名和密碼正確.首先生成加密的祕鑰惟一key:token,以後將user轉化爲JSON數據.保存到Redis中.以後返回給JT-WEB token數據.
5. JT-WEB接收JT-SSO的返回值數據.把數據轉化成對象,從這個對象中獲取token數據,若是用戶名密碼不正確則友好提示給用戶.
若是用戶名和密碼正確,將token數據保存到用戶瀏覽器的Cookie中.
5.返回封裝的對象
6.當登陸事後,跳轉到主頁面時,經過Ajax,Jsonp異步請求回顯用戶登陸信息,同過redis獲取token,用回調函數返回給頁面.sql

 


日誌模塊docker

查看日誌,經過url,和參數username和當前頁的數據來查詢數據庫並返回封裝的值對象
刪除日誌根據url和ids數據庫

添加日誌切面
1,添加一個日誌的註解類
2,添加一個日誌的切面@around通知
2.1 定義切入點和鏈接點
2.2 在執行目標方法後執行添加日誌的操做
3,添加日誌
3.1 用戶登陸後信息是存在subject中的,從subject中獲取用戶信息
3.2 用工具類獲取用戶RequestContextHolder.getRequestAttributes()).getRequest()獲取request對象
3.3 根據鏈接點獲取方法簽名
3.4 獲取類對象,獲取目標方法名和參數
3.5 獲取目標方法上的註解的屬性值(作了什麼操做)
3.6 獲取執行時長
3.7 設置建立的時長
3.8 把參數封裝成對象添加到數據庫中json

 


1.優化sql語句
1.1 儘量根據主鍵查詢
1.2 儘量單表查詢,將訪問的壓力交給tomcat服務器,能夠經過集羣的方式解決,極大減輕數據庫的開銷
①選擇最有效率的表名順序
數據庫的解析器按照從右到左的順序處理FROM子句中的表名,FROM子句中寫在最後的表將被最早處理
②WHERE子句中的鏈接順序
數據庫採用自右而左的順序解析WHERE子句,根據這個原理,表之間的鏈接必須寫在其餘WHERE條件之左,那些能夠過濾掉最大數量記錄的條件必須寫在WHERE子句的之右。bootstrap

1.3 若是進行關聯查詢時,應該提前肯定數據,以後關聯查詢,減小笛卡爾積(關聯的次數)

1.4 少用數據庫函數 max/min 分組 hive
2.添加索引和視圖(續表)
3.添加緩存(Redis/MemCache)
1.1非關係型數據庫
1.2讀寫速度快,10萬吞吐每秒
4.按期進行數據轉儲(將不用的數據,存儲到歷史表中(銀行的流水))
5.可使用高性能非關係型數據庫儲存.(redis/hbase),讀寫速度快
6.分庫分表(貴/運維)
2數據庫防止數據的丟失?
在archivelog mode(歸檔模式)只要其歸檔日誌文件不丟失,就能夠有效地防止數據丟失。


docker 管理鏡像和容器,docker保證數據的一致性,能快速裝多個容器

實現秒殺業務
1,在秒殺開始前 把要秒殺商品放入隊列中.例如5個商品
2,在redis中設置一個key,設置它的消亡時間.
3,在用戶訪問時首先先拿到一個key,若是沒有拿到就直接友好返回,拿到key的用戶把用戶id ,push進入到redis list集合中.
4,而後從list集合中pop出第一個用戶,訪問咱們的隊列,若是隊列中有就取數據,隊列中沒有就友好返回
5,當用戶取出數據,確認訂單支付時,咱們把確認的數據持久化到數據庫中
6,依次執行,當隊列中沒有數據時,直接友好提示並返回下次再來.

solr實現 SolrClient
比模糊查詢速度快
分詞器就是IKAnalyzer中文分詞器,它有細粒度切分和智能切分,即根據某種智能算法。
luncence實現了倒排索引技術\
普通域查詢
複製域查詢
動態域查詢
分頁查詢
分組查詢
高亮查詢
過濾查詢
區間查詢
排序查詢

 

 

 

 

AOP理解

定義切入點
定義通知
在須要添加切面的方法上添加切入點

在執行方法事後添加日誌信息
1 獲取用戶信息
2 獲取ip
3 獲取方法簽名
4 獲取目標類
5 獲取目標方法上的註解
6 讀取註解的屬性值
7 獲取目標方法,和參數
8 完成日誌對象封裝
9 返回執行結果

緩存的Aop實現
ReadWriteLockLruCache<CacheKey,Object> cacheMap
=new ReadWriteLockLruCache<>(3);

1,定義一個惟一的key(類名加方法名加參數名)定義一個工具類CacheKey
2,獲取到目標類,方法和參數
3,封裝到這個工具類CacheKey
4,首先先從這個緩存中獲取,若是有就直接返回
5,若是沒有就執行目標方法,
6,並將結果放入緩存中

 

shiro理解
它是一個安全礦建,實現用戶的認證,受權,加密,會話管理等,使用shiro快速完成認證,受權等開發,下降系統成本
1)Subject(主體):與軟件交互的一個特定的實體(用戶、第三方服務等)。
2)SecurityManager(安全管理器) :Shiro 的核心,用來協調管理組件工做。
3)Authenticator(認證管理器):負責執行認證操做
4)Authorizer(受權管理器):負責受權檢測
5)SessionManager(會話管理):負責建立並管理用戶 Session 生命週期,提供一個強有力的 Session 體驗。
6)SessionDAO:表明 SessionManager 執行 Session 持久(CRUD)動做,它容許任何存儲的數據掛接到 session 管理基礎上。
7)CacheManager(緩存管理器):提供建立緩存實例和管理緩存生命週期的功能
8)Cryptography(加密管理器):提供了加密方式的設計及管理。
9)Realms(領域對象):是shiro和你的應用程序安全數據之間的橋樑。

 

cookie清除怎麼辦
策略1:實現URL重寫技術.
例子:http://www.jt.com/cart/addCart?sessionId=XXXXXXX
步驟:
1.生成SessionId
2.將SessionId保存到域中.
3.發起請求時動態獲取SessionId進行url拼接.
問題:
1.每次發請求都須要進行數據的拼接.
2.業務層,必須先獲取SessionId,以後保存到域中.每一個方法都須要添加該操做.
b,如何進行url重寫。


encodeURL方法用在連接地址、表單提交地址。

response.encodeURL(String url);

encodeRedirectURL方法用於重定向地址。

response.encodeRedirectURL(String url);

 

 

建立線程的3中方式
1 繼承tread

優勢 : 編寫簡單,訪問當前線程直接用this便可得到
缺點 : 繼承thread 就不能繼承其餘類

2 實現runable接口

優勢 : 能夠繼承其餘類.多個線程能夠共享同一個目標
缺點 : 沒有返回值,並且不能拋出異常

3 實現callable接口 中的call方法有返回值

優勢 : 有返回值,能夠拋出異常
缺點 : 使用複雜

list
arrayList
linkedList

 


map
hash

 

 


springBoot經常使用註解
@SpringBootApplication註解的流程
@Target(ElementType.TYPE) // 註解的適用範圍,其中TYPE用於描述類、接口(包括包註解類型)或enum聲明
@Retention(RetentionPolicy.RUNTIME) // 註解的生命週期,保留到class文件中(三個生命週期)
@Documented // 代表這個註解應該被javadoc記錄
@Inherited // 子類能夠繼承該註解

如下爲重點
@SpringBootConfiguration // 繼承了Configuration,表示當前是註解類
@EnableAutoConfiguration // 開啓springboot的註解功能,springboot的四大神器之一,其藉助@import的幫助
@ComponentScan(excludeFilters = { // 掃描路徑設置(具體使用待確認)
@Configuration以後,自己其實也是一個IoC容器的配置類。
@ComponentScan的功能其實就是自動掃描並加載符合條件的組件
@EnableAutoConfiguration也是藉助@Import的幫助,將全部符合自動配置條件的bean定義加載到IoC容器,僅此而已!

@SpringBootApplication
@Configuration //配置類
@PropertySource(value="classpath:/properties/redis.properties")
@Value
@Bean
@Component
@JsonIgnoreProperties

@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration

 

 

數據庫的添加字段

alter 表 add 字段

 

 

redis理解
首先redis是能夠作數據庫,緩存和消息隊列,key-value結構進行儲存.
支持的結構有string,list,hash,set,zset
pexpire 設置key失效時間
redis的事務
Multi:都會開啓事務
Exec:提交
Discard 回滾

redis在項目中用到
1,單點登陸系統
2,商品類目


redis 攔截器,過濾器 數據庫索引 jdk動態代理 微服務的優勢和缺點爲何要用

攔截器的執行順序:

1, 正常狀況所有放行
2, 1pre 2pre 2post 1post 2after 1after

3, 非正常 第一個攔截放行,第二個攔截器攔截
1 pre 2 pre 1 after
攔截器1放行,攔截器2 preHandle纔會執行。

攔截器2 preHandle不放行,攔截器2 postHandle和afterCompletion不會執行。

只要有一個攔截器不放行,postHandle不會執行。


3, 第一個攔截器攔截,第二個攔截器攔截
攔截器1 preHandle不放行,postHandle和afterCompletion不會執行。

攔截器1 preHandle不放行,攔截器2不執行。


過濾前-攔截前-Action處理-攔截後-過濾後

過濾器和攔截器的區別
過濾器



redis 緩存機制

? ?(1) 速度快,由於數據存在內存中,相似於HashMap,HashMap的優點就是查找和操做的時間複雜度都是O(1)?
? ?(2) 支持豐富數據類型,支持string,list,set,sorted set,hash?
? ?(3) 支持事務,操做都是原子性,所謂的原子性就是對數據的更改要麼所有執行,要麼所有不執行?
? ?(4) 豐富的特性:可用於緩存,消息,按key設置過時時間,過時後將會自動刪除


索引
例子
一、若是每次都須要取到全部表記錄,不管如何都必須進行全表掃描了,那麼是否加索引也沒有意義了。
二、對非惟一的字段,例如「性別」這種大量重複值的字段,增長索引也沒有什麼意義。
三、對於記錄比較少的表,增長索引不會帶來速度的優化反而浪費了存儲空間,
由於索引是須要存儲空間的,並且有個致命缺點是對於update/insert/delete的每次執行,
字段的索引都必須從新計算更新。因此並非任何狀況下都改創建索引的


優勢

第一, 經過建立惟一性索引,能夠保證數據庫表中每一行數據的惟一性。
第二, 能夠大大加快數據的檢索速度,這也是建立索引的最主要的緣由。
第三, 能夠加速表和表之間的鏈接,特別是在實現數據的參考完整性方面特別有意義。
第四, 在使用分組和排序子句進行數據檢索時,一樣能夠顯著減小查詢中分組和排序的時間。
第五, 經過使用索引,能夠在查詢的過程當中,使用優化隱藏器,提升系統的性能。

缺點

第一, 建立索引和維護索引要耗費時間,這種時間隨着數據量的增長而增長。
第二, 索引須要佔物理空間,除了數據表佔數據空間以外,每個索引還要佔必定的物理空間,若是要創建聚簇索引,那麼須要的空間就會更大。
第三, 當對錶中的數據進行增長、刪除和修改的時候,索引也要動態的維護,這樣就下降了數據的維護速度。

3、建立方向索引的準則


索引是創建在數據庫表中的某些列的上面。所以,在建立索引的時候,應該仔細考慮在哪些列上能夠建立索引,在哪些列上不能建立索引。
通常來講,應該在這些列上建立索引。

第一, 在常常須要搜索的列上,能夠加快搜索的速度;
第二, 在做爲主鍵的列上,強制該列的惟一性和組織表中數據的排列結構;
第三, 在常常用在鏈接的列上,這些列主要是一些外鍵,能夠加快鏈接的速度;
第四, 在常常須要根據範圍進行搜索的列上建立索引,由於索引已經排序,其指定的範圍是連續的;
第五, 在常常須要排序的列上建立索引,由於索引已經排序,這樣查詢能夠利用索引的排序,加快排序查詢時間;
第六, 在常用在WHERE子句中的列上面建立索引,加快條件的判斷速度。

一樣,對於有些列不該該建立索引。通常來講,不該該建立索引的的這些列具備下列特色:

第一, 對於那些在查詢中不多使用或者參考的列不該該建立索引。
這是由於,既然這些列不多使用到,所以有索引或者無索引,並不能提升查詢速度。
相反,因爲增長了索引,反而下降了系統的維護速度和增大了空間需求。

第二, 對於那些只有不多數據值的列也不該該增長索引。
這是由於,因爲這些列的取值不多,例如人事表的性別列,在查詢的結果中,
結果集的數據行佔了表中數據行的很大比例,即須要在表中搜索的數據行的比例很大。
增長索引,並不能明顯加快檢索速度。

第三, 對於那些定義爲text, image和bit數據類型的列不該該增長索引。
這是由於,這些列的數據量要麼至關大,要麼取值不多。

第四,當修改性能遠遠大於檢索性能時,不該該建立索引。這是由於,修改性能和檢索性能是互相矛盾的。
當增長索引時,會提升檢索性能,可是會下降修改性能。當減小 索引時,會提升修改性能,下降檢索性能。
所以,當修改性能遠遠大於檢索性能時,不該該建立索引。

 


sleep和wait

從使用角度看,sleep是Thread線程類的方法,而wait是Object頂級類的方法。

sleep能夠在任何地方使用,而wait只能在同步方法或者同步塊中使用。

CPU及資源鎖釋放

sleep,wait調用後都會暫停當前線程並讓出cpu的執行時間,但不一樣的是sleep不會釋放當前持有的對象的鎖資源,
到時間後會繼續執行,而wait會放棄全部鎖並須要notify/notifyAll後從新獲取到對象鎖資源後才能繼續執行。

異常捕獲

sleep須要捕獲或者拋出異常,而wait/notify/notifyAll不須要。

 

 


正向代理和反向代理

正向代理是代理的客戶端,而服務端不知道是哪一個客戶端

反向代理是代理的服務端,而客戶端不知道是哪一個服務器


TimerTask 和 Quartz比較

精確度和功能

Quartz能夠經過cron表達式精確到特定時間執行,而TimerTask不能。Quartz擁有TimerTask全部的功能

quartz每次都是新建任務,不影響其餘任務 而timer一個任務失敗就所有失敗

 

TCP/IP:四層模型。

①網絡接口層:對應物理層和數據鏈路層。

②網絡層

③傳輸層

④應用層:包括會話層、表示層、應用層。

(1)OSI:七層模型。


①物理層:在物理信道上實現原始比特流的傳輸。(以太網,?IEEE 802.2 等)


②數據鏈路層:實現無差錯地將數據幀從一個節點傳送到下一個相鄰節點。(Wi-Fi(IEEE 802.11) , WiMAX(IEEE 802.16), ?GPRS, HDLC, PPP 等協議)


③網絡層:實現將數據分組從源站經過網絡傳送到目的站,即網絡上一臺主機與另外一臺主機之間的數據傳輸。(IP, ICMP, IGMP, ARP, RARP, OSPF 等協議)


④傳輸層:實現源端到目的端數據的傳輸,即某主機的某進程與另外一臺主機的某進程之間的數據傳輸。(TCP, UDP 等協議)


⑤會話層:實如今不一樣機器上用戶創建、維護和終止會話關係。即會話層對會話提供控制管理服務、會話同步服務等。(ZIP, ASP, SSH 等協議)


⑥表示層:確保各類通訊設備可以互相操做,不及考慮其數據的內部表示。即確保即便各類通訊設備其數據的內部表示不一樣,但仍然能相互正確操做。(SSL等協議)


⑦應用層:使用戶可以訪問網絡,爲各種應用提供相應的服務、提供各類用戶接口支持服務。應用層不是應用程序,應用層是一個爲應用程序提供各種應用支持的服務層。(HTTP, FTP, SMTP, POP3, DHCP, DNS等協議)

htto請求到響應的過程

1. 域名解析
2. 發起TCP的3次握手
3. 創建TCP鏈接後發起http請求
4. 服務器端響應http請求,瀏覽器獲得html代碼
5. 瀏覽器解析html代碼,並請求html代碼中的資源
6. 瀏覽器對頁面進行渲染呈現給用戶

 

 


Eureka 若是不加安全控制,會存在下列問題:

Eureka 控制檯能夠看到各服務的狀態和參數等信息,若是不加控制,只要知道註冊中心的地址,就能夠登陸上去看到各服務信息;
只要知道註冊中心地址,服務提供者就能夠註冊上來,對外提供服務;
只要知道註冊中心地址,服務消費者就能夠發現註冊中心的服務,並調用服務;
爲了安全起見,咱們仍是爲 Eureka 增長安全控制,這裏用 Spring Security 實現最基礎的用戶名、密碼控制。

一個小知識點而已,幾個配置就能夠完成。

1. maven 包引用

在服務註冊中心項目的 pom.xml 文件中引入 Spring Security 包。

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
2.增長應用配置

在應用配置文件中增長關於 security 的配置,通常是放在 application.yml ,可是本項目中分了 application.yml 和 bootstrap.yml 兩個配置文件,因此我這裏是放在了 application.yml 中。

spring:
application:
name: kite-eureka-center
security:
user:
name: test # 用戶名
password: 123456 # 密碼
此時,啓動並訪問 Eureka 管理控制檯,會提示輸入用戶名和密碼,輸入上面的 name 和 password 便可。

3.服務提供者註冊服務

在服務提供者的應用配置文件中作如下修改便可

eureka: instance: statusPageUrlPath: /actuator/info healthCheckUrlPath: /actuator/health prefer-ip-address: true client: register-with-eureka: true fetch-registry: true service-url: defaultZone: http://test:123456@localhost:3000/eureka/上述配置與沒有安全控制的時候惟一的差異就是在 defaultZone 指定的 eureka 地址。在地址中增長了用戶名和密碼。

相關文章
相關標籤/搜索