企業面試題整理html
淘淘商城前端
1. 淘淘網站併發數：
通過壓力測試能夠支持3000左右的併發，能夠知足目前的業務需求。因爲咱們的系統是分佈式架構，支持水平擴展，若是未來併發量提升的話，能夠增長服務器來提升併發量。mysql
2. 人員配置
產品經理：3人，肯定需求以及給出產品原型圖。面試
項目經理：1人，項目管理。redis
前端團隊：5人，根據產品經理給出的原型製做靜態頁面。spring
後端團隊：20人，實現產品功能。sql
測試團隊：5人，測試全部的功能。數據庫
運維團隊：3人，項目的發佈以及維護。json
3. 開發週期
採用迭代開發的方式進行，通常一次迭代的週期爲一個月左右。後端
4. Sku
最小庫存量單位。
Sku==商品id
5. 你說你用了redis緩存，你redis存的是什麼格式的數據，是怎麼存的
redis中存儲的都是key-value格式的。拿商品數據來講，key就是商品id，value是商品相關信息的json數據。
6. 你前臺portal採用4臺服務器集羣部署，那能前臺高併發訪問性能提上去了，那數據庫會不會形成一個瓶頸，這一塊你是怎麼處理的？
portal系統在高併發的狀況下若是每次請求都請求都查詢數據庫確實會出現數據庫的瓶頸。爲了下降數據庫壓力，在服務層會添加一個緩存，用redis實現，這樣的話請求先到緩存中查找是否有緩存的內容，若是有直接從緩存中取數據，若是沒有再到數據庫中查詢。這樣數據庫的壓力就不會那麼大了。
7. 你購物車存cookie裏邊 能夠實現不登陸就可使用購物車 那麼我如今沒有登陸把商品存購物車了 而後登陸了 而後我換臺電腦而且登陸了還能不能看見我購物車的信息？若是看不到怎麼作到cookie同步，就是在另一臺電腦上能夠看到購物車信息
回答：
淘淘商城現階段使用的僅僅是把購物車的商品寫入cookie中，這樣服務端基本上麼有存儲的壓力。可是弊端就是用戶更換電腦後購物車不能同步。打算下一步這麼實現：當用戶沒有登陸時向購物車添加商品是添加到cookie中，當用戶登陸後購物車的信息是存儲在redis中的而且是跟用戶id向關聯的，此時你更換電腦後使用同一帳號登陸購物車的信息就會展現出來。
8. 若是用戶一直添加購物車添加商品怎麼辦？而且他添加一次你查詢一次數據庫？互聯網上用戶那麼多，這樣會對數據庫形成很大壓力你怎麼辦？
當前咱們使用cookie的方式來保存購物車的數據，因此當用戶往購物車中添加商品時，並不對數據庫進行操做。未來把購物車商品放入redis中，redis是能夠持久化的能夠永久保存，此時就算是頻繁的往購物車中添加數據也沒用什麼問題。
9. 電商活動倒計時方案
一、肯定一個基準時間。可使用一個sql語句從數據庫中取出一個當前時間。SELECT NOW()；
二、活動開始的時間是固定的。
三、使用活動開始時間-基準時間能夠計算出一個秒爲單位的數值。
四、在redis中設置一個key（活動開始標識）。設置key的過時時間爲第三步計算出來的時間。
五、展現頁面的時候取出key的有效時間。Ttl命令。使用js倒計時。
六、一旦活動開始的key失效，說明活動開始。
七、須要在活動的邏輯中，先判斷活動是否開始。
10. 秒殺搶購庫存解決方案
一、把商品的數量放到redis中。
二、秒殺時使用decr命令對商品數量減一。若是不是負數說明搶到。
三、一旦返回數值變爲0說明商品已售完。
11. dubbo服務開發流程，運行流程？zookeeper註冊中心的做用？
使用流程：
第一步：要在系統中使用dubbo應該先搭建一個註冊中心，通常推薦使用zookeeper。
第二步：有了註冊中心而後是發佈服務，發佈服務須要使用spring容器和dubbo標籤來發布服務。而且發佈服務時須要指定註冊中心的位置。
第三步：服務發佈以後就是調用服務。通常調用服務也是使用spring容器和dubbo標籤來引用服務，這樣就能夠在客戶端的容器中生成一個服務的代理對象，在action或者Controller中直接調用service的方法便可。
Zookeeper註冊中心的做用主要就是註冊和發現服務的做用。相似於房產中介的做用，在系統中並不參與服務的調用及數據的傳輸。
12. redis爲何能夠作緩存？項目中使用redis的目的是什麼？redis何時使用？
1）Redis是key-value形式的nosql數據庫。能夠快速的定位到所查找的key，並把其中的value取出來。而且redis的全部的數據都是放到內存中，存取的速度很是快，通常都是用來作緩存使用。
2）項目中使用redis通常都是做爲緩存來使用的，緩存的目的就是爲了減輕數據庫的壓力提升存取的效率。
3）在互聯網項目中只要是涉及高併發或者是存在大量讀數據的狀況下均可以使用redis做爲緩存。固然redis提供豐富的數據類型，除了緩存還能夠根據實際的業務場景來決定redis的做用。例如使用redis保存用戶的購物車信息、生成訂單號、訪問量計數器、任務隊列、排行榜等。
13. acitveMQ的做用、原理？（生產者。消費者。 p2p、訂閱實現流程）
Activemq的做用就是系統之間進行通訊。固然可使用其餘方式進行系統間通訊，若是使用Activemq的話能夠對系統之間的調用進行解耦，實現系統間的異步通訊。原理就是生產者生產消息，把消息發送給activemq。Activemq接收到消息，而後查看有多少個消費者，而後把消息轉發給消費者，此過程當中生產者無需參與。消費者接收到消息後作相應的處理和生產者沒有任何關係。
14. activeMQ在項目中如何應用的？
Activemq在項目中主要是完成系統之間通訊，而且將系統之間的調用進行解耦。例如在添加、修改商品信息後，須要將商品信息同步到索引庫、同步緩存中的數據以及生成靜態頁面一系列操做。在此場景下就可使用activemq。一旦後臺對商品信息進行修改後，就向activemq發送一條消息，而後經過activemq將消息發送給消息的消費端，消費端接收到消息能夠進行相應的業務處理。
15. activeMQ若是數據提交不成功怎麼辦？
Activemq有兩種通訊方式，點到點形式和發佈訂閱模式。若是是點到點模式的話，若是消息發送不成功此消息默認會保存到activemq服務端知道有消費者將其消費，因此此時消息是不會丟失的。
若是是發佈訂閱模式的通訊方式，默認狀況下只通知一次，若是接收不到此消息就沒有了。這種場景只適用於對消息送達率要求不高的狀況。若是要求消息必須送達不能夠丟失的話，須要配置持久訂閱。每一個訂閱端定義一個id，在訂閱是向activemq註冊。發佈消息和接收消息時須要配置發送模式爲持久化。此時若是客戶端接收不到消息，消息會持久化到服務端，直到客戶端正常接收後爲止。
16. 當被問到某個模快存在安全性問題（sso單點登陸系統）時，如何回答？
目前淘淘商城的sso系統的解決方案中直接把token保存到cookie中，確實存在安全性問題。可是實現簡單方便。若是想提升安全性可使用cas框架實現單點登陸。
https://www.apereo.org/projects/cas
17. 當技術面試官問到你某個技術點更深層次研究時，本身沒有深刻了解怎麼回答？
若是沒有深刻研究就直接回答不知道就能夠了。
18. solr怎麼設置搜索結果排名靠前（得分）？
能夠設置文檔中域的boost值，boost值越高計算出來的相關度得分就越高，排名也就越靠前。此方法能夠把熱點商品或者是推廣商品的排名提升。
19. solr的原理
Solr是基於Lucene開發的全文檢索服務器，而Lucene就是一套實現了全文檢索的api，其本質就是一個全文檢索的過程。全文檢索就是把原始文檔根據必定的規則拆分紅若干個關鍵詞，而後根據關鍵詞建立索引，當查詢時先查詢索引找到對應的關鍵詞，並根據關鍵詞找到對應的文檔，也就是查詢結果，最終把查詢結果展現給用戶的過程。
20. solr裏面IK分詞器的原理
IK分析器的分詞原理本質上是詞典分詞。如今內存中初始化一個詞典，而後在分詞過程當中逐個讀取字符，和字典中的字符相匹配，把文檔中的全部的詞語拆分出來的過程。
21. 支付接口是怎麼作的？
面試中能夠說支付這部分不是咱們作的，咱們項目中並無涉及支付部分的處理。若是想了解支付是如何實現能夠參考以前學過的易寶支付相關處理以及支付寶、微信支付相關文檔。
支付寶：
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. 業務如何說？先說業務、說表、說具體實現？
先說整體的業務流程，而後再說具體業務的實現方法及使用的技術。最後說你在系統中負責的內容。不須要說表結構。
23. 單點登陸系統，若是cookie禁用，大家怎麼解決?
若是禁用cookie可使用url中帶參數，把token傳遞給服務端。固然此方法涉及安全性問題，其實在cookie中保存token一樣存在安全性問題。推薦使用sso框架CAS實現單點登陸。
24. 大家作移動端沒有，若是沒有移動端，大家爲何作單點登陸？
單點登陸並非爲移動端準備的，移動端有本身的登陸方式。單點登陸是解決在同一個公司內部多個互信網站之間進行跳轉時不須要屢次登陸，多個系通通一登陸入口。
25. 單點登陸的核心是什麼？
單點登陸的核心是如何在多個系統之間共享身份信息。
26. 除了單點登錄，還作過什麼登錄的方式？
這是什麼狗屁問題？除了單點登陸那就是普通登陸方式，用戶在同一個公司的多個系統之間跳轉時須要屢次登陸。
27. 單點登陸，http無狀態的，別人模仿如何在後端處理
http是無狀態的，若是別人模仿瀏覽器發送http請求，通常後臺是沒法識別的。若是對安全要求高的狀況下應該是https協議。能夠保證在通訊過程當中沒法竊取通訊內容。
28. 安全性問題（別的網站使用爬蟲技術爬你的網站怎麼辦？有沒有安全措施）
單位時間內請求次數超過某個閾值就讓輸入驗證碼，能夠極大下降抓取的速度，若是屢次超過某個閥值能夠加入黑名單。還有就是頁面內容使用json返回，數據常常變一變格式，或者js動態生成頁面內容。
29. 商品存入數據庫怎麼保證數據庫數據安全?
1)對用戶安全管理
用戶操做數據庫時，必須經過數據庫訪問的身份認證。刪除數據庫中的默認用戶，使用自定義的用戶及高強度密碼。
2)定義視圖
爲不一樣的用戶定義不一樣的視圖，能夠限制用戶的訪問範圍。經過視圖機制把須要保密的數據對無權存取這些數據的用戶隱藏起來，能夠對數據庫提供必定程度的安全保護。實際應用中常將視圖機制與受權機制結合起來使用，首先用視圖機制屏蔽一部分保密數據，而後在視圖上進一步進行受權。
3)數據加密
數據加密是保護數據在存儲和傳遞過程當中不被竊取或修改的有效手段。
4)數據庫按期備份
5)審計追蹤機制
審計追蹤機制是指系統設置相應的日誌記錄，特別是對數據更新、刪除、修改的記錄，以便往後查證。日誌記錄的內容能夠包括操做人員的名稱、使用的密碼、用戶的IP地址、登陸時間、操做內容等。若發現系統的數據遭到破壞，能夠根據日誌記錄追究責任，或者從日誌記錄中判斷密碼是否被盜，以便修改密碼，從新分配權限，確保系統的安全。
30. 訂單表的數據量太大,我把訂單分到許多表中,那麼我我想用一條sql查處全部的訂單,怎麼解決?
分庫狀況下：可使用mycat數據庫中間件實現多個表的統一管理。雖然物理上是把一個表中的數據保存到多個數據庫中，可是邏輯上仍是一個表，使用一條sql語句就能夠把數據所有查詢出來。
單庫狀況下：須要動態生成sql語句。先查詢訂單相關的表，而後將查詢多個表的sql語句使用union鏈接便可。
31. 我們單點登陸模塊中，別人僞造咱們cookie中的token怎麼辦？
服務端是沒法阻止僞造cookie的，若是對安全性要求高的話能夠可以使用cas框架。
32. 第一個是當兩個客戶同時買一件商品時庫存只有一個了,怎麼控制?
可使用mysql的行鎖機制，實現樂觀鎖，在更新商品以前將商品鎖定，其餘用戶沒法讀取，當此用戶操做完畢後釋放鎖。當併發量高的狀況下，須要使用緩存工具例如redis來管理庫存。
33. 對數據庫只是採用了讀寫分離,並無徹底解決數據庫的壓力,那麼有什麼辦法解決?
若是數據庫壓力確實很大的狀況下能夠考慮數據庫分片，就是將數據庫中表拆分到不一樣的數據庫中保存。可使用mycat中間件。
34. 同一帳號以客戶端登陸怎麼擠掉另外一端。
用戶登陸後須要在Session中保存用戶的id。當用戶登陸時，從當前全部的Session中判斷是否有此用戶id的存在，若是存在的話就把保存此用戶id的Session銷燬。
35. solr的索引查詢爲何比數據庫要快。
Solr使用的是Lucene API實現的全文檢索。全文檢索本質上是查詢的索引。而數據庫中並非全部的字段都創建的索引，更況且若是使用like查詢時很大的多是不使用索引，因此使用solr查詢時要比查數據庫快。
36. solr索引庫個別數據索引丟失怎麼辦。
首先Solr是不會丟失個別數據的。若是索引庫中缺乏數據，那就向索引庫中添加。（靠！什麼狗屁問題！！！）
37. Lucene索引優化。
直接使用Lucene實現全文檢索已是過期的方案，推薦使用solr。Solr已經提供了完整的全文檢索解決方案。