面試串講5:系統架構及項目設計

一、Cookie操做

　　cookie是否是必須客戶端跳轉完成以後纔會被設置進去？若是我用response.setCookie後有服務器跳轉，在服務器跳轉後我去取這個cookie是否是就取不到啊？在顯示頁顯示不了，可是我刷新一下就能找到cookie了。

　　對於Cookie的設置，有兩種模式：

　　　　WEB服務器自動設置：指的是你第一次訪問裏面的任何一個頁面；

　　　　手工的方式來設置Cookie；

　　大部分開發者都會忽略一個關鍵性的問題，那麼就是Cookie的路徑問題。在默認狀況下假設說你如今在「pages/back/msg」目錄下，你在這個目錄下執行了response.addCookie(c),那麼這個時候的cookie是會存在此目錄下。那麼這個時候即便設置了Cookie,若是你更改了目錄，例如：「/pages/back」下，那麼也沒法取到Cookie,由於路徑不一樣，因此就須要在設置Cookie的時候，若是肯定要保存，除了設置時間以外，也須要設置路徑，路徑就設置爲根目錄「request.getContextPath().」。

　　能夠取到，關鍵看cookie設置的路徑。跳轉也有兩種形式，服務器端跳轉和客戶端跳轉，若是用服務器端跳轉，第一次確定取不到，必須在客戶端刷新一下再次請求，才能夠把cookie刷過來。

二、mvc設計

mvc模式中，各個層級的職能劃分，哪些功能寫在那塊？

　　所謂的mvc設計模式其實是一種思想，雖然從總體上來講是劃分爲了三層，可是實際上裏面會劃分許多的層。

好比有一個業務的完成，要分不少步，咱們是把這些步驟放在服務層仍是Servlet中？

　　服務層是能夠單獨抽取的，也就是說若是你的一個項目要充分的考慮到可擴展性，那麼絕對須要將業務層單獨抽取出來實現RPC調用（WebService）。

　　必定要清楚的是控制層不負責任何與數據庫的操做，是任何的操做都不負責，因此控制層只會存在有一個功能：調用業務層，業務的方法只有一個，若是業務操做要返回多個內容，那麼就使用Map集合返回。

若是放在Servlet中會準確的把各個步驟的錯進行捕獲並處理，但這樣會顯得控制層很重，若是放在服務層的話Servlet又不能明確的對各個步驟失敗進行處理了。

　　控制層必定要處理全部的錯誤操做，若是不處理，你能夠直接選擇一個拋出，然後在整個的web.xml文件裏面配置一個錯誤頁，這個錯誤頁只要是產生了xxx異常，那麼就自動跳轉到一個錯誤頁上顯示。

　　可是我我的的習慣是本身手工來進行處理，由於以上的跳轉屬於全局模式，也就是說無論出現什麼樣的錯誤，都跳轉到一個頁面上進行顯示，這樣的作法會形成錯誤的信息不明確的問題。

各個層使用的技術

　　只有把單機的MVC完全弄清楚以後纔可能牽扯到更多的實際的開發問題，而集羣的開發也只是一種擴展而已。

三、MyEclipse開發項目

 　　MyEclipse如今比較悲催的一點就是它只能開發一些低版本程序了。

　　從MyEclipse2015開始，必須現有WEB項目，然後才能夠創建WEB Server。

　　使用MyEclipse運行項目的時候必定要在網址後面加上項目名稱。

四、SSO處理流程

　　所謂的單點登陸用在什麼場景上？

　　CAS有一個本身的流程。

　　就是CAS服務器的配置，由於版本的區別很大，因此強烈建議你們使用穩定版本開發。同時這裏面還須要針對源代碼

進行大量的修改與配置才能夠得來。

五、讀、寫分離性能

　　數據庫的讀、寫分離。此種考慮須要根據你的實際業務要求，不能憑空設計。

　　在講解Oracle的時候說過這樣一個簡單的架構：

　　　　信息的彙總表，同時爲了保證查詢的性能，須要增長索引，可是這張表平均每1秒要更新1000次，可是這樣就和索引產生了衝突，因此定義兩張表，一張表做爲更新使用，另一張表在系統安靜下來的時候進行差別的備份，然後進行數據的保存。

　　以上是在WEB2.0之前的概念，從WEB2.0開始（AJAX開始）數據量開始暴增，因而你的老闆可能就要求你須要對系統進行大規模升級：要求保證更新速度，要求保證明時性，要求保證數據的有效性。

　　若是這個時候全部的設計仍是圍繞着傳統的關係型數據庫展開，你的設計必定是失敗的。

六、分佈式鎖實現

 　　所謂的分佈式鎖指的是在高併發訪問的狀況下使用的一種技術，所謂的高併發訪問指的就是多個線程對象（每個操做用戶）爲了保證資源的操做完整性而實現的一種技術，這樣的技術能夠簡單的理解爲鎖。

　　若是如今多個線程在同一個虛擬機之中，正常編寫一個程序。然後這個程序裏面產生了若干個線程，而且這些線程要操做統一資源。那麼在這樣的狀況下，爲了保證資源操做的同步最簡單的處理模式就是採用synchronized關鍵字來完成。

　　可是這樣的作法只適合於單JVM運行狀況下，而若是說如今劃分到網絡上。

　　可是若是是多虛擬機的狀態下，這樣的設計就必須作出更改了。

七、負載均衡設計

　　對於項目的開發須要考慮幾個核心問題：高可用（主備關係）、高併發（能夠承受大併發用戶訪問）、分佈式。真正作到這個層次架構的時候，你的系統平均天天的訪問量不可能低於500W-1000W用戶，若是沒有到這個用戶的量級，那麼能夠確定的是用這樣的架構會形成大量的額外硬件成本（雲服務器（雲服務器的出現解決了企業搭建私有云問題））。

　　在正規的項目開發過程之中確定會有專業的前端開發者，這類人員會使用ES6.0標準進行前端開發，例如JQuery、Vue.JS、React等，因此這部分的設計不作考慮。

　　在總體的設計過程之中，就必須去考慮性能的均衡，固然服務器的選擇和你要使用的技術的選擇也須要根據實際狀況肯定。要根據你併發訪問人數來決定你的技術架構。

八、複雜度

 　   評價一個項目的好與壞，有一個最簡單的標準：時間複雜度和空間複雜度。

　　時間複雜度指的是你的處理邏輯很是的複雜，例如：遞歸、循環結構複雜，複雜度直接的影響就是你的CPU的佔用率高。

　　空間複雜度：你佔用的內存大，例如：在進行JDBC進行數據查詢的時候實際上會出現一個問題：若是假設你的數據庫有1000w條數據，沒有使用分頁，那麼這些記錄都將加載到內存之中。因此你的內存佔用率就會很高，假設這些數據會佔用20G的內存，那你的一個服務器必定須要爲上萬人服務，那麼這個時候所佔用的內存就會很是的龐大，你的服務器根本就沒法處理。

　　對於空間複雜度的操做處理，是須要經過最簡單的分頁算法能夠實現約定，而對於時間複雜度，若是太複雜的邏輯運算，每每不會在一臺服務器上運行，須要設計多臺的開發服務器。（不是如今能夠理解的，只是3~4年工做經驗）

　　最好的效果：處理塊，佔用內存小，你的程序必定要寫到位。

九、紅綠燈系統設計

　　若是你的面試公司給了你這樣的一個問題，那麼考慮的只是一個邏輯分析能力。由於這種開發的操做從現實來看都是經過硬件模擬的，那麼若是非要經過軟件模擬，就須要準備好可能使用到的技術：

　　　　java編寫：Graphics類進行繪製開發：

　　　　WEB編寫：HTML5中提供的Canvas進行編寫

　　面對此類的問題必定要有一個假設前提：

　　　　是否須要有黃燈緩衝，緩衝的變動時間？

　　　　是否須要智能調整，若是發現車流量較大，則適當延遲經過時間；

　　　　對於違規的車輛的監控狀況。

　　　　還可能考慮轉向燈的設計

　　實現整個操做的技術環節：

　　　　定時器：Timer、TimerTask,可是這兩個類是須要時鐘支持，但是不許，若是要準確則須要QuartZ這個組件

　　　　描述全部的燈的變化，必定要有一個線程的同步處理機制、synchronized、使用單例實現；

　　　　既然有兩組燈，就建議設計一個單獨紅綠燈類，這個類可使用一些參數變化完成，例如：

　　　　　　|-控制變量 =0：表示紅燈；

　　　　　　|-控制變量 =1：表示綠燈；

　　　　　　|-控制變量 =2：表示轉向燈；

　　　　　　|-控制變量 =3：表示黃燈（綠燈變爲轉向）；

　　　　　　|-控制變量 =4：表示黃燈（轉向變爲紅燈）；

　　　　若是你如今只是但願給出一組狀態，實際上就能夠設置一個如下幾位：

　　　　　　111，能夠描述七個值。

　　若是要編寫還須要考慮傳感器問題：包括監控傳感器、流量傳感器。

　　既然已經有了各類傳感器，那麼就能夠再設置幾個傳感器：車速傳感器，能夠進行大數據的彙總，計算平均的車速，好爲城市的交通規劃做出數據的貢獻。

開發流程：

　　一、須要先實現定時進行燈的切換處理，若是你須要程序編寫，若是使用無界面編寫，這個輸出的信息很是麻煩；

　　二、須要考慮監控的問題，若是隻是在軟件上模擬，能夠設置幾個座標點，而真實的環境須要有傳感器

　　三、考慮數據分析問題，能夠對相應數據進行採集與彙總。

十、開發團隊組成

一、項目中的人員安排

　　任何一個技術型的公司裏面均可能有若干個開發團隊，每一個團隊的開發人數基本上就在3~6我的之間，這樣基本上每一個團隊都有一個架構師（寫代碼），並且每個團隊對應的是一個具體的業務。在團隊裏面3個開發，以及一個美工，這些是正規的開發團隊的組成，可是全部的團隊之上都會有項目經理存在。

　　也有一部分的公司所有請的都是架構師，這些架構師本身直接實現代碼，這一類的人羣技術的要求是比較高的，可是在整個的項目公司裏面還會有一些輔助人員：系統測試（多個組有兩個，每一個組有一個），支撐的人員（打雜），這個就屬於項目的維護人員。

　　因此若是你要想從事軟件行業，那麼最好的作法是不去作這些輔助的工做，而直接上手開發，這樣對於你往後的發展是很是有幫助的，從最初的強調全棧工程師，到如今強調的是開發+運維，那麼之後全員架構時代，也就是說全部的開發人員必定都是能獨擋一面的高手，這類人的工資雖然高，可是整個企業運行來說，這樣的成本是最低的。

　　在之後的開發之路，懂架構有將來，兩年以後，這就是技術人員的基礎要求了。

十一、密碼加密處理（密碼加鹽）

所謂的加密每每通常都會存在有一種解密程序。毒蛇出入七步以內必有解藥。

最簡單的加密，

　　你的原始密碼：abc；　　加密：cba;

那麼說若是全部人都知道有這樣的密碼結構，那麼就能夠很輕鬆的破解，但是若是你在裏面追加一些內容；

　　你的原始密碼：abc;　　鹽值：_;　　新密碼：c_b_a_;

　　若是按照原始規則，那麼如今就沒法獲得正確的原始密碼。

　　也就是說鹽值是讓整個的密碼看起來更加安全

　　MD5的結構特徵是不可逆，可是使用時間長了有些人就開始找到了一些規律，那麼爲了避免讓這些人破解個人密碼，那麼就在生成密碼的時候增長一些額外的內容，這樣的內容就是鹽值，這樣就能夠避免這些人來破壞，不一樣的項目使用不一樣的鹽值來進行處理。

　　Shiro裏面鹽值：password+（{Base64的加密程序}），密碼才保存的更加安全。

十二、商品秒殺設計方案

　　若是要進行商品秒殺的操做必定要有一個前提：預估數據量。

　　　　小米進行搶購的時候都須要針對數據量進行預估：全部的人須要報名參加搶購；

　　　　京東或淘寶的時候發現缺乏報名，它們是依靠大數據分析系統得來的預估數據量；

　　若是沒有預估數據量，那麼整個的系統的先期準備就會不足。如今假設若是要進行秒殺操做

　　　　用戶進行秒殺的登記；

　　　　時間一到開始進行秒殺操做；

　　　　在秒殺的過程之中須要出現一個等待界面，若是此類界面刷新了，則搶購失敗；

1三、日誌輸出

　　在通常的系統開發裏面，對於一些調試的數據都不多去使用System.out進行輸出，幾乎都會配置Log4j開發包，這個開發並不複雜，你只須要配置上開發包，然後使用Logger類就可使用了。

　　裏面分爲幾種級別：info()、error()、warning().若是出現了異常必定使用的是error()。

　　之因此使用log4j輸出，主要是方便進行一些調整。日誌是咱們解決問題的關鍵，也就是說全部的日誌都應該輸出到一個指定的目錄之中，可是這樣的配置都是固定的，不須要作特別的處理。

　　須要的就是配置log4j、slf4j這樣的開發包就可使用日誌輸出了。

1四、企業項目部署

　　實際的環境的架構設計，必需要充分的考慮到你的業務需求以及所謂的高峯訪問的狀況，假如說你有一個系統一年就10我的訪問，那麼就不須要去搞架構了。

　　通常若是要進行架構設計，必須考慮一下幾點：

　　　　該架構可否動態擴容；

　　　　該架構可否支持HA機制；

　　以上的集羣設計是爲了考慮性能平衡，可是會有一個問題存在：沒有考慮到HA機制，若是考慮到高可用機制還須要追加更多的協助主機，這些主機將做爲備選使用。（若是說企業架構的話，這樣的一套集羣涵蓋了大部分的企業互聯網開發的企業操做狀況，作到了必定程度須要深度學習）

1五、實際項目開發場景

 　　項目的開發之中有多少個數據庫？

　　在實際的項目開發過程之中，只有一點是肯定的，那麼就是Tomcat裏面是沒有數據庫的。

　　若是要進行實際的項目開發，每每須要要有許多的子系統，因此如今的開發領域上常常出現一個概念：微架構。其中這種微架構的設計使用兩種開發技術：Dubbo、SpringCloud.

　　若是要是將項目進行子系統的規劃設計，全部的子系統裏面包含的就是全部的業務層接口以及數據層的接口。

　　若是你是作的一些基礎開發，那麼對於整個的開發技術而言，你只須要一個數據庫實現數據便可，固然這裏面還須要考慮庫表分離的問題，全部的數據庫不可能無限制的讓數據增加。

1六、數據庫優化

　　數據庫自己是存儲結構數據的，因此所謂的數據庫優化都是指的是傳統的關係型數據庫操做。那麼對於數據庫的優化有如下的幾個使用原則：

　　你須要有一個很是專業的DBA,能夠根據你的服務器的配置調整你的服務器的配置調整你的數據庫的運行環境；

　　數據庫須要選擇合適的操做系統才能夠返回優點，例如：DB2只能在AIX下運行；

　　請保證你的查詢語句不會寫的特別荒唐（例如：你大量的採用了多表查詢，而且在高併發的狀況下依然採用一樣的方式進行）；

　　能夠將部分的數據靜態化到緩存之中，例如：城市、省份的信息、學校、住宅樓的信息基本不會發生變化；

　　若是以上的要求都作到了，數據庫的操做依然很慢，那麼就有多是數據量太大的緣由了，那麼此時你再怎麼進行優化，你的數據庫的操做也不可能獲得質的提高，那麼這個時候就必須作先期的項目預估，這個預估的時候就須要考慮進行進行庫表分離的有效設計：

　　　　數據庫的分片保存（數據備份問題，一主多從的備份）；

　　　　數據的讀寫分離（你可使用多個數據庫同時完成數據的讀取的負載均衡）；

　　若是從程序自己的角度來說，每個用戶的請求必定要及時的關閉好數據庫的鏈接，不要打開過多的無效連接及在你的項目之中應該配置上數據源。

1七、系統設計

 　　我本身的我的理解：

　　　　一、你須要清楚你所進行開發項目的行業背景；

　　　　　　|-若是在進行一個系統的設計之初進行了大量的分析與設計，結果最終作完成品設計與你的初期設計有很大的差異。那麼就建議不要作特別具體的規劃，可讓甲方派人駐紮，這樣能夠隨時進行業務溝通，隨時進行設計；

　　　　二、在整個系統的設計之中，若是確實有必要會考慮將一些數據進行冗餘處理；（不決定，根據系統決定）

　　　　三、在系統設計之中你必須進行併發訪問的預估，非高峯時期的訪問量、高峯時期的訪問量；

　　　　四、你的系統須要使用那些額外的第三方接口才能夠更好的完成功能，例如：支付寶；

　　　　五、你還須要考慮你項目的子系統設計問題，由於必需要考慮某一個系統的損壞，不會影響其餘的系統；

　　　　　　|-若是要考慮到子系統的問題，那麼就絕對不可能只使用一個服務器開發了，你每每須要的是一個服務器的集羣，同時建議子系統的設計採用Restful架構完成；

　　　　六、還須要考慮與其餘平臺的交互問題；

　　　　七、考慮數據的安全問題；

 

　　實際上如今對於開發人員有些尷尬：咱們開發人員如今的定位好像不這麼清楚，在許多非專業的人士看來，只要跟電腦有關的一切都應該交給開發技術人員完成。若是真的在工做之中進行架構的設計，每每應該有一些專業的搞服務器運維的人士來進行。

　　這些內容與你學習的開發代碼只有一張紙的距離。（可是這層膜要一兩年的經驗才能破）

1八、系統重構

　　系統重構這一個概念實際上會發現常常出如今咱們的開發環境中，我第一次聽到系統重構的概念是在2004年的時候聽到的，當時我我的的第一反應：爲何要重構？

　　對於如今的技術給出的網上資料其實特別的多，可是在當初的時代可以得到技術的來源只有圖書，因此咱們都會翻閱圖書進行查看，可是對於當時只有一些純粹的理論概念上零散的講了點所謂的重構知識。

【我的意見】我僅僅是以我我的意見進行說明：

　　系統重構前提：

　　　　|-你如今的系統已經沒法知足用戶的使用要求，也就是說在白天的時候該系統因爲辦公的人數較多，訪問量也高，因此係統的負荷很大；

　　　　|-你如今業務的流程出現了改變。

　　重構的模式：

　　　　|-業務的從新梳理，也就是說你須要根據如今已有的業務實現進行升級的邏輯改造，這一改造就會牽扯到數據庫的設計變動，同時這個變動還須要保留好原始的操做數據

　　　　|-將一個服務器上運行的項目，拆分到多個服務器上運行，這樣能夠有效的實現負載均衡；

　　　　|-須要將你的業務以子系統的形式出現，也就是說一個綜合的系統之中須要拆分出無數個子系統進行共同的支撐，同時還須要準備出若干種RPC方案技術（Dubbo、Rest-微架構）；

　　　　|-數據的備份存儲問題，由於訪問量大就有可能不是一臺數據庫能夠支撐的；

　　　　|-你可能還須要準備出多個WEB端，那麼這些WEB端的數據的共享，那麼就須要準備出Redis(Redis-Cluster),這些WEB端須要同時被nginx或apache作反向代理。

 

【企業內部】這樣重構的好處：

　　　　全部的業務子系統獨立出去以後能夠進行各類系統間的整合處理（各個子系統之間不要互相調用）;

　　　　適合高併發操做訪問，至少保證速度不會慢；

　　　　數據的操做都基於Redis緩存處理；

　　缺點；服務器的成本加大，由於若是要作高可用的配置的話，基本上還須要增長至少10臺服務器的成本。

　　軟件設計沒有「1+1=2」這樣的公式，咱們惟一能夠作到的事情就是根據具體的業務進行分析。出發點：高可用，高併發，分佈式。

1九、項目闡述

一、項目實際上在咱們看來沒有大小之分。有的只是你的業務邏輯是否清楚。

　  在你進行項目設計的時候應該更清楚這個項目的設計的業務，能夠對某一個項目進行一些一些頭腦風暴擴充；

　  你隨意百度一個相似的項目信息或者是能夠運行的項目代碼，使用一次。

二、項目的解釋必須有一個原則：你的項目的使用環境、預估的訪問人數、併發量；

三、項目的開發技術，若是是單節點的開發技術，只須要傳統的技術名詞：jquery，Struts，hibernate,spring，shiro

四、若是你的項目設計的架構比較複雜，使用的服務節點比較多，這個時候你就須要清楚這些服務節點的做用，以及這些服務節點的安全處理你是如何進行的、節點間的數據互相同步處理；

五、描述這個項目之中具有多少個模塊，完成的週期（比喻作一個cms新聞管理系統，兩天就能夠完成的工做用一個月）項目最快比喻（美工（一週）、測試（2~3天）、開發開發（大約3周，按照一天能夠開發3~5(新手2~4)個模塊來進行推算，並且一個項目團隊的人數不會超過十我的，若是項目是通常的，基本上就能夠考慮五、6我的，美工公用的））

六、你作了哪些項目，這些項目裏面的具體的業務是什麼。

20、項目開發與部署

　　若是要進行項目的開發必定會有一個源代碼程序，可是這個源代碼程序若是要想執行，確定要求將其部署到WEB容器之中，對於WEB容器可使用Tomcat。

2一、項目開發流程

　　實際上對於項目的開發流程與你的正常作飯吃飯是相同的。

　　　　肯定你要作的是什麼飯，例如：你今天打算吃個火鍋？或者吃個炒菜？吃個方便麪？

　　　　須要爲飯菜作一些準備，例如：購買食材、購買調料；

　　　　開始進行作飯的手勢，例如：洗菜、摘菜、準備各類調料：蔥薑蒜；

　　　　開始炒制，開始作飯；

　　　　開始吃；

　　　　開始收尾；

　　實際上項目的流程和它沒有什麼區別？

　　　　【10%】如今假設你是甲方老闆，你須要開發某一款軟件，進行某些業務功能的彌補，那麼對於此時的乙方至關於得到了你的需求，然後能夠針對於你的需求進行分析；將全部可能碰見的功能進行列表以及與甲方進行卻，隨後肯定這個項目能夠，這個醒目作的時候出一些項目的執行方案（不少人會拿着你的方案本身去作了，若是你之後真的開公司進行項目開發，那麼必定要跟甲方要錢，不給錢說明不給你作，不要給本身的方案給它）。

　　　　前期需求的時候必定要給出一些設計界面；

　　　　【30%】進行項目的先期規劃設計，須要設計出數據庫、設計出項目的架構、以及預估項目的訪問量，同時須要考慮擴容性問題（你必須對要進行開發的行業很清楚，纔可以作出來）；

　　　　【50%】進行項目的編寫開發，而在進行編寫開發的過程之中，也會牽扯到一些問題：甲方的需求有可能變動，因此你的項目的結構設計必須知足於變動的需求，那麼就須要對項目重構，最好使用Maven進行重構處理；

　　　　進行項目的內部測試，然後進行bug記錄；

　　　　【10%】進行項目的上線以及項目的維護；（新人通常都作維護）

我的需求分析的實現方式：（需求分析沒有固定的方法，什麼的【10%】表明預付款，最後國內通常要不到）

　　明確的寫出項目的業務流程，例如：該業務涉及到多少張數據表每張表的數據有什麼做用？

　　明確的給出項目規劃圖（前端開發人員提供）；

2二、項目設計案例

一、通常的，用戶表，課程表，報名數據表的設計是第二範式，須要創建用戶數據庫，而後經過userid跟課程id來決定報名一個學生的報名狀況，然而當前狀況是用戶帳號密碼是調用webservice接口獲取的，並且用戶有可能會被註銷，但願老師提供解決思路

二、每個課程是有名額限制的，假如想讓讀者看到實時剩餘名額，在線搶課的人可能比較多，應如何避免數據不一致的情形發生。

　　若是要想實現這樣的架構設計，而且考慮併發訪問的話，那麼就須要更多的去解決你的吞吐量問題，如今作一個假設，參與秒殺的人數爲5W。

　　高併發的狀況下，不要過多的考慮數據庫的設計範式，只須要按照總體的單表處理，全部的操做要經過業務層實現關聯處理。

2三、延遲加載問題

　　對於這種延遲加載問題，實際上屬於spring+Hibernati時代的產物，這個也是Hibernate比較雞肋的功能。之因此說它雞肋主要是由於有以下問題：

　　一、幾乎全部的配置都須要打開延遲加載，不然整個的程序性能會受到嚴重的影響；

　　二、有可能會產生嚴重的「1+N」查詢，例如：如今一個分類下有多個新聞信息，那麼如今很明顯，若是此時沒有打開延遲加載，就意味着若是你如今有10個分類的數據，那麼就會自動查詢10次的字表數據，那麼若是每一個字表的字段包含有3000篇新聞，那麼最終的結果就是30000w條數據，並且這些數據你不是直接去使用。

　　三、當spring與Hibernate結合的時候就會出現有一個頁面數據的延遲打開問題，也就是說你可能但願你的Session一直到頁面後才進行關閉。

　　將Hibernate中的Session延遲到頁面後進行關閉，那麼對於整個的事務處理是很是麻煩的，並且這種操做還須要進行一個OpenSessionInView過濾器的配置。

　　正是由於這樣的狀況，在實際的開發過程之中，針對於須要進行顯示的數據，例如：你如今在查詢一個僱員的時候，但願取得僱員對應的部門數據，並且很肯定這個僱員只對應有一個部門的信息，那麼就建議在業務層裏面，取得完僱員信息以後，直接再使用getter方法查詢該僱員對應的部門的數據信息。

　　在業務層的控制是由於全部的AOP切入點都是在業務層上完成的。隨後到了整個頁面之中就能夠直接在JSP頁面裏面利用emp對象「${emp.dept.dname}」。

　　對於程序的性能，基本上都出如今數據庫上，而若是說用戶不少，問題也會出如今數據庫上，而咱們在開發的時候爲了保證數據庫的操做性能，最好的作法就是：保證你只是查詢到你所須要的數據，不須要的數據絕對不要去查，由於查詢會浪費磁盤的性能，而查詢的結果會佔用內存，而CPU是經過內存讀取數據的，因此若是數據量一大，或者控制不合理，那麼直接致使系統變慢。

2四、用戶認證流程（Oauth設計）

　　若是你如今有多個系統須要統一的集成處理，那麼就須要有一套統一的空間進行認證數據的保存，可是僅僅是保存認證數據而已。

　　通常在進行oauth（讀:歐奧斯）處理的時候每每會使用spache、oltu組件來完成總體的開發操做。

2五、站點訪問統計計量架構設計

　　若是說你如今想作一個全網絡的站點訪問統計，會包含一些核心的數據：用戶從哪裏來、訪問的地址（UV、PV），訪問的次數等，那麼對於這樣的設計確定須要一套分佈式的處理架構。

　　如今假設對於全部的中國站點的訪問量的設計裏面每秒的傳輸的數據有1000w條，對於1000w條的訪問量，那麼確定不可以使用傳統的關係型數據庫處理了（傳統的關係型數據庫提供有事物的支持能力，一旦牽扯到了事務問題，那麼就直接帶來性能下降），因此在這種狀況下確定要使用No-SQL數據庫，既然要進行大併發訪問，確定使用就是Redis數據庫。並且既然每秒有1000w條