1.Struts2框架的執行流程 ?

從客戶端傳送請求過來,先經過前端控制器（核心過濾器）過濾器中,執行一組攔截器（一組攔截器 就會完成部分功能程式碼）執行目標Action,

在Action中返回一個結果檢視,根據Result的配置進行頁面的跳轉.

Struts2和Struts1沒有任何聯絡.Struts2核心是webwork的核心.

2.hibernate框架的理解?

定義:

Hibernate是一個開放原始碼的物件關係對映（ORM）框架，它對JDBC進行了非常輕量級的物件封裝，

使得Java程式設計師可以隨心所欲的使用物件程式設計思維來操縱資料庫.可以通過物件儲存到關係型資料庫中,僅提供sava/get方法即可

Hibernate是一個持久層的ORM框架.

3.Spring框架的理解?

Spring是一個開源框架,核心是控制反轉（IOC程式設計思想）和麵向切面（AOP）。簡單來說，Spring是一個分層的JavaSE/EEfull-stack(一站式) 輕量級開源框架

Spring的AOP的理解:通過預編譯方式和執行期動態代理實現程式功能的統一維護的一種技術,利用AOP可以對業務邏輯的各個部分進行隔離，從而使得業務邏輯各部分之間的耦合度降低，提高程式的可重用性，同時提高了開發的效率.可以在不修改原始碼的前提下，對程式進行增強.

例如:在以前配置事務的時候,進行事務的回滾,提交等操作,配置AOP 以後可以將事務的許可權交給Spring框架去管理,自動管理

4.SpringMVC的理解?

springMvc:是一個表現層框架,就是從請求中接收傳入的引數,

將處理後的結果資料返回給頁面展示

基本型別:string,double,float,integer,long.boolean

5.Mybatis的理解?

MyBatis是一個優秀的持久層框架，它對jdbc的操作資料庫的過程進行封裝，使開發者只需要關注 SQL 本身，而不需要花費精力去處理例如註冊驅動、建立connection、建立statement、手動設定引數、結果集檢索等jdbc繁雜的過程程式碼。

Mybatis通過xml或註解的方式將要執行的各種statement（statement、preparedStatement、CallableStatement）配置起來，並通過java物件和statement中的sql進行對映生成最終執行的sql語句，最後由mybatis框架執行sql並將結果對映成java物件並返回。

#{}可以有效防止sql注入

6.Servlet的理解?

* GET和POST區別?

* GET：請求引數會顯示到位址列.GET方式有大小的限制.GET方式沒有請求體

* POST：請求引數不會顯示到位址列.在請求體中.POST沒有大小限制.POST方式有請求體.

* 只有表單設定為method=”post”才是post請求.其他的都是get請求

生命週期:客戶端第一次訪問該Servlet的時候才會建立一個Servlet的物件,那麼Servlet中的init方法就會執行.任何一次從客戶端傳送的請求,那麼伺服器建立一個新的執行緒執行Servlet中service方法為這次請求服務.

service方法的內部根據請求的方式的不同調用不同doXXX的方法.當Servlet從伺服器中移除或者關閉伺服器的時候Servlet物件就會被銷燬.destroy的方法就會執行.

7.Struts2與SpringMVC的區別?

1)springmvc的入口是一個servlet即前端控制器，而struts2入口是一個filter過慮器。

2)springmvc是基於方法開發(一個url對應一個方法)，請求引數傳遞到方法的形參，可以設計為單例或多例(建議單例)，struts2是基於類開發，傳遞引數是通過類的屬性，只能設計為多例。

3)Struts採用值棧儲存請求和響應的資料，通過OGNL存取資料， springmvc通過引數解析器是將request請求內容解析，並給方法形參賦值，將資料和檢視封裝成ModelAndView物件，最後又將ModelAndView中的模型資料通過reques域傳輸到頁面。Jsp檢視解析器預設使用jstl。

8.Jsp的核心及核心標籤?

a) Servlet

b) Core XML Database Funcations

9.Redis什麼情況下使用，redis持久化方案?

a) 處理大資料量的時候

b) Redis的所有資料都是儲存在記憶體中，

Rdb：快照形式，定期把記憶體中當前時刻的資料儲存到磁碟，redis預設支援的持久化方案

aof形式：append only file。把所有對redis資料庫操作的命令，增刪改操作命令，儲存到檔案中，資料庫恢復是把所有命令執行一遍即可。

10.Hibernate和Mybatis的區別和優劣?

a) Sql優化方面：hibernate的查詢會將表中所有的欄位查詢出來，這一點會有效能的消耗

Mybatis的sql是手動編寫的，所以可以按需求指定查詢的欄位，sql會更靈活，可控性更好

b) Hibernate是在JDBC上進行了一次封裝

Mybatis是基於原生的JDBC，執行速度有優勢

c) Mybatis mapper xml支援動態sql；Hibernate不支援

d) Hibernate與具體資料庫的關聯只需在xml檔案中配置即可，所有hql語句與具體的資料庫無關，移植性好

Mybatis專案所有的sql語句都是依賴所用的資料庫的，所以不同資料庫型別的支援不好

11.StringBuffer、StringBuilder的區別?

StringBuffer、StringBuilder是容器，是可變的字串序列，存放於堆記憶體。

StringBuffer是JDK1.0版本的，執行緒是安全的，效率比較低。StringBuilder是JDK1.5出現的，執行緒不安全，效率高。

12.說一下SOLR?

solr就是一箇中文搜尋引擎,做完分詞之後會做熱度排名,核心是中文分詞器,全文搜尋支援,索引值指向對應的文件,相當於是一個字典,預設為collection的一個域物件,查詢快,效率高.

可以在Redis裡做分詞之後的快取,每次搜尋一次就次數加一,裡面還有一個投票容錯機制,主機掛掉還有備份機,一般配置都為奇數態配置.

13.Solr與Lucene的區別?

Lucene是一個開放原始碼的全文檢索引擎工具包，它不是一個完整的全文檢索引擎，Lucene提供了完整的查詢引擎和索引引擎，目的是為軟體開發人員提供一個簡單易用的工具包，以方便的在目標系統中實現全文檢索的功能，或者以Lucene為基礎構建全文檢索引擎。

Solr的目標是打造一款企業級的搜尋引擎系統，它是一個搜尋引擎服務，可以獨立執行，通過Solr可以非常快速的構建企業的搜尋引擎，通過Solr也可以高效的完成站內搜尋功能。

14.什麼是Redis?

1) Redis的高效能是由於其將所有資料都儲存在了記憶體中，為了使Redis在重啟之後仍能保證資料不丟失，需要將資料從記憶體中同步到硬碟中，這一過程就是持久化。

Redis支援兩種方式的持久化，一種是RDB方式，一種是AOF方式。可以單獨使用其中一種或將二者結合使用。

1.1RDB持久化

RDB方式的持久化是通過快照（snapshotting）完成的，當符合一定條件時Redis會自動將記憶體中的資料進行快照並持久化到硬碟。

每次進行訪問進行儲存,如果伺服器一旦崩潰,會導致資料丟失

RDB是Redis預設採用的持久化方式，在redis.conf配置檔案中預設有此下配置：

save 900 1 , save 300 10, save 60 10000

save 開頭的一行就是持久化配置，可以配置多個條件（每行配置一個條件），每個條件之間是“或”的關係，“save 900 1”表示15分鐘（900秒鐘）內

至少

1個鍵被更改則進行快照，“save 300 10”表示5分鐘（300秒）內至少10個鍵被更改則進行快照。

在redis.conf中：

配置dir指定

rdb快照檔案的位置;配置dbfilenam指定rdb快照檔案的名稱

Redis啟動後會讀取RDB快照檔案，將資料從硬碟載入到記憶體。根據資料量大小與結構和伺服器效能不同，這個時間也不同。

通常將記錄一千萬個字串型別鍵、大小為1GB的快照檔案載入到記憶體中需要花費20～30秒鐘。

問題總結：

通過RDB方式實現持久化，一旦Redis異常退出，就會丟失最後一次快照以後更改的所有資料。這就需要開發者根據具體的應用場合，通過組合設定自動快照條件的方式來將可能發生的資料損失控制在能夠接受的範圍。如果資料很重要以至於無法承受任何損失，則可以考慮使用AOF方式進行持久化。

1.2AOF持久化

預設情況下Redis沒有開啟AOF（append only file）方式的持久化，訪問一段儲存一段,效率高.

可以通過appendonly引數開啟：appendonly yes開啟AOF持久化後每執行一條會更改Redis中的資料的命令，Redis就會將該命令寫入硬碟中的AOF檔案

AOF檔案的儲存位置和RDB檔案的位置相同，都是通過dir引數設定的，預設的檔名是appendonly.aof，可以通過appendfilename引數修改：appendfilename appendonly.aof

2)主從複製（瞭解）

2.1什麼是主從複製

持久化保證了即使redis服務重啟也會丟失資料，因為redis服務重啟後會將硬碟上持久化的資料恢復到記憶體中，但是當redis伺服器的硬碟損壞了可能會導致資料丟失，如果通過redis的主從複製機制就可以避免這種單點故障，如下圖：

說明：

n主redis中的資料有兩個副本（replication）即從redis1和從redis2，即使一臺redis伺服器宕機其它兩臺redis服務也可以繼續提供服務。

n主redis中的資料和從redis上的資料保持實時同步，當主redis寫入資料時通過主從複製機制會複製到兩個從redis服務上。

n只有一個主redis，可以有多個從redis。

n主從複製不會阻塞master，在同步資料時，master 可以繼續處理client 請求

n一個redis可以即是主又是從，如下圖：

2.2主從配置

2.2.1主redis配置

無需特殊配置。

2.2.2從redis配置

修改從redis伺服器上的redis.conf檔案，新增slaveof 主redisip主redis埠

上邊的配置說明當前該從redis伺服器所對應的主redis是192.168.101.3，埠是6379

2.3主從複製過程

2.3.1完整複製

在redis2.8版本之前主從複製過程如下圖：

複製過程說明：

1、slave 服務啟動，slave 會建立和master 的連線，傳送sync 命令。

2、master啟動一個後臺程序將資料庫快照儲存到RDB檔案中

注意：此時如果生成RDB檔案過程中存在寫資料操作會導致RDB檔案和當前主redis資料不一致，所以此時master 主程序會開始收集寫命令並快取起來。

3、master 就傳送RDB檔案給slave

4、slave 將檔案儲存到磁碟上，然後載入到記憶體恢復

5、master把快取的命令轉發給slave

注意：後續master 收到的寫命令都會通過開始建立的連線傳送給slave。

當master 和slave 的連線斷開時slave 可以自動重新建立連線。如果master 同時收到多個slave 發來的同步連線命令，只會啟動一個程序來寫資料庫映象，然後傳送給所有slave。

完整複製的問題：

在redis2.8之前從redis每次同步都會從主redis中複製全部的資料，如果從redis是新建立的從主redis中複製全部的資料這是沒有問題的，但是，如果當從redis停止執行，再啟動時可能只有少部分資料和主redis不同步，此時啟動redis仍然會從主redis複製全部資料，這樣的效能肯定沒有隻複製那一小部分不同步的資料高。

2.3.2部分複製

部分複製說明：

從機連線主機後，會主動發起 PSYNC 命令，從機會提供 master的runid(機器標識，隨機生成的一個串) 和 offset（資料偏移量，如果offset主從不一致則說明資料不同步），主機驗證 runid 和 offset 是否有效， runid 相當於主機身份驗證碼，用來驗證從機上一次連線的主機，如果runid驗證未通過則，則進行全同步，如果驗證通過則說明曾經同步過，根據offset同步部分資料。

2)redis是一個nosql(not only sql不僅僅只有sql)資料庫.翻譯成中文叫做非關係型型資料庫.

關係型資料庫:以二維表形式儲存資料

非關係型資料庫: 以鍵值對形式儲存資料(key, value形式)

Redis是用C語言開發的一個開源的高效能鍵值對（key-value）資料庫。它通過提供多種鍵值資料型別來適應不同場景下的儲存需求，

目前為止Redis支援的鍵值資料型別如下：

字串型別

雜湊型別

列表型別

集合型別

有序集合型別。

3)redis的應用場景

快取（資料查詢、短連線、新聞內容、商品內容等等）。（最多使用）

分散式叢集架構中的session分離。

聊天室的線上好友列表。

任務佇列。（秒殺、搶購、12306等等）

應用排行榜。

網站訪問統計。

資料過期處理（可以精確到毫秒）

redis是將資料存放到記憶體中,由於內容存取速度快所以redis被廣泛應用在網際網路專案中,

redis有點:存取速度快,官方稱讀取速度會達到30萬次每秒,寫速度在10萬次每秒最有,具體限制於硬體.

缺點:對持久化支援不夠良好,

所以redis一般不作為資料的主資料庫儲存,一般配合傳統的關係型資料庫使用.

4) redis應用領域

分散式快取

分散式session

儲存部落格或者論壇的留言回覆等.

總之是用在資料量大,併發量高的情況下

15.談下DUBBO?

Dubbo就是資源排程和治理中心的管理工具。

呼叫關係說明：

0. 服務容器負責啟動，載入，執行服務提供者。

1. 服務提供者在啟動時，向註冊中心註冊自己提供的服務。

2. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。

3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。

4. 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。

5. 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。

16.解決跨域問題?

JSONP-->Script Tags

17.秒殺方案：

1、把商品的數量放到redis中。

2、秒殺時使用decr命令對商品數量減一。如果不是負數說明搶到。

3、一旦返回數值變為0說明商品已售完。

18.ZOOKeeper?

Zookeeper 作為一個分散式的服務框架，主要用來解決分散式叢集中應用系統的一致性問題，它能提供基於類似於檔案系統的目錄節點樹方式的資料儲存，但是 Zookeeper 並不是用來專門儲存資料的，它的作用主要是用來維護和監控你儲存的資料的狀態變化。

通過監控這些資料狀態的變化，從而可以達到基於資料的叢集管理

註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，壓力小。使用dubbo-2.3.3以上版本，建議使用zookeeper註冊中心。

Zookeeper是Apacahe Hadoop的子專案，是一個樹型的目錄服務，支援變更推送，適合作為Dubbo服務的註冊中心，工業強度較高，可用於生產環境，並推薦使用

19.ActiveMQ的訊息形式

一種是點對點的，即一個生產者和一個消費者一一對應；可進行快取,只允許單人登入檢視

另一種是釋出/訂閱模式，即一個生產者產生訊息並進行傳送後，可以由多個消費者進行接收。無法進行快取,支援多人訪問.

JMS定義了五種不同的訊息正文格式，以及呼叫的訊息型別，允許你傳送並接收以一些不同形式的資料，提供現有訊息格式的一些級別的相容性。

StreamMessage -- Java原始值的資料流

MapMessage--一套名稱-值對

TextMessage--一個字串物件

ObjectMessage--一個序列化的 Java物件

BytesMessage--一個位元組的資料流

1.訂單系統

1.1.功能分析

1、在購物車頁面點選“去結算”按鈕跳轉到訂單確認頁面。

a)展示商品列表

b)配送地址列表

c)選擇支付方式

2、展示訂單確認頁面之前，應該確認使用者身份。

a)使用攔截器實現。

b)Cookie中取token

c)取不到token跳轉到登入頁面

d)取到token，根據token查詢使用者資訊。

e)如果沒有使用者資訊，登入過期跳轉到登入頁面

f)取到使用者資訊，放行。

3、提交訂單

a)生成訂單

b)展示訂單提交成功頁面。

訂單系統系統：訂單確認頁面、訂單提交成功頁面。

訂單服務系統

1.1.展示訂單確認頁面

1.1.1.功能分析

1、在購物車頁面點選“去結算”按鈕跳轉到訂單確認頁面。

2、請求的url：

/order/order-cart

3、引數：沒有引數。

4、購物車商品資料從cookie中取出來的。可以在訂單系統中取到cookie中的購物車資料。

5、配送地址列表，需要使用者登入。需要根據使用者id查詢收貨地址列表。靜態資料。

6、支付方式。靜態資料。

7、返回值：邏輯檢視String，展示訂單確認頁面。

1.1.2.Dao層、Service層（沒有）

需要根據使用者id查詢收貨地址列表。沒有此功能。

1.1.3.表現層

請求的url：/order/order-cart

引數：無

業務邏輯：

從cookie中取商品列表展示到頁面。

返回值：邏輯檢視。

1.1.使用者身份認證

在展示訂單確認頁面之前，需要對使用者身份進行認證，要求使用者必須登入。

1.1.1.功能分析

1、使用springmvc的攔截器實現。需要實現一個介面HandlerInterceptor介面。

2、業務邏輯

a)從cookie中取token。

b)沒有token，需要跳轉到登入頁面。

c)有token。呼叫sso系統的服務，根據token查詢使用者資訊。

d)如果查不到使用者資訊。使用者登入已經過期。需要跳轉到登入頁面。

e)查詢到使用者資訊。放行。

3、在springmvc.xml中配置攔截器。

1.1.2.攔截器實現

1.1.1.功能分析

1、在訂單確認頁面點選“提交訂單”按鈕生成訂單。

2、請求的url：/order/create

3、引數：提交的是表單的資料。儲存的資料：訂單、訂單明細、配送地址。

a)向tb_order中插入記錄。

i.訂單號需要手動生成。

要求訂單號不能重複。

訂單號可讀性號。

可以使用redis的incr命令生成訂單號。訂單號需要一個初始值。

ii.Payment：表單資料

iii.payment_type：表單資料

iv.user_id：使用者資訊

v.buyer_nick：使用者名稱

vi.其他欄位null

b)向tb_order_item訂單明細表插入資料。

i.Id：使用incr生成

ii.order_id：生成的訂單號

相關推薦