專案總結

第一天
1、電商行業的背景，b2b、b2c、b2b2c、c2c、o2o2。
2、系統的架構。基於SOA的架構。
3、工程搭建。使用maven管理工程。
4、svn的使用。

第二天
1、ssm框架整合。
2、使用dubbo進行通訊
  1）服務提供者
  2）服務消費者
  3）註冊中心
  4）監控中心
3、商品列表查詢
  1）PageHelper分頁外掛
  2）EasyUI的DataGrid控制元件

第三天
1、商品分類選擇，EasyUI的非同步Tree控制元件。
2、圖片上傳
  1）圖片伺服器FastDFS。tracker、storage
  2）實現圖片上傳使用KindEditor的外掛
3、富文字編輯器。純js實現。textarea控制元件
4、商品新增功能實現。

第四天
1、商城首頁展示。
2、cms系統搭建
  1）內容分類管理
  2）內容管理
3、前臺從資料庫中取內容資訊實現動態展示。

第五天
1、redis的安裝。
2、redis的啟動。
3、redis的5種資料型別。
4、redisCluster
  1）至少有三個節點
  2）JedisCluster物件操作redis叢集
5、向業務邏輯中新增快取。
6、快取同步。刪掉key。

第六天
1、搜尋功能實現，使用solr做搜尋。
2、配置業務域及中文分析器。
3、新的商品資料匯入索引庫。
4、搜尋的實現。

第七天
1、solrCloud
  1）zookeeper叢集(3個)
  2）solr叢集(4個分兩片)
2、使用solrJ連線solr叢集
  1）CloudSolrServer物件連線solr叢集

第八天
1、Activemq，作用是系統之間解耦時使用。實現資料的最終一致。
2、queue點到點、topic廣播
3、Producer
4、Consumer

第九天
1、商品詳情頁面動態展示：jsp+redis
  1）快取設定有效期
2、網頁靜態化
  1）freemarker
  2）建立模板
  3）使用freemarker生成靜態頁面

第十天
1、nginx訪問靜態資源
2、nginx配置虛擬主機
3、nginx實現反向代理
4、nginx實現負載均衡

第十一天
1、sso系統，主要解決分散式環境下Session共享的問題。
2、使用redis儲存Session，設定過期時間。
3、token相當於jsessionid，要儲存到cookie中。

第十二天
1、把購物車儲存到cookie中
2、把購車儲存到服務端redis中

第十三天
1、訂單系統。攔截器，判斷使用者是否登入。
2、訂單確認頁面。收貨地址列表+支付方式列表。
3、生成訂單。訂單號可以使用redis的incr命令生成。

第十四天
  專案部署
  專案總結

專案中的問題

  PS：以下描述若與就業老師所說有衝突，請以就業老師為準，另外參考簡歷一定要改，切不可拿來主義

1、淘淘商城簡歷中的描述
參考簡歷。
  注意：在真實的開發專案中，開發工程師不可能開發所有的模組，只會負責某幾個模組，大家所要描述的是：你所負責的模組（一般3到4個模組）。

2、淘淘網站的併發量
  大概：說5000左右也行。（此處要問怎麼來的，可以說經過壓力測試出來的，自己沒做過，但是知道。有些情況下，並不是所有的事情都是由你來做，由面試官決定用不用你，你把所知道的說清楚就行）可以滿足目前的業務需求。由於我們的系統是分散式架構，支援水平擴充套件，如果將來併發量提高的話，可以增加伺服器來提高併發量。

3、淘淘商城人員的配置
  產品經理：3人，確定需求及給出產品原型圖。
  專案經理：1人，專案管理。
  前端團隊：5人，根據產品經理給出原型製作出靜態頁面（當然也包括UI）。
  後端團端：20人，實現產品的功能（你們就屬於後端團隊）。
  測試團隊：5人，負責測試產品的所有的功能。

4、開發週期
  現在開發採用敏捷開發，快速迭代，開發週期大概6-8個月，後期一般採用迭代的方式開發，一般迭代的週期為一個月左右。（迭代就是所謂的一個小版本的開發）

5、SKU
表示唯一確定唯一的商品的單位（最小庫存單位）SKU==商品ID
例如：對於京東的一款商品：一種顏色，一種配置，一種配送方式，就唯一確定一個商品，這種就叫做一個SKU。
類似於下圖：

6、你說你用了redis，你們redis存的是什麼格式的資料，都是怎麼存的？
  redis中存放資料都是key-value的形式。
  我們商城使用string型別來存放的。拿商品來說：商品的id就是key，商品相關的商品資訊組成一個JSON存放。

7、你前臺系統portal採用4伺服器做叢集部署，前臺系統的併發量提升上去，那對於資料庫會不會造成一個瓶頸，這一塊你們是怎麼處理的？
  portal在高併發的情況下，可以通過部署叢集來提高併發量，這種時候，如果每次都訪問資料，確實會對資料庫造成很大的壓力，那麼這時候，我們就採用在服務層增加快取，使用redis實現，這樣客戶端請求到達時，先從快取中讀取，如果存在資料則直接返回，而不會再從資料庫查詢，如果快取中沒有，則從資料庫查詢，這樣就可減少資料庫的訪問，達到提升資料的訪問瓶頸。

8、購物車存在cookie中，可以實現不登入就可以使用購物車，如果我沒有登入，購買了商品，現在更換了裝置（電腦），那還能不能看到我買的商品？如果看不到怎麼做cookie同步？
  不能；現階段，淘淘商城是採用cookie的方式存放購物車，以減少服務端的儲存壓力。但是弊端就是當更換裝置後將看不到已新增的商品，也就是不能同步商品資訊。
  打算下一步這麼實現：當用戶沒有登入時，商品的資料放入購物車中，將存放於cookie中，此時如果使用者登入，將cookie中的資料存放在redis中，並且是和使用者的ID關聯，並將cookie中的資料刪除。此時如果使用者更換裝置，只要使用同一帳號登入，就可以看到購物車中的商品資訊，就達到了同步cookie的目的。

9、你們商城是通過什麼來做搜尋的？
因為系統要使用站內搜尋功能，資料量很大，需要使用solr。
solr是(基於lucene)搜尋引擎，可以獨立部署，來實現搜尋功能、高亮顯示、效能優化，可以解決高併發的搜尋需求。
  例如：我們系統就是用solr做商品搜尋。–> 怎麼做的呢？
solr是一個伺服器，需要搭建，需要先定義好Field和FieldType，定義中文分詞器，再使用。
通過solr的Java客戶端solrj連線solr服務，它提供豐富的操作索引的方法，可以通過這個客戶端來實現搜尋功能。
  你們索引庫一般有多少資料？答：幾百萬
  如果資料量特別大？怎麼辦？答：做叢集。
  索引庫是如何同步？答：activemq非同步訊息佇列。

10、solr和lucene他們之間有什麼區別？
lucene是一個工具包，類似於一個類庫。
solr是一個基於solr的搜尋引擎，可以獨立執行和部署，它可以通過http請求來索引和搜尋。
  打個比方：solr就相當於一輛汽車，而lucene只是汽車中的引擎，你可以開車，但不開引擎。
另外，使用solr可以獨立部署，擴充套件容易，所以可以最大程度的解耦，而lucene使用需要在業務邏輯中新增程式碼，邏輯耦合度很高，不易維護。

11、你們使用activemq應用在哪種業務場景中，既然都是系統通訊，和其他的系統通訊有什麼區別？
  我們使用activemq應用在生成商品詳情，同步索引庫。activemq是一個訊息中介軟體，非同步傳送訊息，而其他通訊技術：比如dubbo，是同步等待。
  比如：使用activemq在商品服務模組，新增商品並不需要等待索引庫同步完成後才能繼續新增下一個商品，只需要非同步傳送一個訊息告訴索引服務 ，索引服務通過商品ID查詢商品更新索引。
  再有：面試中，要淡定，如果有面試官問：資料庫設計這樣做正確嗎？
  你不清楚的情況下，你就說我們公司就是這麼解決的。其他的我不知道。
  有些面試官，可能他也不知道，他也想知道。

12、電商活動倒計時方案
  1、確定一個基準時間。可以使用一個sql語句從資料庫中取出一個當前時間。SELECT NOW()
  2、活動開始的時間是固定的。
  3、使用活動開始時間減去基準時間可以計算出一個秒為單位的數值。
  4、在redis中設定一個key（活動開始標識）。設定key的過期時間為第三步計算出來的時間。
  5、展示頁面的時候取出key的有效時間。ttl命令。使用js倒計時。
  6、一旦活動開始的key失效，說明活動開始。
  7、需要在活動的邏輯中，先判斷活動是否開始。

13、你們的商城的秒殺方案是什麼？
  1、將商品的數量放入redis中。
  2、秒殺時，可以使用decr命令將商品的數量減一。如果不是負數說明搶到。
  3、如果返回的是負數，說明商品已經搶完。

14、dubbo服務使用流程，執行流程？zookeeper註冊中心的作用？
使用流程：
  第一步：要在系統中使用dubbo應該先搭建一個註冊中心，一般推薦使用zookeeper。
  第二步：有了註冊中心然後是釋出服務，釋出服務需要使用spring容器和dubbo標籤來釋出服務。並且釋出服務時需要指定註冊中心的位置。
  第三步：服務釋出之後就是呼叫服務。一般呼叫服務也是使用spring容器和dubbo標籤來引用服務，這樣就可以在客戶端的容器中生成一個服務的代理物件，在action或者Controller中直接呼叫service的方法即可。
Zookeeper註冊中心的作用：主要就是註冊和發現服務的作用。類似於房產中介的作用，在系統中並不參與服務的呼叫及資料的傳輸。

15、redis為什麼可以做快取？專案中使用redis的目的是什麼？redis什麼時候使用？
  1、Redis是key-value形式的nosql資料庫。可以快速的定位到所查詢的key，並把其中的value取出來。並且redis的所有的資料都是放到記憶體中，存取的速度非常快，一般都是用來做快取使用。
  2、專案中使用redis一般都是作為快取來使用的，快取的目的就是為了減輕資料庫的壓力提高存取的效率。
  3、在網際網路專案中只要是涉及高併發或者是存在大量讀資料的情況下都可以使用redis作為快取。當然redis提供豐富的資料型別，除了快取還可以根據實際的業務場景來決定redis的作用。例如使用redis儲存使用者的購物車資訊、生成訂單號、訪問量計數器、任務佇列、排行榜等。

16、AcitveMQ的作用、原理？（生產者。消費者。 p2p、訂閱實現流程）
  Activemq的作用就是系統之間進行通訊。當然可以使用其他方式進行系統間通訊，如果使用Activemq的話可以對系統之間的呼叫進行解耦，實現系統間的非同步通訊。原理就是生產者生產訊息，把訊息傳送給activemq。Activemq接收到訊息，然後檢視有多少個消費者，然後把訊息轉發給消費者，此過程中生產者無需參與。消費者接收到訊息後做相應的處理和生產者沒有任何關係。

17、ActiveMQ在專案中如何應用的？
  Activemq在專案中主要是完成系統之間通訊，並且將系統之間的呼叫進行解耦。例如在新增、修改商品資訊後，需要將商品資訊同步到索引庫、同步快取中的資料以及生成靜態頁面一系列操作。在此場景下就可以使用activemq。一旦後臺對商品資訊進行修改後，就向activemq傳送一條訊息，然後通過activemq將訊息傳送給訊息的消費端，消費端接收到訊息可以進行相應的業務處理。

18、ActiveMQ如果資料提交不成功怎麼辦？
  Activemq有兩種通訊方式，點到點模式和釋出訂閱模式。
  如果是點到點模式的話，如果訊息傳送不成功此訊息預設會儲存到activemq服務端直到有消費者將其消費，所以此時訊息是不會丟失的。
  如果是釋出訂閱模式的通訊方式，預設情況下只通知一次，如果接收不到此訊息就沒有了。這種場景只適用於對訊息送達率要求不高的情況。如果要求訊息必須送達不可以丟失的話，需要配置持久訂閱。每個訂閱端定義一個id，在訂閱時向activemq註冊。釋出訊息和接收訊息時需要配置傳送模式為持久化。此時如果客戶端接收不到訊息，訊息會持久化到服務端，直到客戶端正常接收後為止。

19、當被問到某個模快存在安全性問題（sso單點登入系統）時，如何回答？
  目前商城的sso系統的解決方案中直接把token儲存到cookie中，確實存在安全性問題。但是實現簡單方便。如果想提高安全性可以使用CAS框架實現單點登入。參考連結：https://www.apereo.org/projects/cas

20、當技術面試官問到你某個技術點更深層次研究時，自己沒有深入瞭解怎麼回答？
  如果沒有深入研究就直接回答不知道就可以了。

21、如何把熱點商品或者是推廣商品的排名提高？
  可以設定文件中域的boost值，boost值越高計算出來的相關度得分就越高，排名也就越靠前。

22、solr的原理
  Solr是基於Lucene開發的全文檢索伺服器，而Lucene就是一套實現了全文檢索的api，其本質就是一個全文檢索的過程。全文檢索就是把原始文件根據一定的規則拆分成若干個關鍵詞，然後根據關鍵詞建立索引，當查詢時先查詢索引找到對應的關鍵詞，並根據關鍵詞找到對應的文件，也就是查詢結果，最終把查詢結果展示給使用者的過程。

23、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

24、業務如何說？先說業務、說表、說具體實現？
  先說總體的業務流程，然後再說具體業務的實現方法及使用的技術。最後說你在系統中負責的內容。不需要說表結構。

25、單點登入系統，如果cookie禁用，你們怎麼解決？
  如果禁用cookie可以使用url中帶引數，把token傳遞給服務端。當然此方法涉及安全性問題，其實在cookie中儲存token同樣存在安全性問題。推薦使用SSO框架CAS實現單點登入。

26、你們做移動端沒有，如果沒有移動端，你們為什麼做單點登入？
  單點登入並不是為移動端準備的，移動端有自己的登入方式。單點登入是解決在同一個公司內部多個互信網站之間進行跳轉時不需要多次登入，多個系統統一登入入口。

27、單點登入的核心是什麼？
  單點登入的核心是如何在多個系統之間共享身份資訊（即共享session）。

28、除了單點登陸，還做過什麼登陸的方式？
  除了單點登入那就是普通登入方式，使用者在同一個公司的多個系統之間跳轉時需要多次登入。

29、單點登入，http無狀態的，別人模仿如何在後端處理？
  http是無狀態的，如果別人模仿瀏覽器傳送http請求，一般後臺是無法識別的。如果對安全要求高的情況下應該是https協議。可以保證在通訊過程中無法竊取通訊內容。

30、安全性問題（別的網站使用爬蟲技術爬你的網站怎麼辦？有沒有安全措施）
  單位時間內請求次數超過某個閾值就讓輸入驗證碼，可以極大降低抓取的速度，如果多次超過某個閥值可以加入黑名單。還有就是頁面內容使用json返回，資料經常變一變格式，或者js動態生成頁面內容。

31、商品存入資料庫怎麼保證資料庫資料安全？
1、對使用者安全管理
  使用者操作資料庫時，必須通過資料庫訪問的身份認證。刪除資料庫中的預設使用者，使用自定義的使用者及高強度密碼。
2、定義檢視
  為不同的使用者定義不同的檢視，可以限制使用者的訪問範圍。通過檢視機制把需要保密的資料對無權存取這些資料的使用者隱藏起來，可以對資料庫提供一定程度的安全保護。實際應用中常將檢視機制與授權機制結合起來使用，首先用檢視機制遮蔽一部分保密資料，然後在檢視上進一步進行授權。
3、資料加密
  資料加密是保護資料在儲存和傳遞過程中不被竊取或修改的有效手段。
4、資料庫定期備份
5、審計追蹤機制
  審計追蹤機制是指系統設定相應的日誌記錄，特別是對資料更新、刪除、修改的記錄，以便日後查證。日誌記錄的內容可以包括操作人員的名稱、使用的密碼、使用者的IP地址、登入時間、操作內容等。若發現系統的資料遭到破壞，可以根據日誌記錄追究責任，或者從日誌記錄中判斷密碼是否被盜，以便修改密碼，重新分配許可權，確保系統的安全。

32、訂單表的資料量太大，我把訂單分到許多表中，那麼我我想用一條sql查處所有的訂單，怎麼解決？
  分庫情況下：可以使用mycat資料庫中介軟體實現多個表的統一管理。雖然物理上是把一個表中的資料儲存到多個數據庫中，但是邏輯上還是一個表，使用一條sql語句就可以把資料全部查詢出來。
  單庫情況下：需要動態生成sql語句。先查詢訂單相關的表，然後將查詢多個表的sql語句使用union連線即可。

33、咱們單點登入模組中，別人偽造我們cookie中的token怎麼辦？
  服務端是無法阻止客戶端偽造cookie的，如果對安全性要求高的話可以可使用CAS框架。

34、第一個是當兩個客戶同時買一件商品時庫存只有一個了，怎麼控制？
  可以使用mysql的行鎖機制，實現樂觀鎖，在更新商品之前將商品鎖定，其他使用者無法讀取，當此使用者操作完畢後釋放鎖。當併發量高的情況下，需要使用快取工具例如redis來管理庫存。

35、對資料庫只是採用了讀寫分離，並沒有完全解決資料庫的壓力，那麼有什麼辦法解決？
  如果資料庫壓力確實很大的情況下可以考慮資料庫分片，就是將資料庫中表拆分到不同的資料庫中儲存。可以使用mycat中介軟體。

36、同一賬號以客戶端登入怎麼擠掉另一端。
  使用者登入後需要在session中儲存使用者的id。當用戶登入時，從當前所有的session中判斷是否有此使用者id的存在，如果存在的話就把儲存此使用者id的session銷燬。

37、solr的索引查詢為什麼比資料庫要快？
  Solr使用的是Lucene API實現的全文檢索。全文檢索本質上是查詢的索引。而資料庫中並不是所有的欄位都建立的索引，更何況如果使用like查詢時很大的可能是不使用索引，所以使用solr查詢時要比查資料庫快。

38、solr索引庫個別資料索引丟失怎麼辦？
  首先Solr是不會丟失個別資料的。如果索引庫中缺少資料，那就向索引庫中新增。

39、Lucene索引優化
  直接使用Lucene實現全文檢索已經是過時的方案，推薦使用solr。Solr已經提供了完整的全文檢索解決方案。

我的GitHub地址：https://github.com/heizemingjun
我的部落格園地址：https://www.cnblogs.com/chenmingjun
我的螞蟻筆記部落格地址：https://blog.leanote.com/chenmingjun
Copyright ©2018~2019 黑澤君
【轉載文章務必保留出處和署名，謝謝！】