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

摘要： 專案的總結 第一天： 學習電商行業的背景，電商模式：B2B、B2C、B2B2C、O2O。 分散式，叢集的理解，系統的架構，基於SSO的架構。 使用Maven搭建後臺工程，及SVN的使用。 第二天： dubbo的學習和使用，系統和系統之間通訊的中介...

專案的總結

第一天：

學習電商行業的背景，電商模式：B2B、B2C、B2B2C、O2O。

分散式，叢集的理解，系統的架構，基於SSO的架構。

使用Maven搭建後臺工程，及SVN的使用。

第二天：

dubbo的學習和使用，系統和系統之間通訊的中介軟體。

webservice ：系統之間通訊。應用於 外部系統 ，並且資料交換不是特別大的情況下（傳統行業OA與ERP之間的通訊）。

http+json：系統之間通訊。屬於 http的協議 ， RestFul風格 傳遞資料（手機客戶端和後臺進行通訊，SSO系統給手機發布介面呼叫，傳遞JSON）。

dubbo：系統之間的通訊。屬於 RPC的協議 （底層二進位制協議），使用 socket通訊 ，傳輸效率高，一般用於 內部系統 之間。作為SOA架構的管理工具，能統計各個服務呼叫的次數。

SSM的整合，逆向工程，商品列表展示，分頁外掛的使用， Easyui 的使用（ datagrid 的使用查詢商品列表）。

學習dubbo的架構及4個角色，如何在spring使用。dubbo的使用貫穿於整合專案，有服務層和表現層的互動就需要使用dubbo。

第三天：

商品類目的選擇，使用 EasyUI 的 tree控制元件 。傳統圖片上傳功能，上傳到某一個tomcat，在叢集環境下，上傳之後，有可能由另一臺伺服器提供服務，圖片不存在，所以需要單獨建立圖片伺服器 FastDFS （tracker、storage）。

在叢集環境下使用FastDFS來儲存圖片（會使用FASTDFS客戶端上傳下載圖片即可）。還有富文字編輯器 KindEditor 的使用（純js實現的）。

富文字編輯器：引入JS、定義好資料來源（ textarea ）、表單提交之前、同步資料、將富文字編輯器中的內容同步到textarea中。

第四天：

商城首頁系統（portal）的搭建 ，使用偽靜態URL攔截形式: *.html 。（SEO：搜尋引擎優化）

首頁的資料應當 動態展示 ，需要有一個 CMS系統 來動態維護（CMS：內容管理系統），就是內容和內容分類管理。輪播圖的動態展示。

首頁訪問壓力很大，需要做 快取redis 。

第五天：

在首頁中的訪問壓力特別大，需要解決 高併發 的問題，使用 快取技術 ，學習了redis技術，並使用 redis的java客戶端Jedis 在內容獲取時的服務層中新增快取及快取同步。

redis：就是一種以 KEY-VALUE 形式 儲存資料在記憶體中 的技術（主要用於快取）。

set 
get 
expire
incr 
keys * 

redis五種儲存資料型別：string hash list set sortedset

sortedset 用於做排行榜，有序，並且不重複。

redis的持久化方案：RDB、AOF。

RDB：快照。

AOF：(append only file) redis中的每一個操作都記錄起來。一旦重啟，就可以將原來資料恢復。

需要手動開啟AOF持久化方案，預設是開啟RDB。

redis伺服器的搭建及叢集搭建（奇數結點）因為：redis叢集中有 投票機制 ，半數以上投票。

注意：新增快取的邏輯不能影響正常的業務邏輯。應用最多的資料型別是 string 和 hash 。

第六、七天：

lucene是一個全文檢索的工具包，提供很多的檢索使用的API。

在首頁中如果找不到對應的商品，就需要搜尋商品，實現搜尋的技術是 lucene/solr 。

學習了lucene相關的介紹，應用場景，以及實現全文檢索的流程。

索引流程及搜尋流程。

學習入門程式：索引流程的程式碼實現。luke的使用。

學習入門程式：搜尋流程的程式碼實現。

索引域及文件的域，以及Field域的說明（是否分詞、是否索引、是否儲存）

索引的維護：

搜尋的兩種型別（使用query子類及queryParser）及lucene搜尋相關的語法。

最簡單的語法： field:value 從field查詢包含value的值的資料。

分詞的過程：

分詞（英文單詞，按空格分詞） --> 過濾（標點符號去掉） --> 大寫轉小寫 --> 去掉停用詞。

中文分詞器的IKAnalyzer的使用：

1、jar包新增到工程build path

2、配置檔案（xx.cfg.xml、擴充套件詞典、停用詞詞典）放入classes下

3、定義業務域

特點：可以擴充套件、可以維護、支援中文分詞。

第八天：

solr 是(基於lucene)搜尋引擎，可以獨立部署，來實現搜尋功能，高亮顯示，效能優化，可以解決高併發的搜尋需求。

lucene和solr的區別：

1、lucene是工具包，solr是伺服器（打比方：lucene是汽車引擎，solr是汽車）

2、lucene的業務域不需要先定義後使用，solr必須是先定義後使用。

3、lucene加入應用系統的時候，耦合度很高不易擴充套件。

4、solr是伺服器，只需要通過http請求操作索引。維護、升級方便，並且能做效能優化。

使用 solrj 作為java的客戶端操作索引和搜尋。

京東案例的實現。使用IK分詞器，配置在schema.xml中。

第九天：

taotao商城的solr服務在linux的搭建，搜尋服務層系統的搭建，表現層搭建，並使用solr實現商品搜尋功能（中文分析器的配置、業務域定義、入資料到索引庫、索功能的實現）。

solr分頁：通過solrj設定start，設定rows，預設查詢是10條。

查詢的時候需要指定預設的搜尋域。

第十天：

在併發量特別大的情況下，一個solr伺服器無法滿足要求，學習了solr叢集在linux下的搭建，參考教案。

測試了solrj的叢集版的使用，將搜尋功能切換到叢集版。

全域性異常處理：需要建立一個類實現 全域性異常處理器的介面（handlerexceptionresolver） ，配置在配置檔案springmvc。xml中。

全域性異常處理中實現：

1、日誌處理

2、傳送異常資訊郵件給相關人員

3、響應一個友好的錯誤頁面給客戶

第十一天：

索引庫需要同步時，可以使用 非同步訊息的中介軟體(activemq) 來實現索引庫的同步。

Activemq的使用場景：

不需要同步等待時的系統之間的通訊使用。比如：訂單系統。 產生訂單後，需要傳送響應給客戶，提示成功。但不需要等待使用者點選確定後才繼續產生訂單。訂單系統只需要產生訂單後，非同步傳送一個訊息，又繼續執行下一個產生訂單邏輯而不需要再等待頁面響應。

同步索引庫。

同步快取。

生成靜態頁面。

傳遞訊息的型別：

PTP --> queue --> 預設快取在mq伺服器上，只能被一個消費者接收。

publish/subscribe --> topic預設是不快取，可以被多個消費者接收。（需要消費者先訂閱）

訊息的格式（JMS的規範）6種格式。TxtMessage、ObjectMessage、ByteMessage、……

1、一般是和spring進行整合使用。

2、傳送端：JMSTemplate 傳送訊息。

3、接收端：使用設定一個監聽容器 --> 指定監聽器 (MessageListener)。

第十二天：

商品詳情的系統搭建 （參考京東，訪問商品詳情時，域名已經變化）。

使用jsp和redis實現頁面的高效能動態展示。

如果高併發量：需要實現 網頁靜態化 來提升響應速度。

freemarker可實現網頁靜態化，使用freemarker的常用語法學習。實現網頁靜態化的方案實現。通過使用activemq實現同步生成靜態網頁。

實現網頁靜態化的方案：

部署不同的伺服器上的（taoao-item-web）工程，分別訂閱了topic（當商品新增/更新的時候傳送的topic包含商品id），工程接收到訊息，產生靜態頁面。

工程所在的伺服器上再部署一個http伺服器，來指定靜態頁面的目錄，提供瀏覽器訪問靜態頁面，提升效率。

第十三天：

在實現靜態化的方案中需要使用nginx，需要學習nginx。nginx能實現的功能：

1、配置虛擬主機，複製 server結點 即可。

2、反向代理，設定 upstream節點 來指定服務的ip地址和埠，在 location結點 設定proxy_pass=http://upstream; 參考教案。

3、負載均衡。

4、作為Http伺服器。

學習實現nginx的高可用的原理。

第十四天：

SSO系統：主要解決分散式環境下 session共享 的問題。

SSO系統的搭建，註冊，登入，通過 token （相當於 jsessionid ）獲取使用者資訊。實現SSO服務，提供給 其他客戶端（如手機介面） 介面。

登入流程：使用者填入使用者名稱和密碼，如果正確，key是一個uuid生成的唯一值（token）。使用者資訊儲存到redis中，設定此key的有效期模擬session（30分鐘），設定到cookie中（跨域：訪問的埠不同，域名不同）。

使用 JSONP 的技術：登入之後，在首頁需要顯示使用者資訊。使用JSONP來實現ajax跨域。

第十五天：

SSO系統的介面的開發完成及購物車實現以及訂單確認頁面實現。

購物車使用cookie來存放。有缺點：更換裝置不能同步資料，儲存的容量有限，如果cookie一旦被禁用，無法使用。

解決方案：

在使用者未登入的情況下，繼續使用cookie來存放購物車，展示列表以cookie為準。

一旦使用者登入，將cookie的資料同步到資料庫redis中，並刪除cookie的內容，展示購物車列表就以redis中的資料為準，後續的新增到購物車也需要新增到redis中。

進入訂單確認頁面，需要認證身份，通過 攔截器 來實現。

第十六天：

訂單提交的功能實現。專案的部署， mysql的linux的安裝 ，系統的網路拓撲圖，伺服器的域名規劃，伺服器的數量規劃及部署。使用tomcat的熱部署，反向代理的配置。

專案中的問題

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

1、淘淘商城簡歷中的描述

參考簡歷。

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

2、淘淘網站的併發量 大概：說5000左右也行。（此處要問怎麼來的，可以說經過 壓力測試 出來的，自己沒做過，但是知道。有些情況下，並不是所有的事情都是由你來做，由面試官決定用不用你，你把所知道的說清楚就行）

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查詢商品更新索引。

再有：面試中，要淡定，如果有面試官問：資料庫設計這樣做正確嗎？

你不清楚的情況下，你就說我們公司就是這麼解決的。其他的我不知道。

有些面試官，可能他也不知道，他也想知道。

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已經提供了完整的全文檢索解決方案 。