中信銀行面試問題總結
1 sring loc aop 理解
IoC(Inversion of Control)是說建立物件的控制權進行轉移,以前建立物件的主動權和建立時機是由自己把控的,而現在這種權力轉移到第三方,比如轉移交給了IoC容器,它就是一個專門用來建立物件的工廠,你要什麼物件,它就給你什麼物件,有了 IoC容器,依賴關係就變了,原先的依賴關係就沒了,它們都依賴IoC容器了,通過IoC容器來建立它們之間的關係。
Loc 好處:第一,資源集中管理,實現資源的可配置和易管理。第二,降低了使用資源雙方的依賴程度,也就是我們說的耦合度。
在OOP中,正是這種分散在各處且與物件核心功能無關的程式碼(橫切程式碼)的存在,使得模組複用難度增加。AOP則將封裝好的物件剖開,找出其中對多個物件產生影響的公共行為,並將其封裝為一個可重用的模組,這個模組被命名為“切面”(Aspect),切面將那些與業務無關,卻被業務模組共同呼叫的邏輯提取並封裝起來,減少了系統中的重複程式碼,降低了模組間的耦合度,同時提高了系統的可維護性。
許可權認證、日誌、事物。AOP的作用在於分離系統中的各種關注點,將核心關注點和橫切關注點分離開來。
2.BeanFactory與ApplicationContext
ApplicationContext是BeanFactory的子介面,也被稱為應用上下文。BeanFactory提供了Spring的配置框架和基本功能,ApplicationContext則添加了更多企業級功能(如國際化的支援),他另一重要優勢在於當ApplicationContext容器初始化完成後,容器中所有的 singleton Bean 也都被例項化了,也就是說當你需要使用singleton Bean 是,在應用中無需等待就可以用,而其他BeanFactory介面的實現類,則會延遲到呼叫 getBean()方法時構造,ApplicationContext的初始化時間會稍長些,呼叫getBean()是由於Bean已經構造完畢,速度會更快。因此大部分系統都使用ApplicationContext,而只在資源較少的情況下,才考慮使用BeanFactory。
3. mybatis 一級快取和二級快取
一級快取是SqlSession級別的快取。在操作資料庫時需要構造 sqlSession物件,在物件中有一個(記憶體區域)資料結構(HashMap)用於儲存快取資料。不同的sqlSession之間的快取資料區域(HashMap)是互相不影響的。
一級快取的作用域是同一個SqlSession,在同一個sqlSession中兩次執行相同的sql語句,第一次執行完畢會將資料庫中查詢的資料寫到快取(記憶體),第二次會從快取中獲取資料將不再從資料庫查詢,從而提高查詢效率。當一個sqlSession結束後該sqlSession中的一級快取也就不存在了。Mybatis預設開啟一級快取。
二級快取是mapper級別的快取,多個SqlSession去操作同一個Mapper的sql語句,多個SqlSession去操作資料庫得到資料會存在二級快取區域,多個SqlSession可以共用二級快取,二級快取是跨SqlSession的。
二級快取是多個SqlSession共享的,其作用域是mapper的同一個namespace,不同的sqlSession兩次執行相同namespace下的sql語句且向sql中傳遞引數也相同即最終執行相同的sql語句,第一次執行完畢會將資料庫中查詢的資料寫到快取(記憶體),第二次會從快取中獲取資料將不再從資料庫查詢,從而提高查詢效率。Mybatis預設沒有開啟二級快取需要在setting全域性引數中配置開啟二級快取
4, jvm 記憶體模型 如何防止記憶體洩露??
名稱 |
特徵 |
作用 |
配置引數 |
異常 |
程式計數器 |
佔用記憶體小,執行緒私有, 生命週期與執行緒相同 |
大致為位元組碼行號指示器 |
無 |
無 |
虛擬機器棧 |
執行緒私有,生命週期與執行緒相同,使用連續的記憶體空間 |
Java 方法執行的記憶體模型,儲存區域性變量表、操作棧、動態連結、方法出口等資訊 |
-Xss |
StackOverflowError OutOfMemoryError |
java堆 |
執行緒共享,生命週期與虛擬機器相同,可以不使用連續的記憶體地址 |
儲存物件例項,所有物件例項(包括陣列)都要在堆上分配 |
-Xms -Xmx -Xmn |
OutOfMemoryError |
方法區 |
執行緒共享,生命週期與虛擬機器相同,可以不使用連續的記憶體地址 |
儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料 |
-XX:PermSize: 16M -XX:MaxPermSize 64M |
OutOfMemoryError |
執行時常量池 |
方法區的一部分,具有動態性 |
存放字面量及符號引用 |
|
|
5.多執行緒 實現方式 執行緒同步
1、繼承Thread類實現多執行緒
2、實現Runnable介面方式實現多執行緒
3、使用ExecutorService、Callable、Future實現有返回結果的多執行緒
一、同步方法
即有synchronized關鍵字修飾的方法。 由於java的每個物件都有一個內建鎖,當用此關鍵字修飾方法時, 內建鎖會保護整個方法。在呼叫該方法前,需要獲得內建鎖,否則就處於阻塞狀態。
二、同步程式碼塊
即有synchronized關鍵字修飾的語句塊。 被該關鍵字修飾的語句塊會自動被加上內建鎖,從而實現同步
三、wait與notify
wait():使一個執行緒處於等待狀態,並且釋放所持有的物件的lock。
sleep():使一個正在執行的執行緒處於睡眠狀態,是一個靜態方法,呼叫此方法要捕捉InterruptedException異常。
notify():喚醒一個處於等待狀態的執行緒,注意的是在呼叫此方法的時候,並不能確切的喚醒某一個等待狀態的執行緒,而是由JVM確定喚醒哪個執行緒,而且不是按優先順序。
notifyAll():喚醒所有處入等待狀態的執行緒,注意並不是給所有喚醒執行緒一個物件的鎖,而是讓它們競爭。
詳細見:wait、notify、notifyAll的使用方法
四、使用特殊域變數(volatile)實現執行緒同步
五、使用重入鎖實現執行緒同步
在JavaSE5.0中新增了一個java.util.concurrent包來支援同步。
ReentrantLock類是可重入、互斥、實現了Lock介面的鎖,它與使用synchronized方法和快具有相同的基本行為和語義,並且擴充套件了其能力。
六、使用區域性變數實現執行緒同步
如果使用ThreadLocal管理變數,則每一個使用該變數的執行緒都獲得該變數的副本,副本之間相互獨立,這樣每一個執行緒都可以隨意修改自己的變數副本,而不會對其他執行緒產生影響。
七、使用阻塞佇列實現執行緒同步
前面5種同步方式都是在底層實現的執行緒同步,但是我們在實際開發當中,應當儘量遠離底層結構。 使用javaSE5.0版本中新增的java.util.concurrent包將有助於簡化開發。 本小節主要是使用LinkedBlockingQueue<E>來實現執行緒的同步 LinkedBlockingQueue<E>是一個基於已連線節點的,範圍任意的blocking queue。 佇列是先進先出的順序(FIFO),關於佇列以後會詳細講解~LinkedBlockingQueue 類常用方法 LinkedBlockingQueue() : 建立一個容量為Integer.MAX_VALUE的LinkedBlockingQueue put(E e) : 在隊尾新增一個元素,如果佇列滿則阻塞 size() : 返回佇列中的元素個數 take() : 移除並返回隊頭元素,如果佇列空則阻塞程式碼例項: 實現商家生產商品和買賣商品的同步
6.雲架構的瞭解,Spring cloud,應用伺服器用了幾個?併發多少,效能?
Spring Cloud 為開發者提供了在分散式系統(配置管理,服務發現,熔斷,路由,微代理,控制匯流排,一次性token,全居瑣,leader選舉,分散式session,叢集狀態)中快速構建的工具,使用Spring Cloud的開發者可以快速的啟動服務或構建應用、同時能夠快速和雲平臺資源進行對接。
應用伺服器 tomcat jboss weblogic jetty 根據你平時實際用到說不熟悉不要說出來
Qps每秒請求數
50QPS以下——小網站
沒什麼好說的,簡單的小網站而已,就如同本站這樣,你可以用最簡單的方法快速搭建,短期沒有太多的技術瓶頸,只要伺服器不要太爛就好。
50~100QPS——DB極限型
大部分的關係型資料庫的每次請求大多都能控制在0.01秒左右,即便你的網站每頁面只有一次DB請求,那麼頁面請求無法保證在1秒鐘內完成100個請求,這個階段要考慮做Cache或者多DB負載。無論那種方案,網站重構是不可避免的。
300~800QPS——頻寬極限型
目前伺服器大多用了IDC提供的“百兆頻寬”,這意味著網站出口的實際頻寬是8M Byte左右。假定每個頁面只有10K Byte,在這個併發條件下,百兆頻寬已經吃完。首要考慮是CDN加速/異地快取,多機負載等技術。
500~1000QPS——內網頻寬極限+Memcache極限型
由於Key/value的特性,每個頁面對memcache的請求遠大於直接對DB的請求,Memcache的悲觀併發數在2w左右,看似很高,但事實上大多數情況下,首先是有可能在次之前內網的頻寬就已經吃光,接著是在8K QPS左右的情況下,Memcache已經表現出了不穩定,如果程式碼上沒有足夠的優化,可能直接將壓力轉嫁到了DB層上,這就最終導致整個系統在達到某個閥值之上,效能迅速下滑。
1000~2000QPS——FORK/SELECT,鎖模式極限型
好吧,一句話:執行緒模型決定吞吐量。不管你係統中最常見的鎖是什麼鎖,這個級別下,檔案系統訪問鎖都成為了災難。這就要求系統中不能存在中央節點,所有的資料都必須分佈儲存,資料需要分佈處理。總之,關鍵詞:分佈
2000QPS以上——C10K極限
儘管現在很多應用已經實現了C25K,但短板理論告訴我們,決定網站整體併發的永遠是最低效的那個環節。我承認我生涯中從未遇到過2000QPS以上,甚至1.5K以上的網站,希望有此經驗的哥們可以一起交流下
高併發效能問題
1、HTML靜態化
2、圖片伺服器分離
3、資料庫叢集、庫表雜湊
4、快取
5、負載均衡
6、映象 容器 docker 技術
7.Spring 7層
8. 人行渠道採用什麼方式,格式什麼?其他渠道要熟悉?
人行查詢回的資料:人基本資訊,貸款資訊,借記卡,信用卡資訊,webservice
加密方式:https 埠加密or數字簽名CA
9 sql 優化
1.對查詢進行優化,要儘量避免全表掃描,首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應儘量避免在 where 子句中對欄位進行 null 值判斷,否則將導致引擎放棄使用索引而進行全表掃描,如:
select idfrom twhere numis null
最好不要給資料庫留NULL,儘可能的使用 NOT NULL填充資料庫.
備註、描述、評論之類的可以設定為 NULL,其他的,最好不要使用NULL。
不要以為 NULL 不需要空間,比如:char(100) 型,在欄位建立時,空間就固定了, 不管是否插入值(NULL也包含在內),都是佔用 100個字元的空間的,如果是varchar這樣的變長欄位, null 不佔用空間。
可以在num上設定預設值0,確保表中num列沒有null值,然後這樣查詢:
select idfrom twhere num= 0
3.應儘量避免在 where 子句中使用 != 或 <> 操作符,否則將引擎放棄使用索引而進行全表掃描。
4.應儘量避免在 where 子句中使用 or 來連線條件,如果一個欄位有索引,一個欄位沒有索引,將導致引擎放棄使用索引而進行全表掃描,如:
select idfrom twhere num=10 or Name= 'admin'
可以這樣查詢:
select idfrom twhere num= 10union allselect idfrom twhere Name= 'admin'
5.in 和 not in 也要慎用,否則會導致全表掃描,如:
select idfrom twhere numin(1,2,3)
對於連續的數值,能用 between 就不要用 in 了:
select idfrom twhere numbetween 1 and 3
很多時候用 exists 代替 in 是一個好的選擇:
select numfrom awhere numin(select numfrom b)
用下面的語句替換:
select numfrom awhere exists(select 1 from bwhere num=a.num)
6.下面的查詢也將導致全表掃描:
select idfrom twhere namelike ‘%abc%’
若要提高效率,可以考慮全文檢索。
7.如果在 where 子句中使用引數,也會導致全表掃描。因為SQL只有在執行時才會解析區域性變數,但優化程式不能將訪問計劃的選擇推遲到執行時;它必須在編譯時進行選擇。然 而,如果在編譯時建立訪問計劃,變數的值還是未知的,因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描:
select idfrom twhere num= @num
可以改為強制查詢使用索引:
select idfrom twith(index(索引名))where num= @num
應儘量避免在 where 子句中對欄位進行表示式操作,這將導致引擎放棄使用索引而進行全表掃描。如:
select idfrom twhere num/2= 100
應改為:
select idfrom twhere num= 100*2
9.應儘量避免在where子句中對欄位進行函式操作,這將導致引擎放棄使用索引而進行全表掃描。如:
select idfrom twhere substring(name,1,3)= ’abc’ -–name以abc開頭的idselect idfrom twhere datediff(day,createdate,’2005-11-30′)= 0 -–‘2005-11-30’ --生成的id
應改為:
select idfrom twhere namelike 'abc%'select idfrom twhere createdate>= '2005-11-30' and createdate< '2005-12-1'
10.不要在 where 子句中的“=”左邊進行函式、算術運算或其他表示式運算,否則系統將可能無法正確使用索引。
11.在使用索引欄位作為條件時,如果該索引是複合索引,那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引,否則該索引將不會被使用,並且應儘可能的讓欄位順序與索引順序相一致。
12.不要寫一些沒有意義的查詢,如需要生成一個空表結構:
select col1,col2into #tfrom twhere 1=0
這類程式碼不會返回任何結果集,但是會消耗系統資源的,應改成這樣:
create table #t(…)
13.Update 語句,如果只更改1、2個欄位,不要Update全部欄位,否則頻繁呼叫會引起明顯的效能消耗,同時帶來大量日誌。
14.對於多張大資料量(這裡幾百條就算大了)的表JOIN,要先分頁再JOIN,否則邏輯讀會很高,效能很差。
15.select count(*) from table;這樣不帶任何條件的count會引起全表掃描,並且沒有任何業務意義,是一定要杜絕的。
16.索引並不是越多越好,索引固然可以提高相應的 select 的效率,但同時也降低了 insert 及 update 的效率,因為 insert 或 update 時有可能會重建索引,所以怎樣建索引需要慎重考慮,視具體情況而定。一個表的索引數最好不要超過6個,若太多則應考慮一些不常使用到的列上建的索引是否有 必要。
17.應儘可能的避免更新 clustered 索引資料列,因為 clustered 索引資料列的順序就是表記錄的物理儲存順序,一旦該列值改變將導致整個表記錄的順序的調整,會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引資料列,那麼需要考慮是否應將該索引建為 clustered 索引。
18.儘量使用數字型欄位,若只含數值資訊的欄位儘量不要設計為字元型,這會降低查詢和連線的效能,並會增加儲存開銷。這是因為引擎在處理查詢和連 接時會逐個比較字串中每一個字元,而對於數字型而言只需要比較一次就夠了。
19.儘可能的使用 varchar/nvarchar 代替 char/nchar ,因為首先變長欄位儲存空間小,可以節省儲存空間,其次對於查詢來說,在一個相對較小的欄位內搜尋效率顯然要高些。
20.任何地方都不要使用 select * from t ,用具體的欄位列表代替“*”,不要返回用不到的任何欄位。
21.儘量使用表變數來代替臨時表。如果表變數包含大量資料,請注意索引非常有限(只有主鍵索引)。
22. 避免頻繁建立和刪除臨時表,以減少系統表資源的消耗。臨時表並不是不可使用,適當地使用它們可以使某些例程更有效,例如,當需要重複引用大型表或常用表中的某個資料集時。但是,對於一次性事件, 最好使用匯出表。
23.在新建臨時表時,如果一次性插入資料量很大,那麼可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果資料量不大,為了緩和系統表的資源,應先create table,然後insert。
24.如果使用到了臨時表,在儲存過程的最後務必將所有的臨時表顯式刪除,先 truncate table ,然後 drop table ,這樣可以避免系統表的較長時間鎖定。
25.儘量避免使用遊標,因為遊標的效率較差,如果遊標操作的資料超過1萬行,那麼就應該考慮改寫。
26.使用基於遊標的方法或臨時表方法之前,應先尋找基於集的解決方案來解決問題,基於集的方法通常更有效。
27.與臨時表一樣,遊標並不是不可使用。對小型資料集使用 FAST_FORWARD 遊標通常要優於其他逐行處理方法,尤其是在必須引用幾個表才能獲得所需的資料時。在結果集中包括“合計”的例程通常要比使用遊標執行的速度快。如果開發時 間允許,基於遊標的方法和基於集的方法都可以嘗試一下,看哪一種方法的效果更好。
28.在所有的儲存過程和觸發器的開始處設定 SET NOCOUNT ON ,在結束時設定 SET NOCOUNT OFF 。無需在執行儲存過程和觸發器的每個語句後向客戶端傳送 DONE_IN_PROC 訊息。
29.儘量避免大事務操作,提高系統併發能力。
30.儘量避免向客戶端返回大資料量,若資料量過大,應該考慮相應需求是否合理。
10 tomcat 啟動引數設定 windows 和linux
.Linux:
在/usr/tomcat6/bin目錄下的catalina.sh檔案中,首先設定JAVA_HOME,linux下設定JAVA_HOME需要使用export指令,如:export JAVA_HOME=/usr/appserver/jdk1.6
然後新增jvm的JAVA_OPTS:JAVA_OPTS='-Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+PrintGCDetails -server'
linux下catalina.sh中完整程式碼如下:
2 3 4 5 |
export CATALINA_BASE=/usr/appserver/tomcat6 export CATALINA_HOME=/usr/appserver/tomcat6 export CATALINA_TMPDIR=/usr/appserver/tomcat6/temp export JAVA_HOME=/usr/appserver/jdk1.6 export JAVA_OPTS='-Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+PrintGCDetails -server' |
Windows
在catalina.bat最前面加入
set JAVA_OPTS=-Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+PrintGCDetails -server
如果用startup.bat啟動tomcat,OK設定生效.夠成功的分配1024M記憶體.
11 常用Linux命令?
1. Ls
2. Pwd
3. Mkdir
4. Rm rmdir
5. Mv
6. Cp
7. Cat
8. More
9. Find 10 chmod 11 tar 12 grep 13 kill 14 tenelt 15 service 16 ssh
12 tomcat叢集
1 tomcat 配置多臺tomcat 埠號
下面配置檔案中的幾個關鍵點:
(1)程序數與每個程序的最大連線數
#工作程序個數,一般跟伺服器cpu核數相等,或者核數的兩倍
worker_processes 2;
#單個程序最大連線數
events{
worker_connections 1024;
}
· 1
· 2
· 3
· 4
· 5
· 6
· 7
· 8
① nginx程序數,建議設定為和伺服器cup核數相等,或者是核數的兩倍
② 單個程序最大連線數,該伺服器的最大連線數=連線數*程序數;
伺服器支援最大併發數=(連線數*程序數) /2 ,因為反向代理是雙向的。
(2)Nginx的基本配置
#nginx基本配置server{
listen 8088; #埠號
server_name 192.168.22.227;#服務名
}
· 1
· 2
· 3
· 4
· 5
① 監聽埠一般都為http埠:80;可以修改為其他,這裡修改為8088。
② server_name :預設為localhost ,這裡修改為伺服器ip地址。
(3)負載均衡列表基本配置
#伺服器叢集
upstream mycluster{
#這裡新增的是上面啟動好的兩臺Tomcat伺服器
server 192.168.22.229:8080 weight=1;
server 192.168.22.230:8080 weight=1;
}
location /{
#將訪問請求轉向至伺服器叢集,mycluster和上面upstream mycluster 對應
proxy_pass http://mycluster;
# 真實的客戶端IP
proxy_set_header X-Real-IP $remote_addr;
# 請求頭中Host資訊
proxy_set_header Host $host;
# 代理路由資訊,此處取IP有安全隱患
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
·
① location / {}:負載均衡訪問的請求,可以新增篩選,假如我們要對所有的jsp字尾的檔案進行負載均衡時,可以這樣寫:location ~ .*.jsp$ {}
② proxy_pass:請求轉向自定義的伺服器列表,這裡我們將請求都轉向標識為http://mycluster的負載均衡伺服器列表;
③ 在負載均衡伺服器列表的配置中,Server指令:指定伺服器的ip地址,weight是權重,可以根據機器配置定義權重(如果某臺伺服器的硬體配置十分好,可以處理更多的請求,那麼可以為其設定一個比較高的weight;而有一臺的伺服器的硬體配置比較差,那麼可以將前一臺的weight配置為weight=2,後一臺差的配置為weight=1)。weigth引數表示權值,權值越高被訪問到的機率越大;
13 資料庫索引 建立
普通索引 新增INDEX
ALTER TABLE `table_name` ADD INDEX index_name ( `column` )
下面演示下給user表的name欄位新增一個索引
主鍵索引 新增PRIMARY KEY
ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )
唯一索引 新增UNIQUE
ALTER TABLE `table_name` ADD UNIQUE ( `column` )
全文索引 新增FULLTEXT
ALTER TABLE `table_name` ADD FULLTEXT ( `column`)
如何新增多列索引
ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )
14 微服務 spring boot
單體應用的不足
1. 邏輯複雜、模組耦合、程式碼臃腫,修改難度大,版本迭代效率低下
2. 系統啟動慢,一個程序包含了所有的業務邏輯,涉及到的啟動模組過多,導致系統的啟動、重啟時間週期過長
3. 系統錯誤隔離性差、可用性差,任何一個模組的錯誤均可能造成整個系統的宕機
4. 可伸縮性差;系統的擴容只能只對這個應用進行擴容,不能做到對某個功能點進行擴容
5. 線上問題修復週期長;任何一個線上問題修復需要對整個應用系統進行全面升級
微服務架構的優點
1. 分而治之;單個服務功能內聚,複雜性低;方便團隊的拆分和管理
2. 可伸縮;能夠單獨的對指定的服務進行伸縮
3. 迭代週期短;支援快速的迭代開發
4. 獨立部署,獨立開發
微服務架構的不足
1. 可維護性差;應用流程常常垮多個微服務,不易進行問題的定位
2. 效率相對低,團隊依賴強,一個服務的版本延遲會拖慢整個應用的開發週期
3. 開發難度大;垮服務的呼叫通常是不同的機器,甚至是不同的機房,開發人員需要處理超時、網路異常等問題
4. 應用級別的需求變動常常波及多個服務;
5. 分散式事務的支援
SpringBoot是伴隨著Spring4.0誕生的;
1) Spring Boot使編碼變簡單
2) Spring Boot使配置變簡單
3) Spring Boot使部署變簡單
4) Spring Boot使監控變簡單
Spring由於其繁瑣的配置,一度被人認為“配置地獄”,各種XML、Annotation配置,讓人眼花繚亂,而且如果出錯了也很難找出原因。
Spring Boot更多的是採用Java Config的方式,對Spring進行配置。
15 談下 ssm 架構
認真理解 ssm 和三層架構關係 每層用到什麼技術 不能含糊
為什麼要有架構?
這是為了滿足“低耦合,高內聚”,實現程式碼的健壯性和可擴充套件性。比如為了更好的降低各層間的耦合度,在三層架構程式設計中,採用面向抽象程式設計。即上層對下層的呼叫,是通過介面實現的。而下層對上層的真正服務提供者,是下層介面的實現類。服務標準(介面)是相同的,服務提供者(實現類)可以更換。
SSM主要由Spring,SpringMVC 和 Mybatis三個構成。它們在三層架構中所處的位置是不同的,即它們在三層架構中的功能各不相同,各司其職
1. SpringMVC:作為View層的實現者,完成使用者的請求接收功能。SpringMVC的Controller作為整個應用的控制器,完成使用者請求的轉發及對使用者的響應
2. MyBatis:作為 Dao層的實現者,完成對資料庫的增、刪、改、查功能
3. Spring:以整個應用大管家的身份出現。整個應用中所有的Bean的生命週期行為,均由Spring來管理。即整個應用中所有物件的建立、初始化、銷燬,及物件間關聯關係的維護,均由Spring進行管理
16 設計模式
一、設計模式的分類
總體來說設計模式分為三大類:
建立型模式,共五種:工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式,共七種:介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式,共十一種:策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。
17 負載均衡 技術
在網際網路高速發展的時代,大資料量、高併發等是網際網路網站提及最多的。如何處理高併發帶來的系統性能問題,最終大家都會使用負載均衡機制。它是根據某種負載策略把請求分發到叢集中的每一臺伺服器上,讓整個伺服器群來處理網站的請求。
公司比較有錢的,可以購買專門負責負載均衡的硬體(如:F5),效果肯定會很好。對於大部分公司,會選擇廉價有效的方法擴充套件整個系統的架構,來增加伺服器的吞吐量和處理能力,以及承載能力。
高可用(HA)
在叢集伺服器架構中,當主伺服器故障時,備份伺服器能夠自動接管主伺服器的工作,並及時切換過去,以實現對使用者的不間斷服務。ps:這裡我感覺它跟故障轉移(failover)是一個意思,看到的網友給個解釋,謝謝?
session複製/共享
在訪問系統的會話過程中,使用者登入系統後,不管訪問系統的任何資源地址都不需要重複登入,這裡面servlet容易儲存了該使用者的會話(session)。如果兩個tomcat(A、B)提供叢集服務時候,使用者在A-tomcat上登入,接下來的請求web伺服器根據策略分發到B-tomcat,因為B-tomcat沒有儲存使用者的會話(session)資訊,不知道其登入,會跳轉到登入介面。
這時候我們需要讓B-tomcat也儲存有A-tomcat的會話,我們可以使用tomcat的session複製實現或者通過其他手段讓session共享。
18 http 協議 get post put 幾個區別
簡單的說
就是整套CRUD(增刪改查)操作,C對應POST,R對應GET,U對應PUT,D對應DELETE。
在實際的做的時候,很多人卻沒有按照HTTP規範去做,導致這個問題的原因有很多,比如說:
1.很多人貪方便,更新資源時用了GET,因為用POST必須要到FORM(表單),這樣會麻煩一點。
2.對資源的增,刪,改,查操作,其實都可以通過GET/POST完成,不需要用到PUT和DELETE。
3.另外一個是,早期的但是Web MVC框架設計者們並沒有有意識地將URL當作抽象的資源來看待和設計 。還有一個較為嚴重的問題是傳統的Web MVC框架基本上都只支援GET和POST兩種HTTP方法,而不支援PUT和DELETE方法。
進一步解說
GET操作是安全的。所謂安全是指不管進行多少次操作,資源的狀態都不會改變。比如我用GET瀏覽文章,不管瀏覽多少次,那篇文章還在那,沒有變化。當然,你可能說每瀏覽一次文章,文章的瀏覽數就加一,這不也改變了資源的狀態麼?這並不矛盾,因為這個改變不是GET操作引起的,而是使用者自己設定的服務端邏輯造成的。
PUT,DELETE操作是冪等的。所謂冪等是指不管進行多少次操作,結果都一樣。比如我用PUT修改一篇文章,然後在做同樣的操作,每次操作後的結果並沒有不同,DELETE也是一樣。
POST操作既不是安全的,也不是冪等的,比如常見的POST重複載入問題:當我們多次發出同樣的POST請求後,其結果是創建出了若干的資源。
安全和冪等的意義在於:當操作沒有達到預期的目標時,我們可以不停的重試,而不會對資源產生副作用。從這個意義上說,POST操作往往是有害的,但很多時候我們還是不得不使用它。
19 maven
3.eclipse配置 maven:
(1). 點選 Add 按鈕,選到你本機安裝 Maven 的路徑值
(2)在Preferences-->Maven-->User Settings中,點選Update Settings,載入剛才我們 對settings.xml的更改
4.修改 maven 本地倉庫存放位置:
找到 apache-maven-3.0.4下的 conf 下的 settings.xml 配置檔案,我的是在 D:\Development\apache-maven-3.0.4\conf\settings.xml
apache-maven-3.0.4的倉庫預設是放在本地使用者的臨時資料夾下面的 .m2 資料夾下的 repository 下,我的是在 C:\Users\Administrator\.m2\repository 目錄下,
現在我們來修改將它指定到我們自己的路徑下,我現在要將倉庫指定到 D:/Development/m2/repository 目錄下,只需要將上面登出的本地倉庫開啟,
然後把相應的路徑值寫到裡面去就行了:
本地倉庫
設定本地倉庫到指定目錄,而不使用Maven預設的配置(預設放在C:/user/m2.目錄下)
開啟Maven的解壓目錄E:\soft\apache-maven-3.1.0\conf,修改settings.xml
配置localRepository即可完成本地倉庫的設定:
Xml程式碼
1. <localRepository>E:/repository/maven/repos</localRepository>
==================================================================
中心倉庫
即,告訴Maven從外網的哪個地方下載jar包
Maven的安裝目錄中,在lib目錄下,maven-model-builder-3.1.0.jar中,有一個預設的pom.xml檔案
其中就配置了Maven預設連線的中心倉庫
修改中心倉庫:
直接在POM.xml中加入repository的配置,指定一個新的url即可
注意:這裡仍然使用<id>central</id>,目的在於覆蓋Maven中的配置的id為central的repository!
Xml程式碼
1. <repositories>
2. <repository>
3. <id>central</id>
4. <name>My Central Repository</name>
5. <url>http://repo.maven.apache.org/maven2</url>
6. <layout>default</layout>
7. <snapshots>
8. <enabled>false</enabled>
9. </snapshots>
10. </repository>
11. </repositories>
==================================================================
私服
配置在區域網環境中,為區域網中所有開發人員提供jar包的統一管理
本地倉庫(本機)--->私服(區域網)--->中心倉庫(外部網路)
私服的安裝
1.下載NEXUS,http://www.sonatype.org
2.解壓
3.配置環境變數:
新建環境變數:NEXUS_HOME = E:\soft\nexus-2.5.1-01
加入到path中:%NEXUS_HOME%\bin;
4.開啟CMD命令列
C:\Users\Administrator>nexus install 安裝服務
C:\Users\Administrator>nexus start 啟動服務
C:\Users\Administrator>nexus uninstall 解除安裝服務
5.訪問私服
使用預設賬戶:admin 密碼:admin123
NEXUS內部使用Jetty作為伺服器
http://localhost:8081/nexus 【介面用extjs開發的】
倉庫的分類
檢視Repository
host倉庫--->內部專案的釋出倉庫
Snapshots 釋出內部snapshots版本的倉庫
Releases 釋出內部release版本的倉庫
3rd party 釋出第3方jar包的倉庫,如oracle資料庫驅動,open-189.jar
proxy倉庫--->從遠端中心倉庫查詢jar包的倉庫
Apache Snapshots 查詢Apache專案的快照版本的倉庫
Central 中心倉庫http://repo1.maven.org/maven2/
Codehaus Snapshots 查詢Codehaus 的快照版本的倉庫
group倉庫--->把倉庫按組劃分,以組為單位進行管理
virtual倉庫
私服的配置 / Repository的配置
在parent模組的pom.xml中加入私服的配置,讓Maven從私服下載jar包,而不直接去遠端倉庫下載。
預設情況下,Maven下載jar包將直接連線到外網http://repo1.maven.org/maven2/去下載;
安裝私服之後,讓Maven下載jar包先從私服查詢,如果沒有,再從外網下載並儲存在私服上
在POM在加入下面的配置,其中url為NEXUS私服的Public Repository對外的地址
以後,Maven下載構建(jar包或外掛)都將從這裡開始下載
Xml程式碼
1. <project>
2.
3. ...
4.
5. <!-- 配置私服地址 -->
6. <repositories>
7. <repository>
8. <id>nexus</id>
9. <url>http://localhost:8081/nexus/content/groups/public/</url>
10. <snapshots><enabled>true</enabled></snapshots>
11. <releases><enabled>true</enabled></releases>
12. </repository>
13. </repositories>
14. <pluginRepositories>
15. <pluginRepository>
16. <id>nexus</id>
17. <url>http://localhost:8081/nexus/content/groups/public/</url>
18. <snapshots><enabled>true</enabled></snapshots>
19. <releases><enabled>true</enabled></releases>
20. </pluginRepository>
21. </pluginRepositories>
22.
23. ...
24.
25. <project>
通過settings.xml來配置私服
由於所有的Maven專案都會用settings.xml中的配置進行解析,如果將Repository配置到這個檔案中,那麼對所有的Maven專案都將生效。
此時,Maven專案中的POM檔案就不需要再配置私服地址了!
注意:修改settings.xml檔案時,看IDE中關聯的是哪個settings檔案。
如C:\user\.m2目錄下可能存在,Maven的解壓目錄下也存在,具體修改哪個根據實際情況而定。如,Eclipse下,檢視Maven的User Settings選項即能看到關聯。
我的IDE關聯的是Maven\conf目錄下的settings.xml:
E:\soft\apache-maven-3.1.0\conf\settings.xml
首先,通過<profile/>新增Repository和pluginRepository
Xml程式碼
1. <settings>
2.
3. ...
4.
5. <profiles>
6. <profile>
7. <id>profile-nexus</id>
8.
9. <repositories>
10. <repository>
11. <id>nexus</id>
12. <url>http://localhost:8081/nexus/content/groups/public/</url>
13. <snapshots><enabled>true</enabled></snapshots>
14. <releases><enabled>true</enabled></releases>
15. </repository>
16. </repositories>
17. <pluginRepositories>
18. <pluginRepository>
19. <id>nexus</id>
20. <url>http://localhost:8081/nexus/content/groups/public/</url>
21. <snapshots><enabled>true</enabled></snapshots>
22. <releases><enabled>true</enabled></releases>
23. </pluginRepository>
24. </pluginRepositories>
25. </profile>
26. </profiles>
27.
28. ...
29.
30. </settings>
然後,使用<activeProfiles>對上面的配置進行啟用(通過配置的id標識進行啟用)
Xml程式碼
1. <activeProfiles>
2. <activeProfile>profile-nexus</activeProfile>
3. </activeProfiles>
現在,本地機器上建立Maven專案,都會使用settings中有關倉庫的配置了
本地倉庫:
<localRepository>E:/repository/maven/repos</localRepository>
本地Maven下載的依賴包和外掛都將放到E:/repository/maven/repos目錄中
私服:
本地所有Maven專案,下載構建都統一從http://localhost:8081/nexus/content/groups/public/ 下載!
【私服上不存在某個構建時,再從遠端下載】
遠端倉庫:
如果遠端倉庫連線不上,則通過nexus修改central的地址即可!
當前使用Maven的預設配置:http://repo1.maven.org/maven2/
Maven 私服 建議大家手動搭建
20. linux 檢視日誌檔案
Linux日誌檔案在/var/log目錄下,可以通過命令檢視日誌檔案。
1,cat messages可以檢視某個日誌檔案。
2,要達到實時更新,可以通過tail命令檢視更新的資料,例如tail -f messages。
3,tail命令引數:
-f 迴圈讀取
-q 不顯示處理資訊
-v 顯示詳細的處理資訊
-c<數目> 顯示的位元組數
-n<行數> 顯示行數
--pid=PID 與-f合用,表示在程序ID,PID死掉之後結束.
-q, --quiet, --silent 從不輸出給出檔名的首部
-s, --sleep-interval=S 與-f合用,表示在每次反覆的間隔休眠S秒。
日誌型別
下面是常見的日誌型別,但並不是所有的Linux發行版都包含這些型別:
型別 |
說明 |
auth |
使用者認證時產生的日誌,如login命令、su命令。 |
authpriv |
與 auth 類似,但是隻能被特定使用者檢視。 |
console |
針對系統控制檯的訊息。 |
cron |
系統定期執行計劃任務時產生的日誌。 |
daemon |
某些守護程序產生的日誌。 |
ftp |
FTP服務。 |
kern |
系統核心訊息。 |
local0.local7 |
由自定義程式使用。 |
lpr |
與印表機活動有關。 |
|
郵件日誌。 |
mark |
產生時間戳。系統每隔一段時間向日志文件中輸出當前時間,每行的格式類似於 May 26 11:17:09 rs2 -- MARK --,可以由此推斷系統發生故障的大概時間。 |
news |
網路新聞傳輸協議(nntp)產生的訊息。 |
ntp |
網路時間協議(ntp)產生的訊息。 |
user |
使用者程序。 |
uucp |
UUCP子系統。 |
日誌優先順序
常見的日誌優先順序請見下標:
優先順序 |
說明 |
emerg |
緊急情況,系統不可用(例如系統崩潰),一般會通知所有使用者。 |
alert |
需要立即修復,例如系統資料庫損壞。 |
crit |
危險情況,例如硬碟錯誤,可能會阻礙程式的部分功能。 |
err |
一般錯誤訊息。 |
warning |
警告。 |
notice |
不是錯誤,但是可能需要處理。 |
info |
通用性訊息,一般用來提供有用資訊。 |
debug |
除錯程式產生的資訊。 |
none |
沒有優先順序,不記錄任何日誌訊息。 |
常用日誌檔案
系統日誌是由一個名為syslog的服務管理的,如以下日誌檔案都是由syslog日誌服務驅動的:
/var/log/boot.log:錄了系統在引導過程中發生的事件,就是Linux系統開機自檢過程顯示的資訊
/var/log/lastlog :記錄最後一次使用者成功登陸的時間、登陸IP等資訊
/var/log/messages :記錄Linux作業系統常見的系統和服務錯誤資訊
/var/log/secure :Linux系統安全日誌,記錄使用者和工作組變壞情況、使用者登陸認證情況
/var/log/btmp :記錄Linux登陸失敗的使用者、時間以及遠端IP地址
/var/log/syslog:只記錄警告資訊,常常是系統出問題的資訊,使用lastlog檢視
/var/log/wtmp:該日誌檔案永久記錄每個使用者登入、登出及系統的啟動、停機的事件,使用last命令檢視
/var/run/utmp:該日誌檔案記錄有關當前登入的每個使用者的資訊。如 who、w、users、finger等就需要訪問這個檔案
/var/log/syslog 或 /var/log/messages 儲存所有的全域性系統活動資料,包括開機資訊。基於 Debian 的系統如 Ubuntu 在 /var/log/syslog 中儲存它們,而基於 RedHat 的系統如 RHEL 或 CentOS 則在 /var/log/messages 中儲存它們。
/var/log/auth.log 或 /var/log/secure 儲存來自可插拔認證模組(PAM)的日誌,包括成功的登入,失敗的登入嘗試和認證方式。Ubuntu 和 Debian 在 /var/log/auth.log 中儲存認證資訊,而 RedHat 和 CentOS 則在 /var/log/secure 中儲存該資訊。
21 redis 優缺點??
一:redis簡介:
1:鍵-值儲存 通常被稱作是一款資料結構伺服器
2:支援的資料型別:字串、雜湊、列表、集合、有序集合等 。對這些資料型別,可以執行原子操作。
3:為了獲得優異的效能,redis採用記憶體中資料集的方式。
4:redis支援資料的持久化,可以每個一段時間將資料轉存到磁碟上,或在日誌尾部追加一條操作命令。
5:redis支援主從複製,並具有非常快速的非阻塞的首次同步、網路斷開自動重連等功能。
6:redis的一些其他功能:簡單的事務支援、釋出訂閱、管道、虛擬記憶體等。
Redis的主要缺點是資料庫容量受到實體記憶體的限制,不能用作海量資料的高效能讀寫,因此Redis適合的場景主要侷限在較小資料量的高效能操作和運算上。
分散式:redis支援主從的模式。
原則:Master會將資料同步到slave,而slave不會將資料同步到master。Slave啟動時會連線master來同步資料。
這是一個典型的分散式讀寫分離模型。我們可以利用master來插入資料,slave提供檢索服務。這樣可以有效減少單個機器的併發訪問數量。
讀寫分離模型
通過增加Slave DB的數量,讀的效能可以線性增長。為了避免Master DB的單點故障,叢集一般都會採用兩臺Master
DB做雙機熱備,所以整個叢集的讀和寫的可用性都非常高。
讀寫分離架構的缺陷在於,不管是Master還是Slave,每個節點都必須儲存完整的資料,如果在資料量很大的情況下,叢集的擴充套件能力還是受限於單個節點的儲存能力,而且對於Write-intensive型別的應用,讀寫分離架構並不適合。
優點:
1. 豐富的資料結構
· String
· list
· set
· hash
· sorted set
2.高速讀寫,redis使用自己實現的分離器,程式碼量很短,沒有使用lock(MySQL),沒有使用CAS(memcached),因此效率非常高。
缺點:
1. 持久化。Redis直接將資料儲存到記憶體中,要將資料儲存到磁碟上,Redis可以使用兩種方式實現持久化過程。定時快照(snapshot):每隔一段時間將整個資料庫寫到磁碟上,每次均是寫全部資料,代價非常高。第二種方式基於語句追加(aof):只追蹤變化的資料,但是追加的log可能過大,同時所有的操作均重新執行一遍,回覆速度慢。
2. 耗記憶體,佔用記憶體過高。
23 mq 流程
1. 建立 連線工廠QueueConnectionFactory
2 提供 連線工廠 建立連線connection
3. 建立一個session 會話
4. 建立一個訊息佇列
5. 建立訊息傳送者
6. 傳送訊息
7. 提交會話
在整個Spring MVC框架中,DispatcherServlet處於核心位置,它負責協調和組織不同元件完成請求處理並返回響應的工作。具體流程為:
1)客戶端傳送http請求,web應用伺服器接收到這個請求,如果匹配DispatcherServlet的對映路徑(在web.xml中配置),web容器將請求轉交給DispatcherServlet處理;
2)DispatcherServlet根據請求的資訊及HandlerMapping的配置找到處理該請求的Controller;
3)Controller完成業務邏輯處理後,返回一個ModelAndView給DispatcherServlet;
4)DispatcherServlet藉由ViewResolver完成ModelAndView中邏輯檢視名到真實檢視物件View的解析工作;
5)DispatcherServlet根據ModelAndView中的資料模型對View物件進行檢視渲染,最終客戶端得到的響應訊息可能是一個普通的html頁面,也可能是一個xml或json串,甚至是一張圖片或一個PDF文件等不同的媒體形式。