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）

電商面試問題