day82_淘淘商城項目_15_項目總結 + 項目中的問題_匠心筆記

項目總結

第一天

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 黑澤君

【轉載文章務必保留出處和署名，謝謝！】