宜立方 電商網站 -- 問題集合

 

 1 |基於大數據技術的電子商務平臺（老師指導下完成）
 2 Ø  開發時間：2017/12 – 至今
 3 Ø  軟件架構：Spring + SpringMVC + Mybatis +EasyUI + Solr + Redis + Maven
 4 Ø  項目描述：
 5 該項目採用SSM框架，採用Redis緩存，採用Solr搜索實現多維度檢索，緩解訪問數據庫壓力。採用Nginx進行地址映射、負載均衡、反向代理。並從數據存儲、服務器架設、性能方面進行優化設計，對項目功能模塊和系統架構進行進一步優化。採用大數據分析技術，經過對業務數據進行採集、提取、分類、分流、分析等處理，進行業務指導和決策支持。
 6 項目分爲：後臺管理系統，前臺顯示系統，用戶系統，訂單系統等。後臺管理能夠實現商品分類，商品管理，廣告管理等。前臺系統實現顯示商品分類、商品、廣告等。用戶系統實現註冊登錄功能，訂單系統實現添加購物車、商品結算功能。
 7 
 8 描述一下這個系統:
 9 [
10 從3個方面來回答這個問題：
11   |--系統背景及系統概述
12   |--系統包括的業務模塊及主業務流程
13   |--責任模塊
14 ]
15 
16 總體介紹：
17 1.背景及系統的概述:
18        商城是一個B2C(Business-to-Customer 商對客)電商項目，集零售與批發於一體。
19 整個項目技術用Spring,SpringMVC,Mybatis框架進行開發。
20 採用了分佈式架構,使用Maven進行項目依賴和jar包的管理,
21 使用中間切分的方式將web,service,mapper,pojo分層開發,這樣的好處也就是讓代碼的重用性更高.
22 採用Redis緩存，
23 採用Solr搜索實現多維度檢索，緩解訪問數據庫壓力，
24 採用Nginx進行地址映射、負載均衡、反向代理。
25 
26 2.系統包括的業務模塊及主業務流程:
27 咱們的這個項目爲後臺商品管理模塊、會員模塊、訂單模塊、購物車模塊、支付模塊、搜索模塊、評論模塊等。
28 
29 3.責任模塊：
30 我在這個項目中主要負責後臺商品的管理模塊：主要是實現商品的錄入、上下架、以及商品類目詳情展現，包括 商品規格參數模板設計以及商品實際參數錄入功能。其中在商品查詢中沒有使用傳統的mybatis分頁查詢而是會用一個分頁插件PageHelper來實現。對於商品圖片的上傳，在後臺頁面使用了富文本編輯器KindEditor進行批量上傳。後臺使用fileupload組件來接收圖片，在後臺代碼裏面實現圖片校驗功能，圖片驗證包括：圖片大小、格式、文件內容的校驗。防止危險腳本經過圖片上傳到服務器；文件內容的校驗是經過ImageIO讀取上傳的文件構建BufferedImage對象，經過斷定BufferedImage的寬高屬性來辨別上傳的文件是否爲圖片。關於數據庫優化方面，商品表中價格字段使用long型存儲，避免了開發中處理小數的問題,商品描述做爲表格單獨設計,由於數量比較大,並且描述通常不輕易改動,單獨做爲一個表在查詢商品的時候不須要查詢,提升了查詢性能,用戶須要的時候讓其查詢而對於商品規格參數的設計考慮一個商品對應一張表，存放該商品的規格參數數據，數據表太龐大，因而組內商討設計了一張商品規格參數模板表，該表中有事個字段，分別是id，建立時間，更新時間、商品類目id、商品類目名稱、規格參數模板數據。每一個類目對應模板表的一條記錄，規格參數模板數據存放的是商品類目的規格參數。新增添商品時模擬模板生成一個規格參數的表單。填寫規格參數數據，保存到數據庫中.
31 
32 前臺系統中我實現了商品分類的展現,實現商品分類展現我們當時有兩種思路,第一種就是當前臺系統的頁面須要商品分類信息的時候,前臺頁面向前臺系統發送ajax請求,由前臺系統經過HttpClient請問後臺系統獲取分類信息,而後前臺系統將商品分類信息數據給前臺頁面.
33 第二種實現方案是前臺頁面直接發送ajax請求訪問後臺系統,因爲後臺系統向前臺頁岩發送的是json格式的數據,而json數據沒法進行跨域傳送數據,我們當時使用了jsonp來包裝json數據,實現路霸數據的傳輸.這種實現方案性能稍高於第一種,最後我採用了這種設計思路。
34 
35 
36 因爲商品首頁分類展現的操做很頻繁，爲了減輕數據庫的壓力，我們使用了redis做爲緩存數據庫。後臺系統在查詢mysql數據庫以前，先查看redis裏面是否有商品分類信息，若是有則直接返回結果，若是沒有則查詢mysql數據庫，將查詢結果保存在redis中並返回該結果。
37 
38 我們的項目中關於用戶登陸的這塊採用的是單點登陸系統（什麼是單點登陸），考慮到通常用戶登陸的時候，當用戶登陸成功之後，我們將用戶信息保存在session中,由於這個我們採用的是分佈式架構,當用戶登陸要訪問其餘功能模塊的時候,因爲session是基於web服務器的,每個功能模塊都有本身的web服務器,各個功能模塊不能共享session數據,因此用戶須要從新登陸.我們採用了單點登陸系統.當用戶登陸成功後,我們根據時間戳和用戶id生成惟一的令牌ticket,將ticket和用戶令牌做爲鍵值對放在redis中,並把ticket寫入cookie中,當用戶訪問其餘功能模塊時,首先從cookie中拿到ticket,根據ticket在redis裏面查找用戶信息,若是找到則登陸成功。
39 
40 在首頁的搜索模塊中我們使用了solr實現，提供服務從數據庫中查詢的數據生成索引庫。爲了實現各模塊數據之間的同步，我們在搜索模塊讓娃不服務接口。只要後臺系統數據有增刪改就調用搜索模塊的服務進行索引庫的維護。（搜索這一塊是其餘人作的，他們提供了一個接口，經過這個接口調用搜索模塊的服務進行維護。）
41 
42 我們使用ActivityMQ實現商品數據的同步.爲了減輕數據庫的壓力,提升系統性能我們引入了redis緩存數據庫和solr索引庫，這樣就會涉及一個數據同步的問題。我們要保證mysql數據庫、redis緩存數據庫以及索引庫中商品的數據是一致的,原先我們是這麼作的:當後臺系統商品的數據進行增刪改操做後,經過httpClient調用前臺系統和搜索系統對redia和索引庫進行維護.這樣雖然能解決數據同步問題,可是各個模塊之間的耦合性過高.當新增長某個系統之後，要對後臺系統進行維護，這顯然不合理的，因此我們引入了activityMQ。後臺管理系統做爲消息的生產者，須要發送消息，在後臺系統聲明交換機，肯定交換機的類型topic。前端系統和搜索系統都是消息的消費者，在前端系統和搜索系統端聲明隊列，並監聽消息，根據消息內容作出相應的操做。
43 
44 購物車的實現有多種方式,能夠直接使用數據庫存儲購買的商品信息,可使用session來做爲購物車存儲商品.用數據爲存儲商品對數據庫形成的負擔特別大,並且對於購物車這種須要實時操做的東西,數據庫的訪問量一旦太大,數據庫容易出現併發錯誤,或者直接崩潰.用session來存儲商品信息效率確實很高,並且會話針對各個鏈接的,因此便於管理,可是用session也不是完美的,由於session是有有效期的，根據服務器設置不一樣而不一樣，若是你在購物的過程當中session超時了,那麼購物車中的東西就空了,session是保存在服務器內存中的,佔用了服務器資源.session沒法進行水平擴展,使用集羣..基於這些我們使用cookie+Mysql,來實現購物車功能.當用戶牌登陸狀態的時候,我們將購物車信息存放在Mysql數據庫中,當用戶處於離線狀態,我們將購物車信息存放在cookie中,用戶進行登陸操做的時候,判斷cookie中是否有購物車信息,若是有,則把購物車信息與數據庫中的合併,由於我們使用了數據庫做爲購物車來存放商品數據,考慮到數據庫的壓力大,我們採用了數據庫的集羣,搭建實現數據庫的讀寫分離.我們設計了一個主庫負責寫入數據,三個從庫讀取數據,這樣就大大減輕了數據庫的壓力。
45 
46 訂單系統，購物車系統。
47 在首頁的商品搜索模塊我們使用了solr實現，我們提供服務從數據庫中查詢的數據生成索引庫。爲了實現與數據庫之間的同步，我們在搜索快提供了服務接口。只要數據有增刪改就調用對應的服務，再以後我就實現了商品詳情頁的展現，首先根據商品的id到redis緩存中命中，若是緩存中沒有才會查詢數據庫，而且保存到redis中，考慮到redis是內存中的稀有資源，因此我們在設計的時候爲不須要常常顯示的提供了在redis中的有效時間。我們設計的是一天的時間，在商品詳情頁中首先將關鍵字段查詢展現，在使用延遲的方法加載商品描述，提升了相應的速度。而且商品規格我們使用按需加載，只有點擊加載商品描述，提升了生意人速度。而且商品規格我們使用按需加載，只有點擊纔會加載，減輕了數據庫的壓力。
48 
49 因爲顧客要建立訂單須要登陸，可是我們採用的是分佈式架構，爲了提升顧客的體驗性，因此我們採用了單點登陸系統。

View Code

 

1，電子商務常見模式

　　B2B：商家到商家。阿里巴巴。
　　B2C：商家到用戶。京東。
　　C2C：用戶到用戶。淘寶。
　　B2B2C：商家到商家到用戶。天貓。
　　O2O：線上到線下。美團、餓了麼。

 

2，電子商務行業技術特色　

　　①技術新：(NoSql推廣首在社區網站和電商項目)，發展快，需求推進技術的革新。
　    ②技術範圍廣：除了java，像淘寶前端還使用了PHP，數據庫MySQL或者oracle，nosql，服務器端使用Linux，服務器安全、系統安全
　　③分佈式：之前是在一臺機器上作運算，如今是分散到不少機器上，最後彙總起來。(集中式向分佈式進行考慮)由需求來推進
　　④高併發、集羣、負載均衡、高可用：由併發問題採用集羣處理，集羣會涉及服務器的主從以及分佈問題，使用負載均衡。(權重高低)高可用對用戶而言，用戶服務不中斷(系統升級，服務不中斷)。
　　⑤海量數據：雙11,570億的背後，訂單有多少？瀏覽次數有多少？商品會有多少？活動相關數據？
　　⑥業務複雜：不要簡單的認爲是：商品展現出來後，加入購物車後購買就完成了。後臺特別複雜，好比優惠(包郵、滿減)
　　⑦系統安全：系統上線必須經過系統安所有門審覈經過。前年CSDN數據泄露。快捷酒店數據泄露(經過身份證就能夠查看你的開房記錄)。近幾年，安全意識逐步在提升。

 

3，Maven是什麼?爲何要進行項目依賴與Jar包管理

　　Maven是一個採用純Java編寫的開 源項目管理工具。採用了一種被稱之爲project object model (POM)概念來管理項目，全部的項目配置信息都被定義在一個叫作POM.xml的文件中，經過該文件，Maven能夠管理項目的整個聲明週期，包括編 譯，構建，測試，發佈，報告等等。Maven自己還支持多種插件，能夠方便更靈活的控制項目。

　　Maven經常使用於項目構建，依賴管理，熱部署等。方便Jar包管理，工程之間的依賴管理，自動打包，熱部署，方便svn版本控制。

 

4，什麼是分佈式架構，爲何使用分佈式架構，分佈式架構的優勢？

　　分佈式結構就是將一個完整的系統，按照業務功能，拆分紅一個個獨立的子系統，在分佈式結構中，每一個子系統就被稱爲「服務」。這些子系統可以獨立運行在web容器中，它們之間經過RPC方式通訊。

　　注：集羣是多臺設備幹同一件事情，而分佈式是不一樣的設備幹不一樣的事情。

　　就商城項目而言。按照微服務的思想，咱們須要按照功能模塊拆分紅多個獨立的服務，如：用戶服務、產品服務、訂單服務、後臺管理服務、數據分析服務等等。這一個個服務都是一個個獨立的項目，能夠獨立運行。若是服務之間有依賴關係，能夠經過RPC方式相互調用。

這樣的好處有不少：

1. 系統之間的耦合度大大下降，可以獨立開發、獨立部署、獨立測試，系統與系統之間的邊界很是明確，排錯也變得至關容易，開發效率大大提高。
2. 系統之間的耦合度下降，從而系統更易於擴展。咱們能夠針對性地擴展維護某些服務。假設這個商城要搞一次大促，下單量可能會大大提高，所以咱們能夠針對性地提高訂單系統、產品系統的節點數量，而對於後臺管理系統、數據分析系統而言，節點數量維持原有水平便可。
3. 服務的複用性更高。好比，當咱們將用戶系統做爲單獨的服務後，該公司全部的產品均可以使用該系統做爲用戶系統，無需重複開發。

 

5，項目的架構，分層架構？

　　技術架構：本項目使用市場上較爲主流的框架spring+springmvc+mybatis進行開發，採用分佈式的系統架構，前臺系統和單點登陸系統採用了集羣的方式部署，後臺管理系統中採用了Maven的多模塊化的管理，其中採用了水平切分的方式，將pojo、dao、service、web分層開發，這樣作的好處就是能夠重用性更高。系統內部接口調用採用Dubbo，在後臺接口中擴展了spirng提供的jackson數據轉化器實現；搜索系統使用了solr實現，在保證系統高性能的前提下，儘量爲公司節約成本，咱們使用MySQL數據庫進行集羣(oracle收費)。在部署方面，採用了Nginx+tomcat的模式，其中nginx的做用一方面是作反向代理、負載均衡、另外一方面是作圖片等靜態資源的服務器。
　　功能架構：分佈式系統架構，如問題四

 

6，涉及的技術

　　Spring、SpringMVC、MybatisJSP、JSTL、jQuery、jQuery plugin、EasyUI、KindEditor(富文本編輯器)、CSS+DIV
　　Redis（緩存服務器）
　　Lucene、Solr（搜索）
　　httpclient（調用系統服務）
　　Mysql
　　Nginx（web服務器）
　　Quartz（定時任務）
　　RabbitMQ（消息隊列）

 

7，功能介紹，項目實現了哪些功能？

　　本項目包含：前臺、後臺、會員、訂單、搜索、單點登錄等系統模塊。
　　　　1）搜索系統包括提供商品的搜索功能。
　　　　2）訂單系統包括提供下單、查詢訂單、修改訂單狀態、定時處理訂單。
　　　　3）後臺管理系統包括管理商品、訂單、類目、商品規格屬性、用戶管理以及內容發佈等功能。
　　　　4）前臺系統包括用戶能夠在前臺系統中進行註冊、登陸、瀏覽商品、首頁、下單等操做。
　　　　5）會員系統包括用戶能夠在該系統中查詢已下的訂單、收藏的商品、個人優惠券、團購等信息。
　　　　6）單點登陸系統爲多個系統之間提供用戶登陸憑證以及查詢登陸用戶的信息。

 

 

8，爲何使用Redis緩存？使用緩存的優勢？

　 　使用緩存事爲了緩解數據庫壓力。在項目中查詢功能是很是頻繁的，若是每次查詢都調用數據庫的話，會給數據庫形成很大的壓力，所以須要在用戶和數據庫之間加一層緩存，對於一樣的查詢，只查詢一遍數據庫，而後把數據保存到緩存當中，當其餘用戶再訪問一樣的頁面時即可以直接從緩存中去讀取數據，這樣查詢效率將會提高很是多，同時也會大大減輕數據庫的壓力。

　　Redis將其數據庫徹底保存在內存中，僅使用磁盤進行持久化。 與其它鍵值數據存儲相比，Redis有一組相對豐富的數據類型（String、Hash、List、Set、SortedSet）。 Redis能夠將數據複製到任意數量的從機中。

 

9，使用Solr幹什麼？Solr怎麼進行搜索的？怎麼實現多維度檢索？

　　Solr是一個高性能，採用Java5開發，基於Lucene的全文搜索服務器。同時對其進行了擴展，提供了比Lucene更爲豐富的查詢語言，同時實現了可配置、可擴展並對查詢性能進行了優化，而且提供了一個完善的功能管理界面，是一款很是優秀的全文搜索引擎。咱們把搜索單獨作成一個服務，能夠針對該服務作擴展，作成服務集羣等，其它模塊均可以調用Solr服務。

 

10，Nginx是怎麼進行地址映射，負載均衡，反向代理等工做的？

反向代理：

 

11，項目中數據庫壓力的解決方案都有哪些？還有其餘的數據庫壓力緩解的方法嗎？

　　1，數據庫語句優化

　　2，數據庫存儲優化（雙數據庫切換數據分流，使用Mycat進行分表分庫，Mysql進行讀寫分離，主備複用，主從複製）

　　3，數據庫訪問性能優化（Redis緩存數據，FastDFS數據庫）

 

12，數據存儲，服務器架設，性能方面怎麼進行優化的？

　　數據存儲：如問題11

　　服務器：

　　　　使用Zookeeper進行服務管理，Dubbo進行服務的發佈等。

　　　　使用Spring Cloud進行服務發佈，配置管理，智能路由等。

　　　　使用Nginx進行負載均衡，反向代理，區域分流。

　　　　使用FastDFS對大文件進行存儲、同步、上傳和下載等。

　　　　使用NoSql（Redis）作數據緩存，用空間換時間，用內存換速度。

　　　　使用Solr搜索與HBase結合實現多維度檢索。

　　性能：

　　　　使用FreeMark進行網頁靜態化。

　　　　系統拆分爲分佈式系統，提升系統擴展性。

 

13，項目中遇到的問題？解決方案？

　　1，後臺管理模塊（商品錄入，上架下架，商品詳情展現【規格參數模板設計，實際參數錄入】）

　　　　技術亮點：分頁插件pagehelper，富文本編輯器，圖片校驗，EasyUI

　　　　數據存儲優化：【商品表價格字段爲long，避免小數】，【商品描述單獨做爲表設計】，【商品規格參數模板】

分頁：
商品查詢中沒有使用傳統的mybatis分頁查詢而是會用一個分頁插件PageHelper來實現。

富文本編輯器：
對於商品圖片的上傳，在後臺頁面使用了富文本編輯器KindEditor進行批量上傳。

圖片校驗：
使用fileupload組件來接收圖片，在代碼裏面實現圖片校驗功能，圖片驗證包括：圖片大小、格式、文件內容的校驗。防止危險腳本上傳到服務器；
文件內容的校驗是經過ImageIO讀取上傳的文件構建BufferedImage對象，經過斷定BufferedImage的寬高屬性來辨別上傳的文件是否爲圖片。

數據存儲優化：
商品表中價格字段使用long型存儲，避免了開發中處理小數的問題； 
商品描述做爲表格單獨設計,由於數量比較大,並且描述通常不輕易改動,單獨做爲一個表在查詢商品的時候不須要查詢,提升了查詢性能； 
商品規格參數的設計考慮一個商品對應一張表，存放該商品的規格參數數據，數據表太龐大，設計了一張商品規格參數模板表；
該表中有事個字段，分別是id，建立時間，更新時間、商品類目id、商品類目名稱、規格參數模板數據；
每一個類目對應模板表的一條記錄，規格參數模板數據存放的是商品類目的規格參數，
新增添商品時模擬模板生成一個規格參數的表單。填寫規格參數數據，保存到數據庫中。

　　

2，前臺技術：

　　　　技術亮點：Bootstarp，Jsonp包裝json數據，頁面靜態化

　　　　數據庫優化：Redis緩存數據庫　　

實現商品分類展現：

第一種實現方案是:
當前臺系統的頁面須要商品分類信息的時候,前臺頁面向前臺系統發送ajax請求,由前臺系統經過HttpClient請問後臺系統獲取分類信息,
而後前臺系統將商品分類信息數據給前臺頁面。 第二種實現方案是：
前臺頁面直接發送ajax請求訪問後臺系統,因爲後臺系統向前臺頁岩發送的是json格式的數據,而json數據沒法進行跨域傳送數據,
當時使用了jsonp來包裝json數據,實現路霸數據的傳輸。

這種實現方案性能稍高於第一種,最後我採用了第二種設計思路。

 

　　3，單點登錄頁面：

　　　　技術亮點：共享Session（先從Session中拿到ticket【時間戳和用戶id生成的惟一令牌】，根據ticket再redis中查找用戶信息）

Redis:
因爲商品首頁分類展現的操做很頻繁，爲了減輕數據庫的壓力，我們使用了redis做爲緩存數據庫。
後臺系統在查詢mysql數據庫以前，先查看redis裏面是否有商品分類信息
若是有則直接返回結果，若是沒有則查詢mysql數據庫，將查詢結果保存在redis中並返回該結果。

單點登陸：

 通常用戶登陸的時候，當用戶登陸成功之後，用戶信息保存在session中,由於這個我們採用的是分佈式架構,當用戶登陸要訪問其餘功能模塊的時候,
 因爲session是基於web服務器的,每個功能模塊都有本身的web服務器,各個功能模塊不能共享session數據,因此用戶須要從新登陸

 我們採用了單點登陸系統.當用戶登陸成功後,就不用在其餘系統中登錄，也就是一次登錄能夠得到其餘全部系統的信任，

 我們根據時間戳和用戶id生成惟一的令牌ticket（String ticket= user.getUserId() + "" + System.currentTimeMillis();）,將ticket和用戶令牌做爲鍵值對放在redis中,並把

 ticket寫入cookie中,當用戶訪問其餘功能模塊時,首先從首先從cookie中拿到ticket,   根據ticket在redis裏面查找用戶信息,若是找到則登陸成功。

　　4，搜索頁面：

　　　　技術亮點：Solr搜索（索引庫），ActivityMQ消息隊列（實現數據同步【索引庫，緩存與信息】），延遲加載

Solr:
在首頁的搜索模塊中我們使用了solr實現，提供服務從數據庫中查詢的數據生成索引庫。爲了實現各模塊數據之間的同步，在搜索模塊提供服務接口。
只要後臺系統數據有增刪改就調用搜索模塊的服務進行索引庫的維護。（提供了搜索服務接口，經過接口調用搜索模塊的服務進行維護。）

ActivityMQ：
使用ActivityMQ實現商品數據的同步，爲了減輕數據庫壓力,提升系統性能，引入了redis緩存數據庫和solr索引庫，這樣就會涉及數據同步問題。
我們要保證mysql數據庫、redis緩存數據庫以及索引庫中商品的數據是一致，

原先我們是這麼作的:
當後臺系統商品的數據進行增刪改操做後,經過httpClient調用前臺系統和搜索系統對redia和索引庫進行維護.這樣雖然能解決數據同步問題,
可是各個模塊之間的耦合性過高.當新增長某個系統之後，要對後臺系統進行維護。

這顯然不合理的，因此我們引入了activityMQ。

後臺管理系統做爲消息的生產者，須要發送消息，在後臺系統聲明交換機，肯定交換機的類型topic。前端系統和搜索系統都是消息的消費者，
在前端系統和搜索系統端聲明隊列，並監聽消息，根據消息內容作出相應的操做。

　

　5，購物車：

　　　　技術亮點：Mysql+Session存儲商品信息，數據庫集羣（讀寫分離，主備複用，負載均衡）

購物車：
能夠直接使用數據庫存儲購買的商品信息,可使用session來做爲購物車存儲商品。
這樣用存儲商品對數據庫形成的負擔特別大,並且購物車這種須要實時操做的東西,數據庫的訪問量一旦太大,數據庫容易出現併發錯誤,或者直接崩潰。

使用session來存儲商品信息效率確實很高,並且會話針對各個鏈接的,因此便於管理。
可是用session也不是完美的,由於session是有有效期的，根據服務器設置不一樣而不一樣
若是你在購物的過程當中session超時了,那麼購物車中的東西就空了,session是保存在服務器內存中的,佔用了服務器資源。

我們使用cookie+Mysql來實現。
當用戶牌登陸狀態的時候,我們將購物車信息存放在Mysql數據庫中,當用戶處於離線狀態,我們將購物車信息存放在cookie中,
用戶進行登陸操做的時候,判斷cookie中是否有購物車信息,若是有,則把購物車信息與數據庫中的合併,
由於我們使用了數據庫做爲購物車來存放商品數據,考慮到數據庫的壓力大,我們採用了數據庫的集羣,搭建實現數據庫的讀寫分離。
我們設計了一個主庫負責寫入數據,三個從庫讀取數據,這樣就大大減輕了數據庫的壓力。
未登陸(先寫到cookie和Redis緩存中，登陸後寫到數據庫表中)；
已登陸(直接寫到數據庫，而後寫到Redis緩存中)

訂單系統，購物車系統。
在首頁的商品搜索模塊我們使用了solr實現，我們提供服務從數據庫中查詢的數據生成索引庫。
爲了實現與數據庫之間的同步，我們在搜索快提供了服務接口，只要數據有增刪改就調用對應的服務。

再以後我就實現了商品詳情頁的展現，首先根據商品的id到redis緩存中命中，若是緩存中沒有才會查詢數據庫，而且保存到redis中，
考慮到redis是內存中的稀有資源，因此我們在設計的時候爲不須要常常顯示的提供了在redi中的有效時間。我們設計的是一天的時間，
在商品詳情頁中首先將關鍵字段查詢展現，在使用延遲的方法加載商品描述，提升了相應的速度。而且商品規格我們使用按需加載，只有點擊加載商品描述，減輕了數據庫壓力