電商面試題100問

項目週期?
答:項目週期爲3-4個月。前端

項目團隊有多少人,如何分配的?
答:項目團隊通常由6-10我的組成,4-5我的是java後臺的,1-2個是前端,2個產品。java

在項目中充當什麼樣的角色?
答:在項目中的職位是組員或者組長,主要負責開發功能模塊,後期配合測試修改bug。
看工做時間與入職的時間,在一家公司入職時間少於1年而且從事開發少於2年不多有機會擔任小組領導node

項目中遇到的最大的問題是什麼?
答:這種問題不要說通常的錯誤,儘可能說業務上的問題。例如:單點登陸的時候如何解決多系統之間用戶登陸信息同步以及用戶信息共享;登陸須要發送短信驗證碼的時候如何保證消息到達率是100%;如何實現redis與數據庫信息同步;開發環境程序正常,生產環境程序bug等。mysql

如何保證所負責與需求相符合?
答:在作模塊以前,與產品經理肯定好需求,再與項目負責人肯定好技術選型應用,在開發過程當中遇到業務問題與產品經理和項目負責人及時溝通。nginx

你以爲作商品模塊(首頁展現、輪播圖、購物車、單點登陸、訂單)時的難點在哪裏?
答:商品模塊:添加或者修改商品時,數據庫、redis、靜態頁面如何同步信息。
購物車:添加的商品數量與庫存數量的對比。商品價格變更同步。購物車的存儲。
單點登陸:如何進行多系統之間的信息交互。(主要指驗證登陸信息)子系統如何保證登陸信息的安全。
訂單:商品數量與庫存的同步,商品價格的準確性。提交訂單的方式,如何驗證訂單。web

所負責模塊裏有哪些功能?(不要上來就說增刪改查)
答:商品模塊的功能:添加商品時,商品圖片的上傳以及存儲,商品價格確保準確性,商品的上下架。也能夠簡單介紹下查詢的各類條件或刪除的各類條件。以及商品信息同步(數據庫、redis、靜態頁面等),商品id的生成規則。面試

在項目開發過程當中遇到不會的功能是如何處理的?
答:技術問題:首先是谷歌,在網上查看各類資料以及博客。其次是與同事交流。最後再去找領導。
業務問題:業務問題首先找經理溝通,技術問題首先google百度ajax

項目中前臺與後臺是如何進行數據交互的?
答:ajax,http請求,socket。redis

如何實現數據庫與redis同步?
答:用消息隊列mq實現。具體操做是在添加或者修改數據的時候,用mq來同步到數據庫與redis,加上事務,確保reids與數據庫數據一致。spring

在項目開發過程當中還有哪些工做內容?
答:與項目經理去客戶公司肯定用戶需求,與同事配合完成單元測試,與測試人員配合完成測試並修改bug,bug提交

項目共有多少張表?所作模塊用到多少張表?表與表之間的關係?
答:180-220(選一個具體數值)。
商品模塊:商品表,庫存表,品牌表,分類表,商品詳情表,規格表,圖片表,商品排序表,商品篩選表,圖片資源類型表,圖片資源表,商品日誌表,曬單圖片說明表。
購物車:商品表,品牌表,分類表,庫存表,用戶表,庫房表,購物車表,購物項表,優惠券表,商品推薦表。
訂單:訂單表,用戶表,用戶地址表,商品表,品牌表,分類表,庫存表,庫房表,地區表,物流信息表。
登陸(後臺):用戶表,權限表,角色表,用戶角色表,權限角色表,日誌表。

插入商品的話,要求級聯插入幾張表,大家當時是怎麼實現的?

答:商品表,商品詳情表,庫存表,圖片表,日誌表。

項目中用的註解開發仍是手動注入?分別如何實現?爲何?

答:註解開發,在類、屬性、方法上寫註解。由於項目中須要配置的太多,用註解能夠簡化開發。
1.
錯誤日誌的處理?項目中的日誌文件存在哪裏?保存多長時間?

答:看日誌大小存放, 通常是15天或者30天。存放在一個單獨的服務器目錄。
1.
生產環境與開發環境在上線部署的時候應該如何配置?

答:生產環境:
一、上線以前備份以前的項目
二、修改上線項目的相關配置
三、關停服務
四、替換以前的項目
五、啓動服務,觀察日誌,是否異常
1.
開發時數據庫中數據從哪來?數據量有多大?

答:開發時數據庫數據部分來自客戶或者運營,部分本身添加,部分來自網絡爬蟲扒的數據。
1.
如何保證庫存?

答:用mq+redis。
1.
若是日誌存儲量過大如何處理?

答:按期清除日誌,日誌通常存放在另外一臺服務器上,15-30天清理一次。
1.
在項目開發過程當中如何進行測試?壓力測試如何作?

答:對本身所負責模塊進行單元測試,而後交給公司測試人員進行測試。通常壓力測試都是測試人員作,Visual
Studio 自帶的工具,還有Loader
Runner(LR),輕量級的工具備Apache項目中的ApacheBench。
1.
項目的併發量有多大?用了多少臺服務器?

答:併發量500-1000,服務器數量通常是10-20臺左右,具體數量看圖

{width=」6.393055555555556in」
height=」3.770138888888889in」}
1.
在項目中,是如何分配開發任務的?

答:開會時,由項目經理與組長分配到我的須要負責開發的功能模塊。
1.
項目中的技術選型的依據是什麼?

答:1.什麼技術更適合當前項目的業務需求,例如互聯網項目查詢條件比較多,數據庫框架選用mybatis;傳統項目查詢條件比較單一,選用hibernate比較合適。
2.若是兩個技術都適用於項目,就看架構師更熟悉哪一個技術,由於若是大部分開發人員都不會,企業會負擔很高的學習成本。
1.
項目的安全問題是如何解決的?

答:單點登陸用token來校驗。或者能夠說有專門負責項目安全的人員。或者說花錢買服務。
環境安全:初期經過購買雲服務
程序安全;token +簽名
1.
用戶分爲幾種?每種所對應的權限?權限具體是如何實現的?

答:通常後天項目中普通用戶、普通管理員、超級管理員。用shiro框架具體實現。
普通用戶:訪問。普通管理員:管理後臺信息。超級管理員:全部權限。
1.
電商項目是否上線?用戶量有多少?

答:能夠說上線(找一個地方性的小型電商網站)或者測試沒有完成,項目尚未上線。能夠說用戶量有日活量:幾千。
1.
商品的屬性是如何進行存儲的?

答:須要存儲到商品表,商品詳情表,庫存表,日誌表等。
1.
工做之餘有沒有在研究一些流行的技術?

答:有,再看一些技術博客。好比說跨域,如何解決高併發,不一樣系統之間的通訊。
1.
在項目中如何實現頁面跳轉並把當前頁面數據傳遞到跳轉頁面?

答:把要傳遞的數據放在request域中(轉發)。
1.
所負責模塊的查詢都有那些條件?那些是靜態條件、哪些是動態條件?

答:商品的價格區間,商品的品牌,商品的分類,型號,顏色,大小,男/女,商品名稱。
靜態條件:商品的價格區間,商品的品牌,商品的分類,型號,顏色,大小,男/女
動態條件:商品名稱,商品類型
1.
所負責模塊中刪除數據的時候直接刪除就能夠麼?若是不是須要作哪些操做?

答:若是單表的能夠進行邏輯刪除,不會進行物理刪除。級聯刪除,刪除該條數據不影響到其餘表中的數據就能夠直接刪除,不然要進行級聯刪除,這裏也是指的邏輯刪除。
1.
支付是如何作的?

答:與支付寶、微信對接,下載它 們兩個的SDK(jar包),須要配置公鑰與私鑰,進行對接,根據官方文檔的API,調用相關支付的藉口,接收回調信息(成功或失敗)。進一步作本身的業務邏輯操做。
1.
表是如何設計的?

答:能夠說是項目經理或者架構師設計的。本身所負責模塊能夠根據項目需求來設計有哪些字段,須要關聯到哪些表。儘可能推行單表設計,不定義外鍵約束。
1.
面向服務經過什麼樣的方式實現?

答:soa架構,表現層與服務層分離,用dubbo和zookeeper搭配完成。
1.
如何提升代碼質量?在項目中如何優化代碼?

答:儘可能減小沒必要要的操做,儘可能不要用到三層以上的for循環與遞歸。寫代碼的時候要給關鍵代碼寫上註釋。相同功能的代碼進行抽取,抽取原則不影響功能的正常運行。
1.
商品的審覈如何作的?

答:添加或者修改,商品的價格以及庫存等重要信息要進行二次填寫,以保證準確率。
前臺js校驗,後臺java代碼校驗。
1.
在項目中如何調試bug?

答:1.以dug方式運行項目,打斷點調試。2.查看項目中的錯誤日誌。3.測試人員使用專業測試工具進行測試。4.運行腳本對代碼進行測試。
1.
查詢商品的時候若是redis沒有數據,能夠拋異常麼?若是不能夠如何作?

答:不能夠用throws拋異常,能夠用trycatch捕獲異常。由於在redis中查詢不到數據,還要對數據庫進行查詢,若是throws拋異常則不能按正常業務運行。
1.
購物車如何實現的?未登陸能夠用購物車麼?購物車的存儲?

答:購物車有三種。1.存放在Cookie。2.放在緩存裏面。3.放到數據庫裏面。
未登陸的時候能夠放在cookie中,可是有的電商網站針對未登陸用戶不提供購物車功能。(例如天貓、淘寶添加商品到購物車的時候必須先登陸)
1.
購物車裏面商品種類能夠無限添加麼?同一種商品的數量有限制麼?

答:不能夠,京東最多隻能夠添加八十種(足夠使用了),避免佔用太多存儲空間;商品數量根據商品類型來控制,通常不超過200種。
1.
若是庫存數量少於購物車用戶添加的數量如何處理?

答:每次用戶訪問購物車的時候,都發送ajax請求查詢一遍redis或者數據庫,若是存庫數量少於購物車中商品數量,發送消息進行提示,並作相應修改。
1.
生成訂單具有的條件?如何保證這些條件?

答:商品數量不能超過限制數量和庫存數量。限制數量在前臺用js校驗,後臺查詢數據庫校驗庫存。
1.
首頁展現的輪播圖,在頁面中是如何存放的?在數據庫中是如何存放的?

答:頁面中存放的是圖片地址,在數據庫中存放的也是圖片的地址。圖片存放在另外一臺服務器上面。
1.
用戶地址是如何保存實現的?(具體)

答:用戶的地址是單獨存放在一張數據庫表中的,須要綁定用戶的id,還須要設置默認路徑。
1.
在電商項目中如何針對不一樣的用戶作推送?

答:對用戶的瀏覽內容作一下記錄,而後在頁面的下方或者右方作商品的推送。還有一種就是針對用戶購物車或者關注商品作促銷信息推送。
1.
如何遷移數據庫(mysql)?

答:這裏介紹的是mysql數據庫,若是被問到其餘的能夠說只知道mysql的。
1.數據庫直接導出,拷貝文件到新服務器,在新服務器上導入。
2.使用【MySQL GUI Tools】中的 MySQLMigrationTool。
3.數據文件和庫表結構文件直接拷貝到新服務器,掛載到一樣配置的MySQL服務下。

我在個人電腦上用虛擬機測試後,選中了佔用時間最少的第三種方案。下面是三種方案的對比:第一種方案的優勢:會重建數據文件,減小數據文件的佔用空間。\

第一種方案的缺點:時間佔用長。(導入導出都須要很長的時間,而且導出後的文件還要通過網絡傳輸,也要佔用必定的時間。)

第二種方案的優勢:設置完成後傳輸無人值守\

第二種方案的缺點:設置繁瑣。傳輸中網絡出現異常,不能及時的被發現,而且會一直停留在數據傳輸的狀態不能被中止,如不仔細觀察不會被發現異常。 傳輸相對其餘fang時間長。 異常後很難從異常的位置繼續傳輸。

第三種方案的優勢:時間佔用短,文件可斷點傳輸。操做步驟少。(絕大部分時間都是在文件的網絡傳輸)
第三種方案的缺點:可能引發未知問題,暫時未發現。
1.
服務器宕機如何處理?所有宕機如何處理?

答:配置主從服務器,運維人員搭建集羣后,從服務器會給主服務器發送信息,若是主服務器沒有響應,那就啓用從服務器。通常不會所有宕機,若是所有掛掉,就重啓。
1.
一件商品只有2件,如今被他人購買一件,這邊如何修改當前用戶的商品信息?

答:這個考察的是對庫存的安全校驗。商品上架多少 庫存 講庫存緩存在redis 中 下單 就在redis 減小,異步 在庫存數據庫中也減小商品 查詢只查詢redis 中的 商品庫存更新後 更新redis 庫存;在用戶點擊添加到購物車按鈕時,發送ajax查詢redis。
dubbo服務開發流程,運行流程?zookeeper註冊中心的做用?端口是多少?
答:dubbo主要是發佈服務和調用服務。
使用流程:
第一步:要在系統中使用dubbo應該先搭建一個註冊中心,通常推薦使用zookeeper。
第二步:有了註冊中心而後是發佈服務,發佈服務須要使用spring容器和dubbo標籤來發布服務。而且發佈服務時須要指定註冊中心的位置。
第三步:服務發佈以後就是調用服務。通常調用服務也是使用spring容器和dubbo標籤來引用服務,這樣就能夠在客戶端的容器中生成一個服務的代理對象,在action或者Controller中直接調用service的方法便可。
Zookeeper註冊中心的做用主要就是註冊和發現服務的做用。相似於房產中介的做用,在系統中並不參與服務的調用及數據的傳輸。
1.
消息中間件acitveMQ的做用、原理?幾種模式,每種的特色及使用問題?MQ發送消息失敗怎麼辦?

答:Activemq的做用就是系統之間進行通訊。固然可使用其餘方式進行系統間通訊,若是使用Activemq的話能夠對系統之間的調用進行解耦,實現系統間的異步通訊。原理就是生產者生產消息,把消息發送給activemq。Activemq接收到消息,而後查看有多少個消費者,而後把消息轉發給消費者,此過程當中生產者無需參與。消費者接收到消息後作相應的處理和生產者沒有任何關係。
Activemq有兩種通訊方式,點到點形式和發佈訂閱模式。若是是點到點模式的話,若是消息發送不成功此消息默認會保存到activemq服務端知道有消費者將其消費,因此此時消息是不會丟失的。若是是發佈訂閱模式的通訊方式,默認狀況下只通知一次,若是接收不到此消息就沒有了。這種場景只適用於對消息送達率要求不高的狀況。若是要求消息必須送達不能夠丟失的話,須要配置持久訂閱。每一個訂閱端定義一個id,在訂閱是向activemq註冊。發佈消息和接收消息時須要配置發送模式爲持久化。此時若是客戶端接收不到消息,消息會持久化到服務端,直到客戶端正常接收後爲止。
1.
Tomcat集羣中怎麼實現共享

答:用dubbo與zookeeper配合來實現tomcat共享。
1,tomcat自身提供的session集羣共享
2,編寫tomcat的session插件對session進行存儲
3,使用javaweb規範中的filter對request對象的getSessio()進行攔截替換實現集羣共享

1.

Shiro如何進行權限控制?

答:1.經過瀏覽器訪問路徑,配置文件查看,是否須要認證等,若是不須要,直接訪問controller
2.若是須要認證,經過配置文件的loginUrl,跳到這個地址,輸入用戶名、密碼等
3.登陸:1.訪問自定義的form表單過濾器FormAuthenticationFilter(本身起的名字和shiro同樣了,因此。。)的createToken方法,裝配token;若是沒有自定義表單過濾器,默認的FormAuthenticationFilter會自動裝配表單token2.訪問自定義realms的認證方法doGetAuthenticationInfo(),查庫(或者緩存),判斷用戶名和密碼是否正確。
4.若是登陸以後訪問的url,經過配置文件裏的配置須要權限:調用自定義realms的受權方法:doGetAuthorizationInfo(),查庫(或者緩存),查出用戶權限,判斷是否擁有權限,沒權訪問,跳到響應的refuse配置的路徑,有權訪問,跳到響應的url
1.
solr的原理?分詞器的原理?如何設置高亮顯示?

答:Solr是基於Lucene開發的全文檢索服務器,而Lucene就是一套實現了全文檢索的api,其本質就是一個全文檢索的過程。全文檢索就是把原始文檔根據必定的規則拆分紅若干個關鍵詞,而後根據關鍵詞建立索引,當查詢時先查詢索引找到對應的關鍵詞,並根據關鍵詞找到對應的文檔,也就是查詢結果,最終把查詢結果展現給用戶的過程。
IK分析器的分詞原理本質上是詞典分詞。如今內存中初始化一個詞典,而後在分詞過程當中逐個讀取字符,和字典中的字符相匹配,把文檔中的全部的詞語拆分出來的過程。
1.
秒殺功能可否與正常的商品購買放在同一臺服務器上?

答:能夠,可是儘可能不要這麼作。由於秒殺商品,搶購的用戶會比較多,併發量太高容易引發宕機,致使正常購買商品功能也不能正常使用,因此建議放在不一樣服務器上。
1.
redis是內存數據庫,若是宕機了,如何解決數據丟失的問題?

答:方案一:redis擁有兩種不一樣形式的持久化方法,它們均可以用小而緊湊的格式將存儲在內存中的數據寫入硬盤:第一種持久化方法爲時間點轉儲,轉儲操做既能夠在「指定時間段內有指定數量的寫操做執行」這一條件被知足時執行,又能夠經過條用兩條轉儲到硬盤中命令中的任何一條來執行;第二種持久化方法將全部修改了數據庫的命令都寫入一個只追加文件裏面,用戶能夠根據數據的重要程度,將只追加寫入設置爲從不一樣步、每秒同步一次或者每寫入一個命令就同步一次。
方案二:使用redis集羣。Redis實現了主從複製的特性:執行復制的從服務器會鏈接上主服務器,接受主服務器發送的整個數據庫的初始副本;以後主服務器執行的寫命令,都會被髮送給全部鏈接着的從服務器去執行,從而實時地更新從服務器的數據集。由於從服務器包含的數據會不斷地進行更新,因此客戶端能夠向任意一個從服務器發送讀請求,以此來避免對主服務器進行集中式的訪問。
1.
商品存入數據庫怎麼保證數據庫數據安全?

答:設置後臺用戶的權限,並對數據庫修改作好記錄(日誌),保證責任到人。
1.
項目中商品小圖片點開後,單品頁面是大圖片,這些圖片是如何處理的?

答:在小圖片上設置鏈接,點擊小圖片後,加載大圖片。
什麼是負載均衡高可用
nginx做爲負載均衡器,全部請求都到了nginx,可見nginx處於很是重點的位置,若是nginx服務器宕機後端web服務將沒法提供服務,影響嚴重。
爲了屏蔽負載均衡服務器的宕機,須要創建一個備份機。主服務器和備份機上都運行高可用(High Availability)監控程序,經過傳送諸如「I am alive」這樣的信息來監控對方的運行情況。當備份機不能在必定的時間內收到這樣的信息時,它就接管主服務器的服務IP並繼續提供負載均衡服務;當備份管理器又從主管理器收到「I am alive」這樣的信息時,它就釋放服務IP地址,這樣的主服務器就開始再次提供負載均衡服務。

什麼是FastDFS
FastDFS是用c語言編寫的一款開源的分佈式文件系統。FastDFS爲互聯網量身定製,充分考慮了冗餘備份、負載均衡、線性擴容等機制,並注重高可用、高性能等指標,使用FastDFS很容易搭建一套高性能的文件服務器集羣提供文件上傳、下載等服務。

(搜索)

solr怎麼設置搜索結果排名靠前(得分)?
能夠設置文檔中域的boost值,boost值越高計算出來的相關度得分就越高,排名也就越靠前。此方法能夠把熱點商品或者是推廣商品的排名提升。

elsticsearch

一、elasticsearch瞭解多少,說說大家公司es的集羣架構,索引數據大小,分片有多少,以及一些調優手段 。
解答:
如實結合本身的實踐場景回答便可。
好比:ES集羣架構13個節點,索引根據通道不一樣共20+索引,根據日期,每日遞增20+,索引:10分片,每日遞增1億+數據,
每一個通道天天索引大小控制:150GB以內。
僅索引層面調優手段:
1.一、設計階段調優

1)根據業務增量需求,採起基於日期模板建立索引,經過roll over API滾動索引;
2)使用別名進行索引管理;
3)天天凌晨定時對索引作force_merge操做,以釋放空間;
4)採起冷熱分離機制,熱數據存儲到SSD,提升檢索效率;冷數據按期進行shrink操做,以縮減存儲;
5)採起curator進行索引的生命週期管理;
6)僅針對須要分詞的字段,合理的設置分詞器;
7)Mapping階段充分結合各個字段的屬性,是否須要檢索、是否須要存儲等。 …

1.二、寫入調優

1)寫入前副本數設置爲0;
2)寫入前關閉refresh_interval設置爲-1,禁用刷新機制;
3)寫入過程當中:採起bulk批量寫入;
4)寫入後恢復副本數和刷新間隔;
5)儘可能使用自動生成的id。

1.三、查詢調優

1)禁用wildcard;
2)禁用批量terms(成百上千的場景);
3)充分利用倒排索引機制,能keyword類型儘可能keyword;
4)數據量大時候,能夠先基於時間敲定索引再檢索;
5)設置合理的路由機制。

二、elasticsearch的倒排索引是什麼?
面試官:想了解你對基礎概念的認知。
解答:通俗解釋一下就能夠。
傳統的咱們的檢索是經過文章,逐個遍歷找到對應關鍵詞的位置。
而倒排索引,是經過分詞策略,造成了詞和文章的映射關係表,這種詞典+映射表即爲倒排索引。
有了倒排索引,就能實現o(1)時間複雜度的效率檢索文章了,極大的提升了檢索效率。

學術的解答方式:

倒排索引,相反於一篇文章包含了哪些詞,它從詞出發,記載了這個詞在哪些文檔中出現過,由兩部分組成——詞典和倒排表。

加分項:倒排索引的底層實現是基於:FST(Finite State Transducer)數據結構。
lucene從4+版本後開始大量使用的數據結構是FST。FST有兩個優勢:

1)空間佔用小。經過對詞典中單詞前綴和後綴的重複利用,壓縮了存儲空間;
2)查詢速度快。O(len(str))的查詢時間複雜度。

三、elasticsearch 索引數據多了怎麼辦,如何調優,部署?
面試官:想了解大數據量的運維能力。
解答:索引數據的規劃,應在前期作好規劃,正所謂「設計先行,編碼在後」,這樣纔能有效的避免突如其來的數據激增致使集羣處理能力不足引起的線上客戶檢索或者其餘業務受到影響。
如何調優,正如問題1所說,這裏細化一下:

四、elasticsearch是如何實現master選舉的?
解答:
前置前提:

1)只有候選主節點(master:true)的節點才能成爲主節點。
2)最小主節點數(min_master_nodes)的目的是防止腦裂。

這個我看了各類網上分析的版本和源碼分析的書籍,雲裏霧裏。
覈對了一下代碼,核心入口爲findMaster,選擇主節點成功返回對應Master,不然返回null。選舉流程大體描述以下:

第一步:確認候選主節點數達標,elasticsearch.yml設置的值discovery.zen.minimum_master_nodes;
第二步:比較:先斷定是否具有master資格,具有候選主節點資格的優先返回;若兩節點都爲候選主節點,則id小的值會主節點。注意這裏的id爲string類型。

五、詳細描述一下Elasticsearch搜索的過程?
面試官:想了解ES搜索的底層原理,再也不只關注業務層面了。
解答:
搜索拆解爲「query then fetch」 兩個階段。
query階段的目的:定位到位置,但不取。
步驟拆解以下:

1)假設一個索引數據有5主+1副本 共10分片,一次請求會命中(主或者副本分片中)的一個。
2)每一個分片在本地進行查詢,結果返回到本地有序的優先隊列中。
3)第2)步驟的結果發送到協調節點,協調節點產生一個全局的排序列表。

fetch階段的目的:取數據。
路由節點獲取全部文檔,返回給客戶端。
六、Elasticsearch在部署時,對Linux的設置有哪些優化方法?
面試官:想了解對ES集羣的運維能力。
解答:

1)關閉緩存swap;
2)堆內存設置爲:Min(節點內存/2, 32GB);
3)設置最大文件句柄數;
4)線程池+隊列大小根據業務須要作調整;
5)磁盤存儲raid方式——存儲有條件使用RAID10,增長單節點性能以及避免單節點存儲故障。

七、lucence內部結構是什麼?
解答:

Lucene是有索引和搜索的兩個過程,包含索引建立,索引,搜索三個要點。能夠基於這個脈絡展開一些。

什麼是sso系統
單點登陸是在多個應用系統中,用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。
登陸的處理流程:
一、登陸頁面提交用戶名密碼。
二、登陸成功後生成token。Token至關於原來的jsessionid,字符串,可使用uuid。
三、把用戶信息保存到redis。Key就是token,value就是TbUser對象轉換成json。
四、使用String類型保存Session信息。可使用「前綴:token」爲key
五、設置key的過時時間。模擬Session的過時時間。通常半個小時。
六、把token寫入cookie中。
如何判斷是否登陸
1.從cookie中取token
2.取不到未登陸
3.取到token,到redis中查詢token是否過時
4.若是過時,爲登陸狀態
5.沒有過時,登陸狀態

實現購車商品數據同步
一、要求用戶登陸。
二、把購物車商品列表保存到數據庫中。推薦使用redis。
三、Key:用戶id,value:購車商品列表。推薦使用hash,hash的field:商品id,value:商品信息。
四、在用戶未登陸狀況下寫cookie。當用戶登陸後,訪問購物車列表時,
a)把cookie中的數據同步到redis。
b)把cookie中的數據刪除
c)展現購物車列表時以redis爲準。
d)若是redis中有數據cookie中也有數據,須要作數據合併。相同商品數量相加,不一樣商品添加一個新商品。
五、若是用戶登陸狀態,展現購物車列表以redis爲準。若是未登陸,以cookie爲準。

瀏覽器跨域問題
跨域是指從一個域名的網頁去請求另外一個域名的資源。瀏覽器出於安全的考慮,不容許不一樣源的請求
JSONP解決AJAX跨域問題:
JSONP是服務器與客戶端跨源通訊的經常使用方法。最大特色就是簡單適用,老式瀏覽器所有支持,服務器改造很是小。
它的基本思想是,網頁經過添加一個

海量數據的存儲問題
現在隨着互聯網的發展,數據的量級也是呈指數的增加,從GB到TB到PB。對數據的各類操做也是越發的困難,傳統的關係性數據庫已經沒法知足快速查詢與插入數據的需求。這個時候NoSQL的出現暫時解決了這一危機。它經過下降數據的安全性,減小對事務的支持,減小對複雜查詢的支持,來獲取性能上的提高。
可是,在有些場合NoSQL一些折衷是沒法知足使用場景的,就好比有些使用場景是絕對要有事務與安全指標的。這個時候NoSQL確定是沒法知足的,因此仍是須要使用關係性數據庫。若是使用關係型數據庫解決海量存儲的問題呢?此時就須要作數據庫集羣,爲了提升查詢性能將一個數據庫的數據分散到不一樣的數據庫中存儲。

什麼是數據庫分片
簡單來講,就是指經過某種特定的條件,將咱們存放在同一個數據庫中的數據分散存放到多個數據庫上面,以達到分散單臺設備負載的效果。
數據的切分(Sharding)根據其切分規則的類型,能夠分爲兩種切分模式。
1.一種是按照不一樣的表來切分到不一樣的數據庫(主機)之上,這種切能夠稱之爲數據的垂直切分
2.另一種則是根據表中的數據的邏輯關係,將同一個表中的數據按照某種條件拆分到多臺數據庫上面,這種切分稱之爲數據的水平切分。

如何實現數據庫分片
當數據庫分片後,數據由一個數據庫分散到多個數據庫中。此時系統要查詢時須要切換不一樣的數據庫進行查詢,那麼系統如何知道要查詢的數據在哪一個數據庫中?當添加一條記錄時要向哪一個數據庫中插入呢?這些問題處理起來都是很是的麻煩。
這種狀況下可使用一個數據庫中間件mycat來解決相關的問題。

什麼是Mycat?
簡單的說,MyCAT就是:一個新穎的數據庫中間件產品,支持mysql集羣,提供高可用性數據分片集羣。你能夠像使用mysql同樣使用mycat。對於開發人員來講根本感受不到mycat的存在。
Mycat讀寫分離
數據庫讀寫分離對於大型系統或者訪問量很高的互聯網應用來講,是必不可少的一個重要功能。對於MySQL來講,標準的讀寫分離是主從模式,一個寫節點Master後面跟着多個讀節點,讀節點的數量取決於系統的壓力,一般是1-3個讀節點的配置

電商活動倒計時方案(秒殺方案):
一、肯定一個基準時間。可使用一個sql語句從數據庫中取出一個當前時間。SELECT NOW();
二、活動開始的時間是固定的。
三、使用活動開始時間-基準時間能夠計算出一個秒爲單位的數值。
四、在redis中設置一個key(活動開始標識)。設置key的過時時間爲第三步計算出來的時間。
五、展現頁面的時候取出key的有效時間。Ttl命令。使用js倒計時。
六、一旦活動開始的key失效,說明活動開始。
七、須要在活動的邏輯中,先判斷活動是否開始。
秒殺方案:
八、把商品的數量放到redis中。
九、秒殺時使用decr命令對商品數量減一。若是不是負數說明搶到。
十、一旦返回數值變爲0說明商品已售完。
因爲宜立方商城是基於SOA的架構,表現層和服務層是不一樣的工程。因此要實現商品列表查詢須要兩個系統之間進行通訊。

如何實現遠程通訊?
一、Webservice:效率不高基於soap協議。項目中不推薦使用。
二、使用restful形式的服務:http+json。不少項目中應用。若是服務太多,服務之間調用關係混亂,須要治療服務。
三、使用dubbo。使用rpc協議進行遠程調用,直接使用socket通訊。傳輸效率高,而且能夠統計出系統之間的調用關係、調用次數。

什麼是dubbo
DUBBO是一個分佈式服務框架,致力於提供高性能和透明化的RPC遠程服務調用方案
Dubbo就是資源調度和治理中心的管理工具。

dubbo服務開發流程,運行流程?zookeeper註冊中心的做用?
使用流程:
第一步:要在系統中使用dubbo應該先搭建一個註冊中心,通常推薦使用zookeeper。
第二步:有了註冊中心而後是發佈服務,發佈服務須要使用spring容器和dubbo標籤來發布服務。而且發佈服務時須要指定註冊中心的位置。
第三步:服務發佈以後就是調用服務。通常調用服務也是使用spring容器和dubbo標籤來引用服務,這樣就能夠在客戶端的容器中生成一個服務的代理對象,在action或者Controller中直接調用service的方法便可。
Zookeeper註冊中心的做用主要就是註冊和發現服務的做用。相似於房產中介的做用,在系統中並不參與服務的調用及數據的傳輸。

電商項目中是如何解決高併發和高可用的?
1.頁面靜態化
2.fastDFS圖片服務器
3.數據緩存服務器
4.數據庫集羣、庫表散列(數據庫的各類優化、數據庫的拆分)
5.負載均衡

什麼是負載均衡
當一臺服務器的單位時間內的訪問量越大時,服務器壓力就越大,大到超過自身承受能力時,服務器就會崩潰。爲了不服務器崩潰,讓用戶有更好的體驗,咱們經過負載均衡的方式來分擔服務器壓力。
咱們能夠創建不少不少服務器,組成一個服務器集羣,當用戶訪問網站時,先訪問一箇中間服務器,在讓這個中間服務器在服務器集羣中選擇一個壓力較小的服務器,而後將該訪問請求引入該服務器。如此以來,用戶的每次訪問,都會保證服務器集羣中的每一個服務器壓力趨於平衡,分擔了服務器壓力,避免了服務器崩潰的狀況。
負載均衡是用反向代理的原理實現的。

redis爲何能夠作緩存?項目中使用redis的目的是什麼?redis何時使用?
1)Redis是key-value形式的nosql數據庫。能夠快速的定位到所查找的key,並把其中的value取出來。而且redis的全部的數據都是放到內存中,存取的速度很是快,通常都是用來作緩存使用。
2)項目中使用redis通常都是做爲緩存來使用的,緩存的目的就是爲了減輕數據庫的壓力提升存取的效率。
3)在互聯網項目中只要是涉及高併發或者是存在大量讀數據的狀況下均可以使用redis做爲緩存。固然redis提供豐富的數據類型,除了緩存還能夠根據實際的業務場景來決定redis的做用。例如使用redis保存用戶的購物車信息、生成訂單號、訪問量計數器、任務隊列、排行榜等。
redis支持五種數據類型存儲:1.字符串2.散列3.列表4.集合5.有序集合(問深一點可能會問道底層數據結構,以及每種數據結構經常使用情景)這裏也能夠列舉一些:

應用場景

計數器
數據統計的需求很是廣泛,經過原子遞增保持計數。例如,點贊數、收藏數、分享數等。
排行榜
排行榜按照得分進行排序,例如,展現 近、 熱、點擊率 高、活躍度 高等等條件的top list。
用於存儲時間戳
相似排行榜,使用redis的zset用於存儲時間戳,時間會不斷變化。例如,按照用戶關注用戶的 新動態列表。記錄用戶斷定信息
記錄用戶斷定信息的需求也很是廣泛,能夠知道一個用戶是否進行了某個操做。例如,用戶是否點贊、用戶是否收藏、用戶是否分享等。
社交列表
社交屬性相關的列表信息,例如,用戶點贊列表、用戶收藏列表、用戶關注列表等。
緩存
緩存一些熱點數據,例如,PC版本文件更新內容、資訊標籤和分類信息、生日祝福壽星列表。
隊列
Redis能做爲一個很好的消息隊列來使用,經過list的lpop及lpush接口進行隊列的寫入和消費,自己性能較好能解決大部分問題。可是,不提倡使用,更加建議使用rabbitmq等服務,做爲消息中間件。
會話緩存 使用Redis進行會話緩存。例如,將web session存放在Redis中。
業務使用方式
String(字符串): 應用數, 資訊數等, (避免了select count(*) from …)
Hash(哈希表): 用戶粉絲列表, 用戶點贊列表, 用戶收藏列表, 用戶關注列表等。
List(列表):消息隊列, push/sub提醒。
SortedSet(有序集合):熱門列表, 新動態列表, TopN, 自動排序。

Redis集羣中,某個節點宕機怎麼辦?你碰見過嗎?你的解決思路是什麼?
redis集羣:通常的是至少是2臺服務器,主從服務器!若是redis集羣的主服務器掛了,沒有關係還有備服務器

(哨兵模式和集羣模式)

中間件問題

AcitveMQ的做用、原理、特色?(生產者。消費者。 p2p、訂閱實現流程)
Activemq的做用就是系統之間進行通訊。固然可使用其餘方式進行系統間通訊,若是使用Activemq的話能夠對系統之間的調用進行解耦,實現系統間的異步通訊。原理就是生產者生產消息,把消息發送給activemq。Activemq接收到消息,而後查看有多少個消費者,而後把消息轉發給消費者,此過程當中生產者無需參與。消費者接收到消息後作相應的處理和生產者沒有任何關係。

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

此處可能會問各類消息中間件的區別以及應用場景,即RabbitMQ、Kafka、RocketMQ之間的區別,以及裏面的組件,好比我遇到過被問到RabbitMQ裏面五種模式的具體寫法與區別

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

單點登陸具體實現了什麼功能?

去登錄頁面
提交登錄頁面
用戶名、密碼、驗證碼的校驗
錯誤信息的回顯
保存用戶到Session中
重定向到登錄以前的訪問頁面
Ajax跨域判斷用戶是否登錄

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

各模塊是怎麼設計的,如商品參數,廣告位等,數據庫設計思路。。。

總的來講調用和設計上的問的較多,以及秒殺,比較多的是細節,好比秒殺中遇到的一些問題,怎麼解決之類的