面試有兩點：1、技術過硬。2、能說會道。
如果自己的技術還過的去，但是表述的不盡人意，其實是吃了很大虧的，下面我來介紹一個大神的面試過程：
面試官：請介紹一下你的電商項目。
大神：該商城是一個綜合性的B2C電商平台，類似於京東商城，主要針對廣大消費者。
在整個項目中，我們采用的是nginx+tomcat來部署的（面試官可能會問nginx是誰來部署的？如何部署的？nginx的執行流程、優點），nginx一方面做加載靜態資源的服務器，另一方面來做反向代理和負載均衡。因為該項目需要在多個環境中運行，我們利用了nginx的反向代理解決了不同環境同系統訪問地址不統一帶來的問題。
因為整個項目實現的功能較多，所以采用分布式的架構設計，整個項目包括后台管理系統、商城首頁系統、搜索系統、商品詳情頁系統、登錄系統、購物車系統、訂單系統等，這樣做的好處是使每個功能模塊獨立出來，降低了各系統之間的耦合度，增刪一個功能不會影響其他功能模塊。
如何解決了瀏覽器訪問當前頁面去加載后台系統數據出現的跨域問題
答：因為項目是采用分布式架構設計的，各模塊之間是相互獨立的，而各模塊的訪問路徑又是不同的，所以當跨域請求數據的時候會遇到跨域受限的問題。比如當用戶首次訪問該網站首頁時，首頁頁面會異步請求后台管理系統加載商品的類目，這是就會出現跨域受限的問題，以前開發時，如果在本模塊內，我們是通過ajax異步請求數據的，但ajax不支持跨域，所以用ajax無法解決跨域請求數據的問題。
最后我們使用的是jsonp來解決這個問題的。jsonp通過script標簽的src可以跨域請求的特性，加載資源，將加載的資源（通過一個方法名將數據進行包裹）當做是js腳本解析，定義一個回調函數（是怎么實現的？），獲取傳入的數據。我們使用jsonp是因為jsonp的兼容性比較好，並且在請求完畢后可以通過callback的方式回傳結果。但jsonp有一個缺點是只支持get請求而不支持post等其他類型的http請求。
其他系統該如何調用后台系統的數據？
答：我們可以發送http請求來訪問后台數據，我們想到的是使用HttpClient(Dubbo)來解決此問題，因為HttpClient可以使用java代碼模擬瀏覽器發送Http請求。
向外拋出一個接口，執行過程是：
1、創建HttpClient對象；
2、構建請求對象post、get請求；
3、如果有參數，就去構造請求參數，get使用URIBuilder去構造請求參數，post構建表單實體，把表單實體放入到post請求對象中。
4、執行請求，並且接受響應；
5、處理響應結果；
6、釋放連接。無論執行方法是否成功，都必須釋放連接。
為什么HttpClient實現認為是線程安全的？
每次連接發起Http請求的時候都會重新建立連接(經歷3次握手)，用完就會關閉連接(4次揮手)，這樣會消耗很多時間，所有我們采用了連接池。如果不采用連接池，每次連接都會打開一個端口，在大並發的情況下系統的端口資源很快就會被用完，導致無法建立新的連接。
get方法如何傳遞參數？
答：定義URIBuilder對象，在URIBuilder里設置參數，以key和value，都是string類型的，然后將URIBuilder放到URI中，然后將URI傳給Httpget請求。
Post方法如果傳輸數據？
答：模擬表單提交，將數據封裝到list集合中，然后將集合數據放入構造的表單實體中，在將表單實體請求放到httppost對象中。
問題背景：
像項目中首頁的大廣告和商品類目這些不需要經常修改的數據，如果用戶每次刷新頁面的時候都要去數據庫中查詢，這樣會浪費資源和增加數據庫的壓力。
解決思路：
所以我們想當把這些數據添加到一個緩存中，用戶去訪問的時候，先去緩存中命中，如果命中失敗，再去數據庫中查詢，然后把查詢到的數據添加到緩存中。
具體方案：
目前比較主流的緩存技術有Redis和Memcached，單純從緩存命中的角度來說，Memcached要高一些，可Redis和Memcache的差距其實並不大，但Redis提供的功能更加強大一些，讀寫速度也很快。所以我們選用了Redis來緩存數據。
redis把數據以key—value的形式緩存到內存中，並提供了多種數據存儲類型（String、Hash、list、Set、SortedSet），還自身提供了持久化功能（2種：RDB、AOF），還可以把數據備份到磁盤中（redis的SAVE命令用於創建當前 redis數據庫的備份），防止redis宕機時的數據丟失。（會周期性的把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步）。我們使用的是spring與redis的java的客戶端jedis進行整合，可以利用jedis做分片式集群，解決了redis內存受限的問題。
單點登錄系統
之前實現的登錄和注冊是在同一個tomcat內部完成，而現在系統架構是每一個系統都是由一個團隊進行維護，每個系統都是單獨部署運行一個單獨的tomcat，所以，不能將用戶的登錄信息保存到session中（多個tomcat的session是不能共享的，即session共享問題），所以我們需要一個單獨的系統來維護用戶的登錄信息。我們是這樣做的，用戶去登錄頁面登錄，發送含有用戶信息的請求且會攜帶cookie去服務端數據庫查詢是否有該用戶，如果沒有提示用戶，如果有就把用戶信息保存到redis中，並生成一個token保存到cookie中。
后台管理系統
在后台管理系統中采用了Maven的多模塊化的管理，其中采用了水平切分的方式（垂直與水平划分的區別：垂直：功能模塊明確，層次不夠清晰，代碼重用性差。水平：層次清晰，代碼重用性高，易於獨立維護。），將各層分層開發，這樣做的好處是代碼重用性高，層次清晰，易於獨立維護。系統內部接口調用采用Httpclient（Dubbo），接口提供端采用RESTful風格的接口定義（一種軟件架構風格，設計風格而不是標准，只是提供了一組設計原則和約束條件）；系統之間的通知機制采用MQ的方式，使用ActiveMQ的實現，使用了ActiveMQ的消息訂閱模式的消息機；部署方面，采用了nginx+tomcat的模式，其中nginx的作用一方面是做反向代理、負載均衡、另一方面是做圖片等靜態資源的服務器。
我負責的模塊
在此項目中我主要負責后台管理模塊，主要實現商品管理和商品規格參數管理，對商品和商品規格進行CRUD操作。在實現前台調用后台數據時，為了實現系統間的調用，便使用了HttpClient技術來實現此功能，在后台提供了需要調用的接口。（HttpClient介紹、工作原理、優缺點）。如果在后台對商品進行操作，為了使前台數據與后台數據實現同步，我們使用了ActiveMQ消息隊列機制實現商品同步功能（ActiveMQ介紹、工作原理、優缺點）。
在此項目中，我還參與了購物車模塊的開發。在開發這個模塊時候，我們考慮了會員在未登錄和登錄兩種情況下把商品加入購物車，后台如何該保存商品信息。
在用戶商品詳情頁點擊加入購物車的時候，我們用了登錄攔截器來判斷用戶是否登錄。如果沒有登錄，將商品信息保存到cookie中，當用戶登錄后，再把商品持久到數據庫中；但是考慮到cookie儲存大小（4k）的問題，還有當cookie儲存的數據越多就會影響響應速度，我們決定使用redis來緩存用戶在未登錄狀態下的商品信息（redis介紹、原理、優缺點），在redis中設置緩存生存時間（如何做到的？），如果用戶在規定時間內沒有登錄，數據便會自動刪除。如果用戶在規定時間內登錄了，便會通過ActiveMQ消息隊列機制將數據同步到數據庫中。
不管你的簡歷和工作經驗是真是假，至少要做到能自圓其說就行。
參考鏈接：https://blog.csdn.net/qq_38584262/article/details/80707593