關(guān)于電商項目面試遇到的問題：
1、電商項目中有沒有用到多線程，哪些地方要用多線程？
2、你項目對于訂單是怎么處理的，假如一個客戶在下訂單的時候沒有購買怎么辦，對于顧客在購買商品的時候你們怎么處理你們的庫存？
3、計算一下133平方是多少？
4、你平時測試的流程？
5、你們數(shù)據(jù)庫怎么設(shè)計的？
6、你們怎么處理redis緩存的數(shù)據(jù)，怎么刪除的？
7、你覺得分布式開發(fā)的缺點是什么？
8、緩存技術(shù)你覺得在什么時候用的比較多？
9、你們怎么管理你們的內(nèi)存？
10、說說你對于web前端的優(yōu)化？
11、插入商品的話，要求級聯(lián)插入幾張表，你們當(dāng)時是怎么實現(xiàn)的？
12、支付接口是怎么做的？
13、redis為什么可以做緩存？
14、當(dāng)被問到某個?？齑嬖诎踩詥栴}（sso單點登錄系統(tǒng)）時，如何回答？
15、solr怎么設(shè)置搜索結(jié)果排名靠前（得分）？
16、activeMQ在項目中如何應(yīng)用的？
17、activeMQ如果數(shù)據(jù)提交不成功怎么辦？
1、電商項目中有沒有用到多線程，哪些地方要用多線程？
項目中自己寫的程序沒有用到多線程，通常使用開源框架編寫程序，框架中已將多線程進(jìn)行了封裝。
2、你項目對于訂單是怎么處理的，假如一個客戶在下訂單的時候沒有購買怎么辦，對于顧客在購買商品的時候你們怎么處理你們的庫存？
按照我們的理解：
如果客戶在下訂單的時候沒有支付成功，最終訂單沒有完成，此商品信息還在購物車。
如果未完成的訂單在一定的時間內(nèi)不支付，自動取消。
如果管理庫存？
對于庫存的管理，我們有專門的團(tuán)隊負(fù)責(zé)一個進(jìn)銷存系統(tǒng)的來管理庫存。
我們是在用戶付款后再調(diào)用進(jìn)銷存系統(tǒng)的接口，更改庫存。
3、計算一下133平方是多少？
需要詳細(xì)確定題目意思？
4、你平時測試的流程？
開發(fā)過程中自己編寫單元測試類對dao、service方法進(jìn)行測試。
一個模塊開發(fā)完成我會對模塊的業(yè)務(wù)流程進(jìn)行測試。
整個系統(tǒng)開發(fā)完成我們團(tuán)隊進(jìn)行集成測試，測試通過后提交給測試人員
系統(tǒng)進(jìn)行測試階段，我會協(xié)助測試人員進(jìn)行缺陷修復(fù)。
5、你們數(shù)據(jù)庫怎么設(shè)計的？
先對自己負(fù)責(zé)模塊的需求進(jìn)行分析，搞清楚業(yè)務(wù)需求。
定義出一個一個實體(表)
根據(jù)分析的業(yè)務(wù)需求定義表的一個一個字段
分析表與表之間的關(guān)系，定義外鍵。
6、你們怎么處理redis緩存的數(shù)據(jù)，怎么刪除的？
redis緩存的數(shù)據(jù)有一些是常駐緩存的，當(dāng)數(shù)據(jù)庫中數(shù)據(jù)有變化時做數(shù)據(jù)同步。
有一些緩存是設(shè)置有效期的，當(dāng)緩存到期后會自動刪除。
刪除redis緩存使用del或者h(yuǎn)del命令。
7、你覺得分布式開發(fā)的缺點是什么？
1. 和集中式相比，功能之間的調(diào)用使用的是接口調(diào)用，而不是直接調(diào)用。需要編寫穩(wěn)定有效的API。
2. 分布式系統(tǒng)之間的通信無法直接通知，需要使用消息機(jī)制（MQ）進(jìn)行通知。
3. 分布式開發(fā)涉及到多個開發(fā)團(tuán)隊，開發(fā)過程中需要頻繁的進(jìn)行溝通
4. 分布式開發(fā)中測試更加復(fù)雜，有效的測試用例可以幫助我們更好的剝離項目邏輯與協(xié)調(diào)組件系統(tǒng)。而小的集中系統(tǒng)開發(fā)甚至可以不使用測試用例。
5. 集中式系統(tǒng)開發(fā)可以使用debug從頭到尾進(jìn)行調(diào)試，而分布式層次太深，組件調(diào)用太多，使用debug很難整體調(diào)試。需要有效使用日志組件，更好的幫助我們找到問題。
8、緩存技術(shù)你覺得在什么時候用的比較多？
不是什么地方都需要使用緩存，符合以下兩個條件才需要使用緩存。
1. 數(shù)據(jù)訪問的頻率很高
2. 數(shù)據(jù)修改的頻率低
另外在使用緩存的時候，要注意緩存是否有效利用，需要及時清理掉緩存中不常用的數(shù)據(jù)
9、你們怎么管理你們的庫存？
我們主要是負(fù)責(zé)商城功能的開發(fā)，不直接管理商品庫存。
對于庫存的管理，我們有專門的團(tuán)隊負(fù)責(zé)一個進(jìn)銷存系統(tǒng)的來管理庫存
我們是在用戶付款后再調(diào)用進(jìn)銷存系統(tǒng)的接口，查詢商品的庫存數(shù)量。如果沒有庫存，則付款失敗并提示用戶。
10、說說你對于web前端的優(yōu)化？
前端是龐大的，包括 HTML、 CSS、 Javascript、Image 、Flash等等各種各樣的資源。前端優(yōu)化是復(fù)雜的，針對方方面面的資源都有不同的方式。那么，前端優(yōu)化的目的是什么 ?
- 從用戶角度而言，優(yōu)化能夠讓頁面加載得更快、對用戶的操作響應(yīng)得更及時，能夠給用戶提供更為友好的體驗。
- 從服務(wù)商角度而言，優(yōu)化能夠減少頁面請求數(shù)、或者減小請求所占帶寬，能夠節(jié)省可觀的資源。
總之，恰當(dāng)?shù)膬?yōu)化不僅能夠改善站點的用戶體驗并且能夠節(jié)省相當(dāng)?shù)馁Y源利用。
前端優(yōu)化的途徑有很多，按粒度大致可以分為兩類，第一類是頁面級別的優(yōu)化，例如 HTTP請求數(shù)、腳本的無阻塞加載、內(nèi)聯(lián)腳本的位置優(yōu)化等 ;第二類則是代碼級別的優(yōu)化，例如 Javascript中的DOM 操作優(yōu)化、CSS選擇符優(yōu)化、圖片優(yōu)化以及 HTML結(jié)構(gòu)優(yōu)化等等。另外，本著提高投入產(chǎn)出比的目的，后文提到的各種優(yōu)化策略大致按照投入產(chǎn)出比從大到小的順序排列
11、插入商品的話，要求級聯(lián)插入幾張表，你們當(dāng)時是怎么實現(xiàn)的？
** 此問題主要是考察商品表設(shè)計問題：**
電商網(wǎng)站中，商品表設(shè)計是電商的核心業(yè)務(wù)，在電商系統(tǒng)中占有很重要的地位：那么在商品業(yè)務(wù)系統(tǒng)中，保存商品表，就需要涉及很多相關(guān)表保存：
商品表涉及簡單業(yè)務(wù)流程表：
1）商品分類表
2）分類屬性表
3）貨品表
4）貨品表規(guī)格參數(shù)
5）商品表
6）品牌表
商品在保存時基本需要考慮以上幾張表的關(guān)系，保存商品表必須級聯(lián)保存商品屬性表，同時必須保存貨品表以及貨品對應(yīng)的規(guī)格參數(shù)表，同時必須維護(hù)商品對應(yīng)的商品規(guī)格屬性表
12、支付接口是怎么做的？
企業(yè)支付可以使用銀聯(lián)進(jìn)行支付，如果使用銀聯(lián)進(jìn)行支付，那么需要去申請,填寫申請材料，獲取銀聯(lián)提供的密鑰。
企業(yè)還可以是使用第三方支付進(jìn)行支付。
一般支付接口流程都大同小異。下面以支付寶為例：
接口開發(fā)最重要的應(yīng)該是理解數(shù)據(jù)交互流程了，流程弄清了，并理解為何這么設(shè)計，開發(fā)起來也是事半功倍
首先，要準(zhǔn)備下面幾個參數(shù)：
企業(yè)支付寶賬號的PID(也叫ParnerID)和KEY，如果使用RSA簽名而不是MD5的話，還要把RSA私鑰準(zhǔn)備好支付時用戶看到的東西：商品名稱(subject)、支付總額（total_fee）、購買數(shù)量交易后的跳轉(zhuǎn)地址，交易成功后用戶可以手工點擊，或頁面延遲自動跳轉(zhuǎn)到這個地址(return_url)交易狀態(tài)異步通知地址，交易成功或交易關(guān)閉會把消息POST到這個地址(notify_url)
發(fā)起支付流程如下：
網(wǎng)站按照指定要求，用token和自己的私鑰，構(gòu)造一個重定向得到支付地址(調(diào)用支付接口)
網(wǎng)站把重定向地址返回給瀏覽器
瀏覽器自動重定向到該地址，即包含了token、網(wǎng)站簽名的支付寶交易頁面
支付寶顯示當(dāng)前交易金額、數(shù)量、賣家等信息
用戶用自己的支付寶賬號支付這筆金額
支付寶把用戶支付成功（或失敗）這個消息和訂單號加上支付寶的簽名，使用HTTP POST的方式通知網(wǎng)站（失敗的話，會隔段時間重新發(fā)送）
網(wǎng)站處理交易后續(xù)邏輯（發(fā)貨、訂單狀態(tài)存儲之類的）
網(wǎng)站返回"success"字符串給支付寶，表示該通知已經(jīng)處理，不用再重發(fā)
支付寶顯示支付成功頁面給用戶（這一步和第10步是不分先后發(fā)生的）
支付成功頁面延遲自動跳轉(zhuǎn)，或用戶點擊“返回商戶頁面”，跳轉(zhuǎn)到網(wǎng)站的支付結(jié)束頁面（此時不一定成功處理支付寶發(fā)來的通知），但會在URL帶上當(dāng)前的訂單號和狀態(tài)。
13、redis為什么可以做緩存？
Redis就是一個高性能的，分布式的內(nèi)存對象緩存系統(tǒng)，用于在動態(tài)應(yīng)用中減少數(shù)據(jù)庫負(fù)載，提升訪問速度。
第一次發(fā)送請求時，從RDBMS中獲取數(shù)據(jù)并返回，同時將該數(shù)據(jù)保存分布式緩存系統(tǒng)中；當(dāng)用戶再次發(fā)送請求時直接從緩存中獲取，提高性能。
14、當(dāng)被問到某個?？齑嬖诎踩詥栴}（sso單點登錄系統(tǒng)）時，如何回答？
1、票據(jù)ticket超時
2、登錄一次，所有授權(quán)的應(yīng)用系統(tǒng)都可以訪問，可能導(dǎo)致一些信息泄露。
3、通過cookie維護(hù)的票據(jù)ticket應(yīng)該加密
4、防止cookie被偽造或者被竊取
15、solr怎么設(shè)置搜索結(jié)果排名靠前（得分）？
1、配置solr的solrconfig.xml中edismax，來改變Boost打分規(guī)則
2、或者在solr的schema中增加一個字段，該字段專門用于排序
16、activeMQ在項目中如何應(yīng)用的？
答：
如何應(yīng)用：activemq作為消息中間件，首先需要對activemq進(jìn)行安裝；其次要根據(jù)需求，分析消息的生產(chǎn)者和發(fā)布者；最后發(fā)送消息時，需要添加異常處理機(jī)制。
應(yīng)用場景：activemq在電商項目中的應(yīng)用場景比較廣泛，比如索引同步、詳情頁靜態(tài)化、商品上下架申請、調(diào)價申請、訂單狀態(tài)已支付后需要通知庫房發(fā)貨等。
17、activeMQ如果數(shù)據(jù)提交不成功怎么辦？
答：該問題比較模糊，具體activemq的問題如下：
1、消費者接收消息不成功，怎么辦？
對于activemq來說，如果消息生產(chǎn)者沒有把消息發(fā)送到mq中的broker里面，則消息不會重新發(fā)送。
如果消息生產(chǎn)者已經(jīng)把消息發(fā)送到mq中的broker里面，但是消息的消費者沒有應(yīng)答（可能沒有接收到，也可能是接收到之后，處理業(yè)務(wù)邏輯時出現(xiàn)異常）。此時activemq會默認(rèn)最多重發(fā)6次消息，如果依然沒有接收到消息，那么該消息會進(jìn)入DLQ（Dead Letter Queue死信隊列）。
2、消息接收成功，但是處理出現(xiàn)異常，或者沒有應(yīng)答怎么辦？
在程序中捕獲異常，將消息重新放入MQ，由其它消費方再次處理。
