電商面試問題 有用

1.freemarker生成的靜態化頁面，若是商品的信息更改之後，會不會生成新的靜態化化頁面，freemarker靜態化頁面的數據是從哪裏調用出來的，若是不是從數據裏面掉的數據的，這個地方須要用到同步，和誰同步

 

答案:

1.若是商品信息更改之後，是須要生成新的靜態化頁面。（注意：淘淘商城中沒有修改商品而後生成新的靜態化頁面的邏輯，實際中是須要這一部分邏輯的）; 

2.freemarker模塊頁面中的數據是在建立靜態化頁面的時候獲取到的，那麼這部分數據若是真採起淘淘商城中發mq去從數據庫中查詢，那也就不用擔憂這麼多數據，從數據庫中獲取不是性能很慢。這個就不是本問題所涉及的了。若是不發mq也行啊，直接現存的數據爲啥不行呢？

3.對於數據庫高併發，緩解數據庫查詢壓力，咱們從業務設計角度分商品詳情頁面內容緩存和頁面靜態化處理兩個維度去講解。靜態化頁面是在商品新增或者修改的時候產生新的靜態化頁面。這個問題，是假設了商品數據放到某一個地方存起來，而後從存的地方取出來做爲模板中的數據。這個設計我不敢苟同。設計上有漏洞，實現上沒有一點優點。經過查看京東

商品的詳情頁，F12能夠看到整個詳情頁面也是應用了靜態化頁面，經過nginx去找頁面。

******************************************************************************************

2.若是數據庫的信息更改之後，那麼索引庫和緩存庫裏面的信息是怎麼更新的？不可能每次都去訪問數據庫吧。

 

答案:

a>該問題前提是商品詳情頁面若是採起的是緩存商品數據這種設計的話，那麼當商品信息更改之後，索引和緩

存中數據更新同步邏輯在淘淘商城中設計是採起了發mq異步從數據庫中查詢的。若是從數據庫中根據發mq發來

的商品主鍵id來查詢數據庫不是不能夠。若是數據庫查詢很慢，性能很低，那麼就設計到優化該邏輯的設計

了。好比：是否能夠採起新增商品臨時表，發的mq就從臨時表中去取；還好比索引和緩存的數據很少，我也可

以直接經過mq把商品內容發過來啊。我甚至，能夠不採用發mq直接去同步。

 

***********************************************************************

3.消息隊列MQ，若是消息丟失了怎麼辦，我怎麼能知道消息有沒有丟失，遇到這種問題我怎麼處理

答案:

[html] view plain copy

a>消息丟失能夠分爲消息生產者丟失和消息消費者丟失；消息丟監控中心看不到消息，且會報異常。

常規作法是開啓事務+設置持久化。

對於消費端須要session.commit()，提價事務。另外除了Session.AUTO_ACKNOWLEDGE還有分別以下設置：

 

b>注意對於業務中依賴消息的且高密度，高併發的場景，咱們推薦使用RabbitMQ，該mq提供瞭解決生成者和消費者消息丟失的解決方案；主要思路主要是放在怎麼確認消息已經收到，也就是針對不一樣生產者和消費者提供了確認機制.請參考：http://www.cnblogs.com/Leo_wl/p/6581989.html

c>還能夠設計一張路由表，消費者消費成功以後就會修改該表中記錄狀態

******************************************************************************************

4.若是兩我的，兩臺電腦同時登陸同一個賬號，同時對同一個帳單提交，帳單同時被服務器處理，那服務器應該先處理誰的，或者怎麼規避這個問題。非單點登陸，重定向，stoken攔截器的問題

 

答案:

a>如今購物app和desktop都會同時存在，且有的電商是容許統一帳號在不一樣電商上登陸的。以京東爲例，在本地不一樣電腦使用同一個帳號登陸，是能夠的。

b>經過實際演示，A，B兩臺電腦登陸同一個帳號，同時對同一件商品提交訂單時，若是A電腦先下訂單，那麼B再下訂單也會產生訂單。這就比如你買了2件商品同樣，實際過程當中京東沒有由於是同一帳號，不一樣電腦上提交同一商品而規避用戶重複購買。由於下訂單也是前後順序的。

c>經過實際演示，A，B兩臺電腦登陸同一個帳號，對同一件商品同時刪除，若是A電商先刪除該商品，B電腦再刪除該商品，那麼B電商點擊刪除操做以後，會彈出刪除失敗提示框。

d>經過springmvc HandlerInterceptor攔截器配置，preHandle()方法去檢查客戶機請求是否攜帶token，京東就是這樣作的。

 

******************************************************************************************

5.用戶購買商品時，何時才減小庫存。

答：a>提交訂單，支付狀態由未付款改爲支付成功後，纔會減小庫存。倉庫系統

不會根據用戶臨時行爲去減小庫存商品數量。這樣帶來的數據變更太大。而是會根據下單後

商品支付成功狀態來減小庫存。

 

 

******************************************************************************************

7.日誌文件的管理。

答：

a>通常大型的電商系統都會將各個子系統的中後臺操做進行監控，隨時可以查看系統運行狀態。那麼其後臺管

理系統的日誌能夠設計日誌表來專門存儲後臺操做。這一類日誌稱之爲自定義日誌信息；

b>除此以外，還有咱們各個服務產生的日誌，例如tomcat,solr等日誌這些日誌也能夠分佈式日誌框架收集。

 

c>將咱們自定的日誌信息和系統服務日誌信息收集以後，就能夠經過日誌架構，來搭建日誌管理系統了。這些

日誌信息能夠都存儲在日誌服務器中。有專門的報表及其報警系統組成。

 

 

 

******************************************************************************************

8.項目中用到了多少臺服務器，測試環境和正式環境各有多少臺。

答：視項目規模來看。

a>一個門戶網站的uv量月統計達到幾十萬，至少也得部署4臺，這樣也可以應該理論值1000-2000併發量。另外還得看服務器性能和架構，因此單純要問有多少臺，沒有多少意義。真要是說，將項目定位成小型-中型-大型-超大型系統。那麼算上其餘系統所須要的服務器依次須要4-6臺---6-10臺—至少20臺---數據節點，上千。

b>測試環境主要是供RD和QA使用，通常都會各自分配一臺。正式環境就是上面所說的了。

 

 

******************************************************************************************

9.從通常的商城來看，能夠分爲B2C與C2C，也就是單商城系統和多商城系統。單商城的系統，基本上就是所有商品生成一個訂單，根據訂單號支付，若是是多商城系統，假定咱們使用微信支付，微信支付每次下單隻能使用惟一一個單號，那麼咱們只能把不一樣的店鋪，例如店鋪A和店鋪B的全部商品，都統一放到一個訂單號去微信下單支付。可是，這樣子又違反了訂單規則：不一樣的店鋪存在着不一樣的訂單業務，店鋪和訂單是一對多的關係，並且每一個訂單號必須是惟一的。怎麼辦？這個地方須要用到拆單，怎麼拆

 

答案:暫時先待定

******************************************************************************************

10.商品修改之後，購物車裏面的價格是怎麼處理的！！

答：該問題假設的情景是用戶添加了一件商品，那麼此時商品價格修改了。此時下訂單以什麼爲準？該問題分爲下訂單前和下訂單後。

a>一旦下了訂單，那麼訂單中就有了該商品的金額，及時修改了商品價格，也是按照訂單來支付的。

b>若是沒有下訂單，那麼在下訂單的時候，是按照最新修改的商品價格來計算該商品金額的。

 

******************************************************************************************

11.商品修改以後，怎麼同步的！！！

 

答：商品修改以後，須要同步的是什麼？

a>若是按照淘淘商城中，新增商品同步到solr索引，同步到redis中。那麼就能夠在修改商品的時候，add(document),set(item)。淘淘商城中採起的策略是發mq，根據id查詢，這種方式去同步的，對於redis就是直接刪除，而後新增。

******************************************************************************************

12.在項目中併發是怎麼解決的，用到哪些技術，具體是怎麼實現的，原理是什麼！

答：這裏談到的併發，指的是在同一時刻服務器應該可以同時處理的請求的量。解決併發能夠從以下角度去解決：

a>購買高性能服務器和數據庫（不能從根本上解決高併發）

b>頁面靜態化處理

  靜態化頁面效率高消耗最小，避免大量數據庫訪問量。

c>圖片服務器分離（基本網站都採起的策略）

使用獨立的圖片服務器下降提供頁面訪問請求的服務器系統壓力而且能夠保證系統不會由於圖片問題而崩潰，在應用服務器

和圖片服務器上，能夠進行不一樣的配置優化，

d>集羣架構

增長一臺服務器分擔原有服務器訪問和存儲壓力來改善負載壓力。比較成熟的集羣架構要保證可伸縮性：如圖

e>負載均衡（軟件和硬件的負載，通常使用軟件負載更多）

可將用戶瀏覽器訪問請求分發到應用服務器集羣中的任何一臺服務器上，若是有更多用戶，就在集羣中加入更多的服務器，使用應用服務器服務器的負載壓力再也不成爲整個網站的瓶頸。

f>特定業務功能能夠考慮使用多線程去處理

g>緩存

減小數據庫訪問壓力

h>讀寫分離，分庫分表

i>代碼優化

 

 

dubbo服務開發流程，運行流程？zookeeper註冊中心的做用？

使用流程：

第一步：要在系統中使用dubbo應該先搭建一個註冊中心，通常推薦使用zookeeper。

第二步：有了註冊中心而後是發佈服務，發佈服務須要使用spring容器和dubbo標籤來發布服務。而且發佈服務時須要指定註冊中心的位置。

第三步：服務發佈以後就是調用服務。通常調用服務也是使用spring容器和dubbo標籤來引用服務，這樣就能夠在客戶端的容器中生成一個服務的代理對象，在action或者Controller中直接調用service的方法便可。

Zookeeper註冊中心的做用主要就是註冊和發現服務的做用。相似於房產中介的做用，在系統中並不參與服務的調用及數據的傳輸。

 

redis爲何能夠作緩存？項目中使用redis的目的是什麼？redis何時使用？

1）Redis是key-value形式的nosql數據庫。能夠快速的定位到所查找的key，並把其中的value取出來。而且redis的全部的數據都是放到內存中，存取的速度很是快，通常都是用來作緩存使用。

2）項目中使用redis通常都是做爲緩存來使用的，緩存的目的就是爲了減輕數據庫的壓力提升存取的效率。

3）在互聯網項目中只要是涉及高併發或者是存在大量讀數據的狀況下均可以使用redis做爲緩存。固然redis提供豐富的數據類型，除了緩存還能夠根據實際的業務場景來決定redis的做用。例如使用redis保存用戶的購物車信息、生成訂單號、訪問量計數器、任務隊列、排行榜等。

acitveMQ的做用、原理？（生產者。消費者。 p2p、訂閱實現流程）
Activemq的做用就是系統之間進行通訊。固然可使用其餘方式進行系統間通訊，若是使用Activemq的話能夠對系統之間的調用進行解耦，實現系統間的異步通訊。原理就是生產者生產消息，把消息發送給activemq。Activemq接收到消息，而後查看有多少個消費者，而後把消息轉發給消費者，此過程當中生產者無需參與。消費者接收到消息後作相應的處理和生產者沒有任何關係。
當技術面試官問到你某個技術點更深層次研究時，本身沒有深刻了解怎麼回答？
若是沒有深刻研究就直接回答不知道就能夠了。
solr怎麼設置搜索結果排名靠前（得分）？
能夠設置文檔中域的boost值，boost值越高計算出來的相關度得分就越高，排名也就越靠前。此方法能夠把熱點商品或者是推廣商品的排名提升。

solr的原理

Solr是基於Lucene開發的全文檢索服務器，而Lucene就是一套實現了全文檢索的api，其本質就是一個全文檢索的過程。全文檢索就是把原始文檔根據必定的規則拆分紅若干個關鍵詞，而後根據關鍵詞建立索引，當查詢時先查詢索引找到對應的關鍵詞，並根據關鍵詞找到對應的文檔，也就是查詢結果，最終把查詢結果展現給用戶的過程。
solr裏面IK分詞器的原理
IK分析器的分詞原理本質上是詞典分詞。如今內存中初始化一個詞典，而後在分詞過程當中逐個讀取字符，和字典中的字符相匹配，把文檔中的全部的詞語拆分出來的過程。

支付接口是怎麼作的？

面試中能夠說支付這部分不是咱們作的，咱們項目中並無涉及支付部分的處理。若是想了解支付是如何實現能夠參考以前學過的易寶支付相關處理以及支付寶、微信支付相關文檔。
支付寶：
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

activeMQ在項目中如何應用的？

Activemq在項目中主要是完成系統之間通訊，而且將系統之間的調用進行解耦。例如在添加、修改商品信息後，須要將商品信息同步到索引庫、同步緩存中的數據以及生成靜態頁面一系列操做。在此場景下就可使用activemq。一旦後臺對商品信息進行修改後，就向activemq發送一條消息，而後經過activemq將消息發送給消息的消費端，消費端接收到消息能夠進行相應的業務處理。

activeMQ若是數據提交不成功怎麼辦？

Activemq有兩種通訊方式，點到點形式和發佈訂閱模式。若是是點到點模式的話，若是消息發送不成功此消息默認會保存到activemq服務端知道有消費者將其消費，因此此時消息是不會丟失的。
若是是發佈訂閱模式的通訊方式，默認狀況下只通知一次，若是接收不到此消息就沒有了。這種場景只適用於對消息送達率要求不高的狀況。若是要求消息必須送達不能夠丟失的話，須要配置持久訂閱。每一個訂閱端定義一個id，在訂閱是向activemq註冊。發佈消息和接收消息時須要配置發送模式爲持久化。此時若是客戶端接收不到消息，消息會持久化到服務端，直到客戶端正常接收後爲止。

當被問到某個模快存在安全性問題（sso單點登陸系統）時，如何回答？

目前淘淘商城的sso系統的解決方案中直接把token保存到cookie中，確實存在安全性問題。可是實現簡單方便。若是想提升安全性可使用cas框架實現單點登陸。
https://www.apereo.org/projects/cas

業務如何說？先說業務、說表、說具體實現？

先說整體的業務流程，而後再說具體業務的實現方法及使用的技術。最後說你在系統中負責的內容。不須要說表結構。

你作過電商項目，那麼你說說sku的幾種經常使用設計方法，大家的sku是怎麼設計的？
SKU屬性的設計，能夠分爲兩類：
1）經過屬性集關聯SKU屬性
　　適合品類較少的網站，管理容易些。
    如麥包包等專賣箱包或者服飾類的網站。通常就是顏色+尺碼兩種。並且因爲品類不多，爲了方便管理，能夠將SKU屬性歸入到屬性
集中管理，這樣產品關聯了屬性集後，天然就關聯了普通屬性、查詢屬性、SKU屬性和評論屬性了。
若是該網站產品種類不多，好比只賣服裝，那麼能夠作進一步的簡化，即直接將SKU屬性從屬關聯屬性集，去掉」屬性集關聯SKU「。

     基於本設計的管理方式：
     按品類建立屬性集，如箱包、鞋子、服裝、文胸等。而後建立多個SKU屬性，即便針對內涵類似的，可是可選項不一樣的也建立
多個，如尺碼，用在箱包和用在服裝上是徹底不一樣的。這些分別建立，並
      產品建立時，關聯一個屬性集，經過屬性集關聯了1~N個SKU屬性，而後選項這些SKU屬性的組合，如2個顏色*3個尺碼，即6個組合，而後能夠根據須要刪除不支持的組合，這樣最終得出了一個組合列表，點擊」生成SKU「，就根據組合數量建立了產品
SKU，每一個產品SKU對應一個組合，存儲在產品SKU選項值表中。對於某些SKU，能夠設置專門的選項配圖。

2）產品和SKU屬性直接關聯

      適合品類不少網站，比較靈活，可是維護起來數據量比較大。
      爲了簡化，我增長SKU屬性關聯產品分類（可爲空，表示是全局的），這樣在建立產品時，能夠只列出全局的+本產品分類的SKU屬性，這樣就不會一會兒列出不少SKU屬性了。SKU屬性分爲前端名稱和後臺名稱兩個，方便不一樣業務含義的SKU屬性，在前端也可以用同一個名稱顯示，如顏色、容量等。另外在操做上能夠作些優化，好比用下拉列表顯示可選的SKU屬性時，能夠同時顯示該屬性的屬性描述，供產品維護人員參考。
基於SKU方式來管理產品時，產品的價格、庫存和圖片等信息必然是放在產品SKU表中處理的，和訂單、購物車等表的關聯，也是經過產品SKU表，而不是產品表。至於產品表，其實是一個總的業務彙總和外部關聯表，但實際銷售的並非它。咱們網站作的更細些，會就每一個產品SKU生成獨立的URL（僞靜態），但從SEO方面考慮，每一個產品SKU擁有獨立

單點登陸具體實現了什麼功能？
1. 去登錄頁面
2. 提交登錄頁面
3. 用戶名、密碼、驗證碼的校驗
4. 錯誤信息的回顯
5. 保存用戶到Session中
6. 重定向到登錄以前的訪問頁面
7. Ajax跨域判斷用戶是否登錄

Redis在其中是怎麼用的？起了什麼做用？
redis中存儲的都是key-value格式的。拿商品數據來講，key就是商品id，value是商品相關信息的json數據。
在商城系統中當併發量比較高，頻繁的對數據庫進行讀操做的時候都須要添加緩存。例如頁面中內容數據的緩存、商品數據的緩存以及用戶數據的緩存等。
作商品數據的緩存時，由於商品的數據量很大，並且緩存是把數據保存到內存中，此時不可能把全部的商品數據都放到緩存中。因此須要設置商品數據緩存的有效期，當用戶訪問到非熱點數據後，此數據放到緩存中，當緩存到期後就從緩存中刪除，並且長時間不會添加到緩存。而熱點數據一旦從緩存中刪除會立刻又添加到緩存。這樣能夠提升緩存的利用率，同時也減輕了數據庫的壓力。

插入商品的話，要求級聯插入幾張表，大家當時是怎麼實現的？
經過Redis生成商品編號（ID）
保存商品表
再保存Sku表（此表中外鍵，是商品表的ID）