摘要商城總結

第一天： 學習電商行業的背景，電商模式：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。

第6、七天： lucene是一個全文檢索的工具包，提供不少的檢索使用的API。 在首頁中若是找不到對應的商品，就須要搜索商品，實現搜索的技術是lucene/solr。 學習了lucene相關的介紹，應用場景，以及實現全文檢索的流程。

索引流程及搜索流程。 學習入門程序：索引流程的代碼實現。luke的使用。 學習入門程序：搜索流程的代碼實現。 索引域及文檔的域，以及Field域的說明（是否分詞、是否索引、是否存儲）

索引的維護： 搜索的兩種類型（使用query子類及queryParser）及lucene搜索相關的語法。 最簡單的語法：field:value從field查詢包含value的值的數據。

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

中文分詞器的IKAnalyzer的使用： 一、jar包添加到工程build path 二、配置文件（xx.cfg.xml、擴展詞典、停用詞詞典）放入classes下 三、定義業務域 特色：能夠擴展、能夠維護、支持中文分詞。

第八天： solr 是(基於lucene)搜索引擎，能夠獨立部署，來實現搜索功能，高亮顯示，性能優化，能夠解決高併發的搜索需求。 lucene和solr的區別： 一、lucene是工具包，solr是服務器（打比方：lucene是汽車引擎，solr是汽車） 二、lucene的業務域不須要先定義後使用，solr必須是先定義後使用。 三、lucene加入應用系統的時候，耦合度很高不易擴展。 四、solr是服務器，只須要經過http請求操做索引。維護、升級方便，而且能作性能優化。 使用solrj做爲java的客戶端操做索引和搜索。 京東案例的實現。使用IK分詞器，配置在schema.xml中。

第九天： taotao商城的solr服務在linux的搭建，搜索服務層系統的搭建，表現層搭建，並使用solr實現商品搜索功能（中文分析器的配置、業務域定義、入數據到索引庫、索功能的實現）。 solr分頁：經過solrj設置start，設置rows，默認查詢是10條。 查詢的時候須要指定默認的搜索域。

第十天： 在併發量特別大的狀況下，一個solr服務器沒法知足要求，學習了solr集羣在linux下的搭建，參考教案。 測試了solrj的集羣版的使用，將搜索功能切換到集羣版。 全局異常處理：須要建立一個類實現全局異常處理器的接口（handlerexceptionresolver），配置在配置文件springmvc。xml中。 全局異常處理中實現： 一、日誌處理 二、發送異常信息郵件給相關人員 三、響應一個友好的錯誤頁面給客戶

第十一天： 索引庫須要同步時，可使用異步消息的中間件(activemq)來實現索引庫的同步。

Activemq的使用場景： 不須要同步等待時的系統之間的通訊使用。好比：訂單系統。

  產生訂單後，須要發送響應給客戶，提示成功。但不須要等待用戶點擊肯定後才繼續產生訂單。訂單系統只須要產生訂單後，異步發送一個消息，又繼續執行下一個產生訂單邏輯而不須要再等待頁面響應。 同步索引庫。 同步緩存。 生成靜態頁面。

傳遞消息的類型： PTP --> queue --> 默認緩存在mq服務器上，只能被一個消費者接收。 publish/subscribe --> topic默認是不緩存，能夠被多個消費者接收。（須要消費者先訂閱）

消息的格式（JMS的規範）6種格式。TxtMessage、ObjectMessage、ByteMessage、…… 一、通常是和spring進行整合使用。 二、發送端：JMSTemplate 發送消息。 三、接收端：使用設置一個監聽容器 --> 指定監聽器 (MessageListener)。

第十二天： 商品詳情的系統搭建 （參考京東，訪問商品詳情時，域名已經變化）。 使用jsp和redis實現頁面的高性能動態展現。 若是高併發量：須要實現網頁靜態化來提高響應速度。

freemarker可實現網頁靜態化，使用freemarker的經常使用語法學習。實現網頁靜態化的方案實現。經過使用activemq實現同步生成靜態網頁。 實現網頁靜態化的方案： 部署不一樣的服務器上的（taoao-item-web）工程，分別訂閱了topic（當商品添加/更新的時候發送的topic包含商品id），工程接收到消息，產生靜態頁面。 工程所在的服務器上再部署一個http服務器，來指定靜態頁面的目錄，提供瀏覽器訪問靜態頁面，提高效率。

第十三天： 在實現靜態化的方案中須要使用nginx，須要學習nginx。nginx能實現的功能： 一、配置虛擬主機，複製server結點便可。 二、反向代理，設置upstream節點來指定服務的ip地址和端口，在location結點設置proxy_pass=http://upstream; 參考教案。 三、負載均衡。 四、做爲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：如下描述若與就業老師所說有衝突，請以就業老師爲準，另外參考簡歷必定要改，切不可拿來主義

一、淘淘商城簡歷中的描述 參考簡歷。 注意：在真實的開發項目中，開發工程師不可能開發全部的模塊，只會負責某幾個模塊，你們所要描述的是：你所負責的模塊（通常3到4個模塊）。

二、淘淘網站的併發量 大概：說5000左右也行。（此處要問怎麼來的，能夠說通過壓力測試出來的，本身沒作過，可是知道。有些狀況下，並非全部的事情都是由你來作，由面試官決定用不用你，你把所知道的說清楚就行）能夠知足目前的業務需求。因爲咱們的系統是分佈式架構，支持水平擴展，若是未來併發量提升的話，能夠增長服務器來提升併發量。

三、淘淘商城人員的配置 產品經理：3人，肯定需求及給出產品原型圖。 項目經理：1人，項目管理。 前端團隊：5人，根據產品經理給出原型製做出靜態頁面（固然也包括UI）。 後端團端：20人，實現產品的功能（大家就屬於後端團隊）。 測試團隊：5人，負責測試產品的全部的功能。

四、開發週期 如今開發採用敏捷開發，快速迭代，開發週期大概6-8個月，後期通常採用迭代的方式開發，通常迭代的週期爲一個月左右。（迭代就是所謂的一個小版本的開發）

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

六、你說你用了redis，大家redis存的是什麼格式的數據，都是怎麼存的？ redis中存放數據都是key-value的形式。 咱們商城使用string類型來存放的。拿商品來講：商品的id就是key，商品相關的商品信息組成一個JSON存放。

七、你前臺系統portal採用4服務器作集羣部署，前臺系統的併發量提高上去，那對於數據庫會不會形成一個瓶頸，這一塊大家是怎麼處理的？ portal在高併發的狀況下，能夠經過部署集羣來提升併發量，這種時候，若是每次都訪問數據，確實會對數據庫形成很大的壓力，那麼這時候，咱們就採用在服務層增長緩存，使用redis實現，這樣客戶端請求到達時，先從緩存中讀取，若是存在數據則直接返回，而不會再從數據庫查詢，若是緩存中沒有，則從數據庫查詢，這樣就可減小數據庫的訪問，達到提高數據的訪問瓶頸。

八、購物車存在cookie中，能夠實現不登陸就可使用購物車，若是我沒有登陸，購買了商品，如今更換了設備（電腦），那還能不能看到我買的商品？若是看不到怎麼作cookie同步？ 不能；現階段，淘淘商城是採用cookie的方式存放購物車，以減小服務端的存儲壓力。可是弊端就是當更換設備後將看不到已添加的商品，也就是不能同步商品信息。 打算下一步這麼實現：當用戶沒有登陸時，商品的數據放入購物車中，將存放於cookie中，此時若是用戶登陸，將cookie中的數據存放在redis中，而且是和用戶的ID關聯，並將cookie中的數據刪除。此時若是用戶更換設備，只要使用同一賬號登陸，就能夠看到購物車中的商品信息，就達到了同步cookie的目的。

九、大家商城是經過什麼來作搜索的？ 由於系統要使用站內搜索功能，數據量很大，須要使用solr。 solr是(基於lucene)搜索引擎，能夠獨立部署，來實現搜索功能、高亮顯示、性能優化，能夠解決高併發的搜索需求。 例如：咱們系統就是用solr作商品搜索。--> 怎麼作的呢？ solr是一個服務器，須要搭建，須要先定義好Field和FieldType，定義中文分詞器，再使用。 經過solr的Java客戶端solrj鏈接solr服務，它提供豐富的操做索引的方法，能夠經過這個客戶端來實現搜索功能。 大家索引庫通常有多少數據？答：幾百萬 若是數據量特別大？怎麼辦？答：作集羣。 索引庫是如何同步？答：activemq異步消息隊列。

十、solr和lucene他們之間有什麼區別？ lucene是一個工具包，相似於一個類庫。 solr是一個基於solr的搜索引擎，能夠獨立運行和部署，它能夠經過http請求來索引和搜索。 打個比方：solr就至關於一輛汽車，而lucene只是汽車中的引擎，你能夠開車，但不開引擎。 另外，使用solr能夠獨立部署，擴展容易，因此能夠最大程度的解耦，而lucene使用須要在業務邏輯中添加代碼，邏輯耦合度很高，不易維護。

十一、大家使用activemq應用在哪一種業務場景中，既然都是系統通訊，和其餘的系統通訊有什麼區別？ 咱們使用activemq應用在生成商品詳情，同步索引庫。activemq是一個消息中間件，異步發送消息，而其餘通訊技術：好比dubbo，是同步等待。 好比：使用activemq在商品服務模塊，添加商品並不須要等待索引庫同步完成後才能繼續添加下一個商品，只須要異步發送一個消息告訴索引服務 ，索引服務經過商品ID查詢商品更新索引。 再有：面試中，要淡定，若是有面試官問：數據庫設計這樣作正確嗎？ 你不清楚的狀況下，你就說咱們公司就是這麼解決的。其餘的我不知道。 有些面試官，可能他也不知道，他也想知道。

十二、電商活動倒計時方案 一、肯定一個基準時間。可使用一個sql語句從數據庫中取出一個當前時間。SELECT NOW() 二、活動開始的時間是固定的。 三、使用活動開始時間減去基準時間能夠計算出一個秒爲單位的數值。 四、在redis中設置一個key（活動開始標識）。設置key的過時時間爲第三步計算出來的時間。 五、展現頁面的時候取出key的有效時間。ttl命令。使用js倒計時。 六、一旦活動開始的key失效，說明活動開始。 七、須要在活動的邏輯中，先判斷活動是否開始。

1三、大家的商城的秒殺方案是什麼？ 一、將商品的數量放入redis中。 二、秒殺時，可使用decr命令將商品的數量減一。若是不是負數說明搶到。 三、若是返回的是負數，說明商品已經搶完。

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

1五、redis爲何能夠作緩存？項目中使用redis的目的是什麼？redis何時使用？ 一、Redis是key-value形式的nosql數據庫。能夠快速的定位到所查找的key，並把其中的value取出來。而且redis的全部的數據都是放到內存中，存取的速度很是快，通常都是用來作緩存使用。 二、項目中使用redis通常都是做爲緩存來使用的，緩存的目的就是爲了減輕數據庫的壓力提升存取的效率。 三、在互聯網項目中只要是涉及高併發或者是存在大量讀數據的狀況下均可以使用redis做爲緩存。固然redis提供豐富的數據類型，除了緩存還能夠根據實際的業務場景來決定redis的做用。例如使用redis保存用戶的購物車信息、生成訂單號、訪問量計數器、任務隊列、排行榜等。

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

1七、ActiveMQ在項目中如何應用的？ Activemq在項目中主要是完成系統之間通訊，而且將系統之間的調用進行解耦。例如在添加、修改商品信息後，須要將商品信息同步到索引庫、同步緩存中的數據以及生成靜態頁面一系列操做。在此場景下就可使用activemq。一旦後臺對商品信息進行修改後，就向activemq發送一條消息，而後經過activemq將消息發送給消息的消費端，消費端接收到消息能夠進行相應的業務處理。

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

1九、當被問到某個模快存在安全性問題（sso單點登陸系統）時，如何回答？ 目前商城的sso系統的解決方案中直接把token保存到cookie中，確實存在安全性問題。可是實現簡單方便。若是想提升安全性可使用CAS框架實現單點登陸。參考連接：

20、當技術面試官問到你某個技術點更深層次研究時，本身沒有深刻了解怎麼回答？ 若是沒有深刻研究就直接回答不知道就能夠了。

2一、如何把熱點商品或者是推廣商品的排名提升？ 能夠設置文檔中域的boost值，boost值越高計算出來的相關度得分就越高，排名也就越靠前。

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

2三、solr裏面IK分詞器的原理 IK分析器的分詞原理本質上是詞典分詞。如今內存中初始化一個詞典，而後在分詞過程當中逐個讀取字符，和字典中的字符相匹配，把文檔中的全部的詞語拆分出來的過程。

2一、支付接口是怎麼作的？ 面試中能夠說支付這部分不是咱們作的，咱們項目中並無涉及支付部分的處理。若是想了解支付是如何實現能夠參考以前學過的易寶支付相關處理以及支付寶、微信支付相關文檔。

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

2五、單點登陸系統，若是cookie禁用，大家怎麼解決？ 若是禁用cookie可使用url中帶參數，把token傳遞給服務端。固然此方法涉及安全性問題，其實在cookie中保存token一樣存在安全性問題。推薦使用SSO框架CAS實現單點登陸。

2六、大家作移動端沒有，若是沒有移動端，大家爲何作單點登陸？ 單點登陸並非爲移動端準備的，移動端有本身的登陸方式。單點登陸是解決在同一個公司內部多個互信網站之間進行跳轉時不須要屢次登陸，多個系通通一登陸入口。

2七、單點登陸的核心是什麼？ 單點登陸的核心是如何在多個系統之間共享身份信息（即共享session）。

2八、除了單點登錄，還作過什麼登錄的方式？ 除了單點登陸那就是普通登陸方式，用戶在同一個公司的多個系統之間跳轉時須要屢次登陸。

2九、單點登陸，http無狀態的，別人模仿如何在後端處理？ http是無狀態的，若是別人模仿瀏覽器發送http請求，通常後臺是沒法識別的。若是對安全要求高的狀況下應該是https協議。能夠保證在通訊過程當中沒法竊取通訊內容。

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

3一、商品存入數據庫怎麼保證數據庫數據安全？ 一、對用戶安全管理 用戶操做數據庫時，必須經過數據庫訪問的身份認證。刪除數據庫中的默認用戶，使用自定義的用戶及高強度密碼。 二、定義視圖 爲不一樣的用戶定義不一樣的視圖，能夠限制用戶的訪問範圍。經過視圖機制把須要保密的數據對無權存取這些數據的用戶隱藏起來，能夠對數據庫提供必定程度的安全保護。實際應用中常將視圖機制與受權機制結合起來使用，首先用視圖機制屏蔽一部分保密數據，而後在視圖上進一步進行受權。 三、數據加密 數據加密是保護數據在存儲和傳遞過程當中不被竊取或修改的有效手段。 四、數據庫按期備份 五、審計追蹤機制 審計追蹤機制是指系統設置相應的日誌記錄，特別是對數據更新、刪除、修改的記錄，以便往後查證。日誌記錄的內容能夠包括操做人員的名稱、使用的密碼、用戶的IP地址、登陸時間、操做內容等。若發現系統的數據遭到破壞，能夠根據日誌記錄追究責任，或者從日誌記錄中判斷密碼是否被盜，以便修改密碼，從新分配權限，確保系統的安全。

3二、訂單表的數據量太大，我把訂單分到許多表中，那麼我我想用一條sql查處全部的訂單，怎麼解決？ 分庫狀況下：可使用mycat數據庫中間件實現多個表的統一管理。雖然物理上是把一個表中的數據保存到多個數據庫中，可是邏輯上仍是一個表，使用一條sql語句就能夠把數據所有查詢出來。 單庫狀況下：須要動態生成sql語句。先查詢訂單相關的表，而後將查詢多個表的sql語句使用union鏈接便可。

3三、我們單點登陸模塊中，別人僞造咱們cookie中的token怎麼辦？ 服務端是沒法阻止客戶端僞造cookie的，若是對安全性要求高的話能夠可以使用CAS框架。

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

3五、對數據庫只是採用了讀寫分離，並無徹底解決數據庫的壓力，那麼有什麼辦法解決？ 若是數據庫壓力確實很大的狀況下能夠考慮數據庫分片，就是將數據庫中表拆分到不一樣的數據庫中保存。可使用mycat中間件。

3六、同一帳號以客戶端登陸怎麼擠掉另外一端。 用戶登陸後須要在session中保存用戶的id。當用戶登陸時，從當前全部的session中判斷是否有此用戶id的存在，若是存在的話就把保存此用戶id的session銷燬。

3七、solr的索引查詢爲何比數據庫要快？ Solr使用的是Lucene API實現的全文檢索。全文檢索本質上是查詢的索引。而數據庫中並非全部的字段都創建的索引，更況且若是使用like查詢時很大的多是不使用索引，因此使用solr查詢時要比查數據庫快。

3八、solr索引庫個別數據索引丟失怎麼辦？ 首先Solr是不會丟失個別數據的。若是索引庫中缺乏數據，那就向索引庫中添加。

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