商城項(xiàng)目面試問題整理

1.網(wǎng)站并發(fā)數(shù)：

經(jīng)過壓力測試可以支持3000左右的并發(fā)，可以滿足目前的業(yè)務(wù)需求。由于我們的系統(tǒng)是分布式架構(gòu)，支持水平擴(kuò)展，如果將來并發(fā)量提高的話，可以增加服務(wù)器來提高并發(fā)量。

2.人員配置

產(chǎn)品經(jīng)理：3人，確定需求以及給出產(chǎn)品原型圖。

項(xiàng)目經(jīng)理：1人，項(xiàng)目管理。

前端團(tuán)隊(duì)：5人，根據(jù)產(chǎn)品經(jīng)理給出的原型制作靜態(tài)頁面。

后端團(tuán)隊(duì)：20人，實(shí)現(xiàn)產(chǎn)品功能。

測試團(tuán)隊(duì)：5人，測試所有的功能。

運(yùn)維團(tuán)隊(duì)：3人，項(xiàng)目的發(fā)布以及維護(hù)。

3.開發(fā)周期

采用迭代開發(fā)的方式進(jìn)行，一般一次迭代的周期為一個月左右。

4.Sku/spu

最小庫存量單位。

Sku==商品id

5.你說你用了redis緩存，你redis存的是什么格式的數(shù)據(jù)，是怎么存的

redis中存儲的都是key-value格式的。拿商品數(shù)據(jù)來說，key就是商品id，value是商品相關(guān)信息的json數(shù)據(jù)。

6.你前臺portal采用4臺服務(wù)器集群部署，那能前臺高并發(fā)訪問性能提上去了，那數(shù)據(jù)庫會不會造成一個瓶頸，這一塊你是怎么處理的？

portal系統(tǒng)在高并發(fā)的情況下如果每次請求都請求都查詢數(shù)據(jù)庫確實(shí)會出現(xiàn)數(shù)據(jù)庫的瓶頸。為了降低數(shù)據(jù)庫壓力，在服務(wù)層會添加一個緩存，用redis實(shí)現(xiàn)，這樣的話請求先到緩存中查找是否有緩存的內(nèi)容，如果有直接從緩存中取數(shù)據(jù)，如果沒有再到數(shù)據(jù)庫中查詢。這樣數(shù)據(jù)庫的壓力就不會那么大了。

7.你購物車存cookie里邊 可以實(shí)現(xiàn)不登錄就可以使用購物車 那么我現(xiàn)在沒有登錄把商品存購物車了 然后登錄了 然后我換臺電腦并且登錄了還能不能看見我購物車的信息？如果看不到怎么做到cookie同步，就是在另外一臺電腦上可以看到購物車信息

淘淘商城現(xiàn)階段使用的僅僅是把購物車的商品寫入cookie中，這樣服務(wù)端基本上么有存儲的壓力。但是弊端就是用戶更換電腦后購物車不能同步。打算下一步這么實(shí)現(xiàn)：當(dāng)用戶沒有登錄時向購物車添加商品是添加到cookie中，當(dāng)用戶登錄后購物車的信息是存儲在redis中的并且是跟用戶id向關(guān)聯(lián)的，此時你更換電腦后使用同一賬號登錄購物車的信息就會展示出來。

8.如果用戶一直添加購物車添加商品怎么辦？并且他添加一次你查詢一次數(shù)據(jù)庫？互聯(lián)網(wǎng)上用戶那么多，這樣會對數(shù)據(jù)庫造成很大壓力你怎么辦？

當(dāng)前我們使用cookie的方式來保存購物車的數(shù)據(jù)，所以當(dāng)用戶往購物車中添加商品時，并不對數(shù)據(jù)庫進(jìn)行操作。將來把購物車商品放入redis中，redis是可以持久化的可以永久保存，此時就算是頻繁的往購物車中添加數(shù)據(jù)也沒用什么問題。

9.電商活動倒計(jì)時方案

確定一個基準(zhǔn)時間。可以使用一個sql語句從數(shù)據(jù)庫中取出一個當(dāng)前時間。SELECT NOW()；

活動開始的時間是固定的。

使用活動開始時間-基準(zhǔn)時間可以計(jì)算出一個秒為單位的數(shù)值。

在redis中設(shè)置一個key（活動開始標(biāo)識）。設(shè)置key的過期時間為第三步計(jì)算出來的時間。

展示頁面的時候取出key的有效時間。Ttl命令。使用js倒計(jì)時。

一旦活動開始的key失效，說明活動開始。

需要在活動的邏輯中，先判斷活動是否開始。

10.秒殺搶購庫存解決方案

把商品的數(shù)量放到redis中。

秒殺時使用decr命令對商品數(shù)量減一。如果不是負(fù)數(shù)說明搶到。

一旦返回數(shù)值變?yōu)?說明商品已售完。

11.dubbo服務(wù)開發(fā)流程，運(yùn)行流程？zookeeper注冊中心的作用？

使用流程：

第一步：要在系統(tǒng)中使用dubbo應(yīng)該先搭建一個注冊中心，一般推薦使用zookeeper。

第二步：有了注冊中心然后是發(fā)布服務(wù)，發(fā)布服務(wù)需要使用spring容器和dubbo標(biāo)簽來發(fā)布服務(wù)。并且發(fā)布服務(wù)時需要指定注冊中心的位置。

第三步：服務(wù)發(fā)布之后就是調(diào)用服務(wù)。一般調(diào)用服務(wù)也是使用spring容器和dubbo標(biāo)簽來引用服務(wù)，這樣就可以在客戶端的容器中生成一個服務(wù)的代理對象，在action或者Controller中直接調(diào)用service的方法即可。

Zookeeper注冊中心的作用主要就是注冊和發(fā)現(xiàn)服務(wù)的作用。類似于房產(chǎn)中介的作用，在系統(tǒng)中并不參與服務(wù)的調(diào)用及數(shù)據(jù)的傳輸。

12.redis為什么可以做緩存？項(xiàng)目中使用redis的目的是什么？redis什么時候使用？

? 1.Redis是key-value形式的nosql數(shù)據(jù)庫。可以快速的定位到所查找的key，并把其中的value取出來。并且redis的所有的數(shù)據(jù)都是放到內(nèi)存中，存取的速度非常快，一般都是用來做緩存使用。

? 2.項(xiàng)目中使用redis一般都是作為緩存來使用的，緩存的目的就是為了減輕數(shù)據(jù)庫的壓力提高存取的效率。

? 3.在互聯(lián)網(wǎng)項(xiàng)目中只要是涉及高并發(fā)或者是存在大量讀數(shù)據(jù)的情況下都可以使用redis作為緩存。當(dāng)然redis提供豐富的數(shù)據(jù)類型，除了緩存還可以根據(jù)實(shí)際的業(yè)務(wù)場景來決定redis的作用。例如使用redis保存用戶的購物車信息、生成訂單號、訪問量計(jì)數(shù)器、任務(wù)隊(duì)列、排行榜等。

1

2

3

4

5

13.acitveMQ的作用、原理？（生產(chǎn)者。消費(fèi)者。 p2p、訂閱實(shí)現(xiàn)流程）

Activemq的作用就是系統(tǒng)之間進(jìn)行通信。當(dāng)然可以使用其他方式進(jìn)行系統(tǒng)間通信，如果使用Activemq的話可以對系統(tǒng)之間的調(diào)用進(jìn)行解耦，實(shí)現(xiàn)系統(tǒng)間的異步通信。原理就是生產(chǎn)者生產(chǎn)消息，把消息發(fā)送給activemq。Activemq接收到消息，然后查看有多少個消費(fèi)者，然后把消息轉(zhuǎn)發(fā)給消費(fèi)者，此過程中生產(chǎn)者無需參與。消費(fèi)者接收到消息后做相應(yīng)的處理和生產(chǎn)者沒有任何關(guān)系。

14.activeMQ在項(xiàng)目中如何應(yīng)用的？

Activemq在項(xiàng)目中主要是完成系統(tǒng)之間通信，并且將系統(tǒng)之間的調(diào)用進(jìn)行解耦。例如在添加、修改商品信息后，需要將商品信息同步到索引庫、同步緩存中的數(shù)據(jù)以及生成靜態(tài)頁面一系列操作。在此場景下就可以使用activemq。一旦后臺對商品信息進(jìn)行修改后，就向activemq發(fā)送一條消息，然后通過activemq將消息發(fā)送給消息的消費(fèi)端，消費(fèi)端接收到消息可以進(jìn)行相應(yīng)的業(yè)務(wù)處理。

15.activeMQ如果數(shù)據(jù)提交不成功怎么辦？

Activemq有兩種通信方式，點(diǎn)到點(diǎn)形式和發(fā)布訂閱模式。如果是點(diǎn)到點(diǎn)模式的話，如果消息發(fā)送不成功此消息默認(rèn)會保存到activemq服務(wù)端知道有消費(fèi)者將其消費(fèi)，所以此時消息是不會丟失的。

如果是發(fā)布訂閱模式的通信方式，默認(rèn)情況下只通知一次，如果接收不到此消息就沒有了。這種場景只適用于對消息送達(dá)率要求不高的情況。如果要求消息必須送達(dá)不可以丟失的話，需要配置持久訂閱。每個訂閱端定義一個id，在訂閱是向activemq注冊。發(fā)布消息和接收消息時需要配置發(fā)送模式為持久化。此時如果客戶端接收不到消息，消息會持久化到服務(wù)端，直到客戶端正常接收后為止。

16.當(dāng)被問到某個模快存在安全性問題（sso單點(diǎn)登錄系統(tǒng)）時，如何回答？

目前商城的sso系統(tǒng)的解決方案中直接把token保存到cookie中，確實(shí)存在安全性問題。但是實(shí)現(xiàn)簡單方便。如果想提高安全性可以使用cas框架實(shí)現(xiàn)單點(diǎn)登錄。

https://www.apereo.org/projects/cas

17.當(dāng)技術(shù)面試官問到你某個技術(shù)點(diǎn)更深層次研究時，自己沒有深入了解怎么回答？

如果沒有深入研究就直接回答不知道就可以了。

18.solr怎么設(shè)置搜索結(jié)果排名靠前（得分）？

可以設(shè)置文檔中域的boost值，boost值越高計(jì)算出來的相關(guān)度得分就越高，排名也就越靠前。此方法可以把熱點(diǎn)商品或者是推廣商品的排名提高。

19.solr的原理

Solr是基于Lucene開發(fā)的全文檢索服務(wù)器，而Lucene就是一套實(shí)現(xiàn)了全文檢索的api，其本質(zhì)就是一個全文檢索的過程。全文檢索就是把原始文檔根據(jù)一定的規(guī)則拆分成若干個關(guān)鍵詞，然后根據(jù)關(guān)鍵詞創(chuàng)建索引，當(dāng)查詢時先查詢索引找到對應(yīng)的關(guān)鍵詞，并根據(jù)關(guān)鍵詞找到對應(yīng)的文檔，也就是查詢結(jié)果，最終把查詢結(jié)果展示給用戶的過程。

20.solr里面IK分詞器的原理

IK分析器的分詞原理本質(zhì)上是詞典分詞。現(xiàn)在內(nèi)存中初始化一個詞典，然后在分詞過程中逐個讀取字符，和字典中的字符相匹配，把文檔中的所有的詞語拆分出來的過程。

21.支付接口是怎么做的？

面試中可以說支付這部分不是我們做的，我們項(xiàng)目中并沒有涉及支付部分的處理。如果想了解支付是如何實(shí)現(xiàn)可以參考之前學(xué)過的易寶支付相關(guān)處理以及支付寶、微信支付相關(guān)文檔。

支付寶：

https://doc.open.alipay.com/doc2/apiDetail.htm?spm=a219a.7629065.0.0.eeTXH8&apiId=850&docType=4#

微信支付：

https://mp.weixin.qq.com/cgi-bin/readtemplate?t=business/faq_tmpl

22.業(yè)務(wù)如何說？先說業(yè)務(wù)、說表、說具體實(shí)現(xiàn)？

先說總體的業(yè)務(wù)流程，然后再說具體業(yè)務(wù)的實(shí)現(xiàn)方法及使用的技術(shù)。最后說你在系統(tǒng)中負(fù)責(zé)的內(nèi)容。不需要說表結(jié)構(gòu)。

23.單點(diǎn)登錄系統(tǒng)，如果cookie禁用，你們怎么解決?

如果禁用cookie可以使用url中帶參數(shù)，把token傳遞給服務(wù)端。當(dāng)然此方法涉及安全性問題，其實(shí)在cookie中保存token同樣存在安全性問題。推薦使用sso框架CAS實(shí)現(xiàn)單點(diǎn)登錄。

24.你們做移動端沒有，如果沒有移動端，你們?yōu)槭裁醋鰡吸c(diǎn)登錄？

單點(diǎn)登錄并不是為移動端準(zhǔn)備的，移動端有自己的登錄方式。單點(diǎn)登錄是解決在同一個公司內(nèi)部多個互信網(wǎng)站之間進(jìn)行跳轉(zhuǎn)時不需要多次登錄，多個系統(tǒng)統(tǒng)一登錄入口。

25.單點(diǎn)登錄的核心是什么？

單點(diǎn)登錄的核心是如何在多個系統(tǒng)之間共享身份信息。

26.除了單點(diǎn)登陸，還做過什么登陸的方式？

這是什么狗屁問題？除了單點(diǎn)登錄那就是普通登錄方式，用戶在同一個公司的多個系統(tǒng)之間跳轉(zhuǎn)時需要多次登錄。

27.單點(diǎn)登錄，http無狀態(tài)的，別人模仿如何在后端處理

http是無狀態(tài)的，如果別人模仿瀏覽器發(fā)送http請求，一般后臺是無法識別的。如果對安全要求高的情況下應(yīng)該是https協(xié)議。可以保證在通信過程中無法竊取通信內(nèi)容。

28.安全性問題（別的網(wǎng)站使用爬蟲技術(shù)爬你的網(wǎng)站怎么辦？有沒有安全措施）

單位時間內(nèi)請求次數(shù)超過某個閾值就讓輸入驗(yàn)證碼，可以極大降低抓取的速度，如果多次超過某個閥值可以加入黑名單。還有就是頁面內(nèi)容使用json返回，數(shù)據(jù)經(jīng)常變一變格式，或者js動態(tài)生成頁面內(nèi)容。

29.商品存入數(shù)據(jù)庫怎么保證數(shù)據(jù)庫數(shù)據(jù)安全?

? 1.對用戶安全管理

1

用戶操作數(shù)據(jù)庫時，必須通過數(shù)據(jù)庫訪問的身份認(rèn)證。刪除數(shù)據(jù)庫中的默認(rèn)用戶，使用自定義的用戶及高強(qiáng)度密碼。

? 2.定義視圖

1

為不同的用戶定義不同的視圖，可以限制用戶的訪問范圍。通過視圖機(jī)制把需要保密的數(shù)據(jù)對無權(quán)存取這些數(shù)據(jù)的用戶隱藏起來，可以對數(shù)據(jù)庫提供一定程度的安全保護(hù)。實(shí)際應(yīng)用中常將視圖機(jī)制與授權(quán)機(jī)制結(jié)合起來使用，首先用視圖機(jī)制屏蔽一部分保密數(shù)據(jù)，然后在視圖上進(jìn)一步進(jìn)行授權(quán)。

? 3.數(shù)據(jù)加密

1

數(shù)據(jù)加密是保護(hù)數(shù)據(jù)在存儲和傳遞過程中不被竊取或修改的有效手段。

? 4.數(shù)據(jù)庫定期備份

1

5)審計(jì)追蹤機(jī)制

審計(jì)追蹤機(jī)制是指系統(tǒng)設(shè)置相應(yīng)的日志記錄，特別是對數(shù)據(jù)更新、刪除、修改的記錄，以便日后查證。日志記錄的內(nèi)容可以包括操作人員的名稱、使用的密碼、用戶的IP地址、登錄時間、操作內(nèi)容等。若發(fā)現(xiàn)系統(tǒng)的數(shù)據(jù)遭到破壞，可以根據(jù)日志記錄追究責(zé)任，或者從日志記錄中判斷密碼是否被盜，以便修改密碼，重新分配權(quán)限，確保系統(tǒng)的安全。

30.訂單表的數(shù)據(jù)量太大,我把訂單分到許多表中,那么我我想用一條sql查處所有的訂單,怎么解決?

分庫情況下：可以使用mycat數(shù)據(jù)庫中間件實(shí)現(xiàn)多個表的統(tǒng)一管理。雖然物理上是把一個表中的數(shù)據(jù)保存到多個數(shù)據(jù)庫中，但是邏輯上還是一個表，使用一條sql語句就可以把數(shù)據(jù)全部查詢出來。

單庫情況下：需要動態(tài)生成sql語句。先查詢訂單相關(guān)的表，然后將查詢多個表的sql語句使用union連接即可。

31.咱們單點(diǎn)登錄模塊中，別人偽造我們cookie中的token怎么辦？

服務(wù)端是無法阻止偽造cookie的，如果對安全性要求高的話可以可使用cas框架。

32.第一個是當(dāng)兩個客戶同時買一件商品時庫存只有一個了,怎么控制?

可以使用mysql的行鎖機(jī)制，實(shí)現(xiàn)樂觀鎖，在更新商品之前將商品鎖定，其他用戶無法讀取，當(dāng)此用戶操作完畢后釋放鎖。當(dāng)并發(fā)量高的情況下，需要使用緩存工具例如redis來管理庫存。

33.對數(shù)據(jù)庫只是采用了讀寫分離,并沒有完全解決數(shù)據(jù)庫的壓力,那么有什么辦法解決?

如果數(shù)據(jù)庫壓力確實(shí)很大的情況下可以考慮數(shù)據(jù)庫分片，就是將數(shù)據(jù)庫中表拆分到不同的數(shù)據(jù)庫中保存。可以使用mycat中間件。

34.同一賬號以客戶端登錄怎么擠掉另一端。

用戶登錄后需要在Session中保存用戶的id。當(dāng)用戶登錄時，從當(dāng)前所有的Session中判斷是否有此用戶id的存在，如果存在的話就把保存此用戶id的Session銷毀。

35.solr的索引查詢?yōu)槭裁幢葦?shù)據(jù)庫要快。

Solr使用的是Lucene API實(shí)現(xiàn)的全文檢索。全文檢索本質(zhì)上是查詢的索引。而數(shù)據(jù)庫中并不是所有的字段都建立的索引，更何況如果使用like查詢時很大的可能是不使用索引，所以使用solr查詢時要比查數(shù)據(jù)庫快。

36.solr索引庫個別數(shù)據(jù)索引丟失怎么辦。

首先Solr是不會丟失個別數(shù)據(jù)的。如果索引庫中缺少數(shù)據(jù)，那就向索引庫中添加。（靠！什么狗屁問題！！！）

37.Lucene索引優(yōu)化。

直接使用Lucene實(shí)現(xiàn)全文檢索已經(jīng)是過時的方案，推薦使用solr。Solr已經(jīng)提供了完整的全文檢索解決方案。

原文鏈接?https://blog.csdn.net/qq_43192819/article/details/89006217