在廣州作了四年開發，大大小小參與過五個項目的開發，一個是某公司內部的人員管理系統，一個是物流項目，最近作的是一個電商項目。javascript
前兩個項目採用的是ssh框架搭建的，最近的項目採用的是ssm框架搭建的。在實際開發中，我以爲這兩個框架，他們最大的區別在於hibernate與mybatis的區別。java
Hibernate與mybatis相比較，mybatis更爲輕便、靈活，容易掌握。mybatis能夠把sql語句從Java代碼中分離了出來，放在了配置文件中書寫，大大下降了java代碼與SQL語句的耦合度，更容易對sql語句操做，重要的是mybatis還能夠書寫動態的sql語句，但mybatis也存在一些缺陷，好比mybatis自己的緩存機制沒有hibernate那麼完善，hibernate除了自己有良好的緩存機制，還可使用第三方緩存。Hibernate較完整的封裝了JDBC，但學起來要比mybatis更困難一些。Hibernate的DAO層開發比MyBatis簡單，對對象的維護和緩存要比MyBatis好。mysql
（springmvc與Struts的區別：springmvc是方法級別的攔截，一個方法對應一個request上下文，而方法同時又跟一個url對應,參數的傳遞是直接注入到方法中的，是該方法獨有的。
struts2是類級別的攔截， 一個類對應一個request上下文， struts是在接受參數的時候，能夠用屬性來接受參數， 這就說明參數是讓多個方法共享的,這也就沒法用註解或其餘方式標識其所屬方法了）。nginx
該商城是一個綜合性的B2C平臺，主要針對女性消費者，主要銷售女性化妝品，首飾，服裝等女性用品。商家入駐商城銷售自家的產品，而且能夠獲得商城提供的各類服務。面試
在整個項目中，咱們採用的是nginx+tomcat來部署的（面試官會可能問nginx是誰來部署的？如何部署的？Nginx的執行流程，優勢），nginx一方面作加載靜態資源的服務器，另外一方面來作反向代理和負載均衡。由於該項目須要在多個環境中運行，咱們利用了nginx的反向代理解決了不一樣環境同系統訪問地址不統一帶來的問題。ajax
由於整個項目實現的功能較多， 因此採用分佈式的架構設計，整個項目包括後臺管理系統、前臺系統、訂單系統、登陸系統、搜索系統、購物車系統等，這樣作的好處是使每一個功能模塊獨立出來，下降了各系統之間的耦合度，增刪一個功能不會影響其餘功能模塊。redis
由於項目是採用分佈式架構設計的，各模塊之間是相互獨立的，而各模塊的訪問路徑又是不一樣的，因此當跨域請求數據的時候會遇到跨域受限的問題。好比當用戶首次訪問該網站首頁時，首頁頁面會異步請求後臺管理系統加載商品的類目，這是就會出現跨域受限的問題，之前開發時，若是在本模塊內，咱們是經過ajax異步請求數據的，但Ajax不支持跨域，因此用ajax沒法解決跨域請求數據的問題。最後咱們使用的是jsonp來解決這個問題的。jsonp經過script標籤的src能夠跨域請求的特性，加載資源，將加載的資源（經過一個方法名將數據進行包裹）當作是js腳本解析，定義一個回調函數（是怎麼實現的？），獲取傳入的數據。咱們使用jsonp是由於Jsonp的兼容性比較好，而且在請求完畢後能夠經過callback的方式回傳結果。但jsonp有一個缺點是隻支持get請求而不支持post等其餘類型的http請求。spring
這樣咱們解決了瀏覽器訪問當前頁面去加載後臺系統數據出現的跨域問題，可是另外一個問題又來了，其餘系統該如何獲得調用後臺系統的數據吶？咱們想能夠發送http請求來訪問後臺數據，咱們想到的是使用httpclient來解決此問題，由於httpclient可使用java代碼模擬瀏覽器發送http請求（get方法如何傳遞參數？定義uribuilder對象，在uribuilder裏設置參數，以key和value，都是string類型的，而後將uribuilder放到uri中，在後將uri講給httpget請求。Post方法若是傳輸數據？模擬表單提交，將數據封裝到list集合中，而後將集合數據放入構造的表單實體中，在將表單實體請求放到httppost對象中）。向外拋出一個接口，執行過程是：一、建立httpclient 對象二、構建請求對象post ,get請求三、若是有參數，就去構造請求參數 sql
3.1 get數據庫
使用uribuilder去構造請求參數
3.2 post
構建表單實體，把表單實體放入到 post請求對象中。
四、執行請求 ，而且接受響應
五、處理響應結果
6. 釋放鏈接。不管執行方法是否成功，都必須釋放鏈接。
HttpClient實現認爲是線程安全的。
每次鏈接發起Http請求的時候都會從新創建鏈接(經歷3次握手)，用完就會關閉鏈接(4次揮手)，這樣會消耗不少時間，全部咱們採用了鏈接池。若是不採用鏈接池，每次鏈接都會打開一個端口，在大併發的狀況下系統的端口資源很快就會被用完，致使沒法創建新的鏈接。
像項目中首頁的大廣告和商品類目這些不須要常常修改的數據，若是用戶每次刷新頁面的時候都要去數據庫中查詢，這樣會浪費資源和增長數據庫的壓力。因此咱們想當把這些數據添加到一個緩衝中，用戶去訪問的時候，先去緩存中命中，若是命中失敗，再去數據庫中查詢，而後把查詢到的數據添加到緩存中。目前比較主流的緩存技術有Redis和Memcached，單純從緩存命中的角度來講，Memcached要高一些，可redis和Memcache的差距其實並不大，但Redis提供的功能更增強大一些，讀寫速度也很快。因此咱們選用了redis來緩存數據。Redis把數據以key—value的形式緩存到內存中，並提供了多種數據存儲類型（string，set，list，hash等），還自身提供了持久化功能（2種），還能夠把數據備份到磁盤中（Redis的SAVE命令用於建立當前 Redis 數據庫的備份），防止redis宕機時的數據丟失。（會週期性的把更新的數據寫入磁盤或者把修改操做寫入追加的記錄文件，而且在此基礎上實現了master-slave(主從)同步）。咱們使用的是spring與jedis整合的客戶端，能夠利用jedis作分片式集羣，解決了redis內存受限的問題。
以前實現的登陸和註冊是在同一個tomcat內部完成，而如今系統架構是每個系統都是由一個團隊進行維護，每一個系統都是單獨部署運行一個單獨的tomcat，因此，不能將用戶的登陸信息保存到session中（多個tomcat的session是不能共享的）（session共享？），因此咱們須要一個單獨的系統來維護用戶的登陸信息。咱們是這樣作的，用戶去登陸頁面登陸，去數據庫查詢是否有該用戶，若是沒有提示用戶，若是有就把用戶信息保存到redis中，並生成一個token保存到cookie中，
在後臺管理系統中採用了Maven的多模塊化的管理，其中採用了水平切分的方式（垂直與水平劃分的區別：垂直：功能模塊明確，層次不夠清晰，代碼重用性差。水平：層次清晰，代碼重用性高，獨立維護。），將各層分層開發，這樣作的好處是代碼重用性高，層次清晰，易於獨立維護。系統內部接口調用採用Httpclient，接口提供端採用RESTful方式的接口定義（一種軟件架構風格，設計風格而不是標準，只是提供了一組設計原則和約束條件），系統之間的通知機制採用MQ的方式，使用RabbitMQ的實現，使用了RabbitMQ的消息訂閱模式的消息機制；部署方面，採用了Nginx+tomcat的模式，其中nginx的做用一方面是作反向代理、負載均衡、另外一方面是作圖片等靜態資源的服務器；
在此項目中我主要負責後臺管理模塊，主要實現商品管理和商品規格參數管理，對商品和商品規格進行CRUD操做。；在實現前臺調用後臺數據時，爲了實現系統間的調用，便使用了httpclient技術來實現此功能，在後臺提供了須要調用的接口。（httpclient介紹，工做原理，優缺點）。若是在後臺對商品進行操做，爲了使前臺數據與後臺數據實現同步，咱們使用了RabbitMQ 消息隊列機制實現商品同步功能（RabbitMQ介紹，工做原理，優缺點）；
在此項目中，我還參與了購物車模塊的開發。在開發這個模塊時候，咱們考慮了會員在未登陸和登陸兩種狀況下把商品加入購物車，後臺如何該保存商品信息。
在用戶商品詳情頁點擊加入購物車的時候，咱們用了登陸攔截器來判斷用戶是否登陸；
若是沒有登陸，將商品信息保存到cookie中，當用戶登陸後，再把商品持久到數據庫中；可是考慮到cookie儲存大小的問題，還有當cookie儲存的數據越多就會影響響應速度，咱們決定使用redis來緩存用戶在未登陸狀態下的商品信息（redis介紹，原理，優缺點），在redis中設置緩存生存時間（如何作到的？），若是用戶在規定時間內沒有登陸，數據便會自動刪除。若是用戶在規定時間內登陸了，便會經過RabbitMQ消息隊列機制將數據同步到數據庫中；